Documentos de Académico
Documentos de Profesional
Documentos de Cultura
INGENIERIA DE SOFTWARE II
Trayecto III - Trimestre I Unidad 1
QU ES IMPORTANTE?
Es importante la participacin en clase Es importante la puntualidad Es importante mantener nuestros celulares apagados o en modo de vibracin en clase. -no contestarlos en el saln-
Proyecto Prctico (Tributario al Proyecto Socio-Tecnolgico) Talleres prcticos relacionados con la materia con el objetivo de:
Entender el contexto del tema. Debatir las ideas expuestas en el taller. Cotejar lo que creemos saber.
1 Informe Tcnico sobre el Marco ISO-9126 (10%) (30-01-2013) Taller 1 (15%) (06-02-2013)
SABERES
Unidad 1: Requerimientos del Software o Qu son los requerimientos o Requisitos? o Necesidades, Objetivos Requerimientos y Actores Relacionados con los
ESTRATEGIAS
RECURSOS
EVALUACIN
o Importancia de la Ingeniera de Requisitos en la prctica o Levantamiento y Recoleccin de Requerimientos. o Tcnicas ms usadas: Mtodo JAD y FPA
Talleres prcticos dirigidos, basados en casos de estudios nicos e integrales que permitan al participante la aplicacin directa y visible de los conocimientos tericos adquiridos durante las actividades en aula de encuentros.
Pizarra magntica Marcadores Material Educativo Computarizado: Material Instruccional, Software Instruccional Computador Casos Prcticos Proyector Multimedia Plataforma Tecnolgica Aula de encuentros Evaluacin continua Trabajo en grupo Ejercicios individuales Participacin
Unidad 2: Especificacin de Requerimientos o Textual, notacin grfica y lenguajes de representacin (Lenguaje Unificado de Modelado UML, Notacin de Requerimientos de Usuario URN). o Tcnicas para escribir requerimientos Estndares de Documentacin. de alta calidad.
Trabajos de investigacin que fortalezcan en el participante la capacidad de interpretacin de la formacin relacionada con la investigacin en ingeniera del software.
del
SABERES
Unidad 3: Anlisis de Requerimientos
o Inspeccin, validacin, completitud, deteccin de conflictos inconsistencias de requerimientos. o Documentos de Requerimientos de Software: Creacin, Importancia. o Mtricas y herramientas para la ingeniera de requisitos. Unidad 4: Modelado del Sistema o Tcnicas y Mtodos de Modelado de Sistemas. o Modelado Orientado a Casos de Uso, Prototipo y Tcnicas de Anlisis. o Modelado del negocio: Casos de Uso del Negocio, Especificacin de CUN, Actividades del Negocio, Objetos del Negocio. e
ESTRATEGIAS
RECURSOS
EVALUACIN
usos e
Lecturas orientadas. El profesor asesor elaborar un cuestionario con preguntas que orienten al participante en la identificacin del conocimiento relevante que debe adquirir hacia el final de la lectura.
Exposiciones, mesas redondas y foros de discusin acerca de las consultas y lecturas recomendadas realizadas por el participante.
Humphrey Watts S. (2001). Introduccin al Proceso Software Personal. Addison Wesley. Meyer
JACOBSON Ivar. BOOCH Grady RUMBAUCH James (1999) The United Software Development Process. Rational Software Corporation. Addition Wesley. Larman Craig. (2003) UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. PEARSON Prentice Hall. Segunda Edicin.
Pressman, Roger S. (2005). Ingeniera del Software: Un enfoque prctico; Sexta edicin. McGraw-Hill, Madrid.
Reifer, Donald J. (1993). SOFTWARE MANAGEMENT. IEEE Computer Society Press. Los Alamitos, CA Sommerville, Ian (2006). Ingeniera de Software; Sexta edicin. Pearson Educacin, Mxico. Wang, Yingxu & King, Graham (2000). Software Engineering Processes. Principles and Applications. CRC Press LLC, N. W. Florida.
Wilson, Scott F. Analyzing Requirements and Defining Solution Architectures. Redmond: Microsoft Press, 1999.
Choque Ayala de Joaquin , Americo . Ingeniero de Sistemas www.unpmsm.org Joaquin Deza de Choque, Victoria Rosa. Analista de Sistemas www.unpmsm.org Apuntes de Clases
La funcionalidad es slo una parte de lo que el sistema puede hacer. Para definir la arquitectura debemos CONOCER los requerimientos o atributos de calidad, que nos hablan de las caractersticas especficas que el sistema tendr. Ejemplo: Flexibilidad, transportabilidad, usabilidad, etc.
Los atributos de calidad muchas veces se afectan entre s. Por ejemplo portabilidad vs. performance o flexibilidad vs. performance.
Por lo general estn pobremente especificados, o no especificados (un requerimiento que no es medible no es implementable). En general no se analizan sus dependencias. La importancia de los atributos varia con el dominio para el cual se construye el software. El ingeniero de software, generalmente no identifica las restricciones asociadas a los atributos de calidad que identifica.
La arquitectura de un sistema es un medio para alcanzar los atributos de calidad deseados, no el fin.
El atributo de mayor importancia suele ser la flexibilidad: Facilidad de cambios.
Valorar la importancia de construir software de calidad Caracterizar los requerimientos de software. Identificar los problemas asociados a los requerimientos de software Diferenciar entre el espacio del problema y el espacio de solucin.
Reconocer la importancia del Modelado de Negocios y de la Ingeniera de Requerimientos en el proceso de desarrollo de software de calidad.
QU ES CALIDAD?
Propiedad o conjunto de propiedades inherentes a una cosa, que permite apreciarla como igual, mejor o peor que las restantes de su especie.
Diccionario de la Real Academia Espaola
Totalidad de las caractersticas de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades expresadas o implcitas.
NORMA UNE 66-001-92 Traduccin de ISO 8402 [AENOR, 1992]
ORGENES DE LA CALIDAD
Calidad Programada
Calidad Realizada
Calidad Necesaria
Los requisitos [requerimientos] especificados. Las necesidades o expectativas del cliente o usuario.
(IEEE Std. 610.1990) [IEEE, 1993] (Cursivas nuestras)
Concordancia del software producido con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.
[Pressman, 1998]
DESCRIPCIN Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades especficas. Las funciones son aquellas que satisfacen lo indicado o implica necesidades.
Idoneidad Exactitud Interoperabilidad Seguridad Cumplimiento de normas. Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestacin bajo condiciones establecidas durante un perodo de tiempo establecido.
FIABILIDAD
Madurez Recuperabilidad Tolerancia a fallos Un conjuntos de atributos relacionados con el esfuerzo necesitado para el uso, y en la valoracin individual de tal uso, por un establecido o implicado conjunto de usuarios.
USABILIDAD
Aprendizaje
Comprensin Operatividad
* Un atributo es una entidad la cual puede ser verificada o medida en el producto software.
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"
CARACTERISTICAS/ ATRIBUTOS
DESCRIPCIN Conjunto de atributos relacionados con la relacin entre el nivel de desempeo del software y la cantidad de recursos necesitados bajo condiciones establecidas.
EFICIENCIA
Comportamiento en el tiempo Comportamiento de recursos Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software.
MANTENIBILIDAD
Estabilidad Facilidad de anlisis Facilidad de cambio Facilidad de pruebas Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra.
PORTABILIDAD
1. Completar la Tabla del marco ISO-9126. 2. Determinar el grado de calidad de una aplicacin WEB, en funcin del Marco ISO-9126. Para la aplicacin seleccionada determinar: Empresa, URL, Objetivos
Se estima que, del total de proyectos software grandes emprendidos, un 28% fracasan, un 46% caen en severas modificaciones que lo retrasan y un 26% son totalmente exitosos. Cuando un proyecto fracasa, rara vez es debido a fallas tcnicas, la principal causa de fallos y fracasos es la falta de aplicacin de una buena metodologa o proceso de desarrollo. Nosotros DEBEMOS comprometemos a mejorar las metodologas o procesos de desarrollo, o crear nuevas y concientizarnos en su utilizacin adecuada.
Una condicin o capacidad que debe poseer el sistema, necesaria para resolver un problema o alcanzar un objetivo
Una condicin o capacidad que debe ser satisfecha o poseida por un sistema o un componente del sistema a fin de satisfacer un contrato, estndar, especificacin u otro documento formalmente impuesto.
(IEEE Standard Glossary of Engineering Terminology, 1990 )
Los requerimientos son el punto de acuerdo entre el cliente y el ingeniero de software. Este
entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente.
Aspecto de un sistema o una descripcin de aquello que el sistema es capaz de hacer a fin de cumplir su propsito
(Pfleeger, 1998)
Los requerimientos EXPRESAN lo que una aplicacin o sistema debe hacer para satisfacer las necesidades de sus clientes o usuarios. lograr estas funciones No intentan expresar cmo
CONTEXTO DE SISTEMA
El trmino sistema se refiere a: Un sistema de Software
- Software de sistema -- Ejemplo: Sistemas operativos, compilador, interpretes, DBMS, entre otros.
-
- Software de desarrollo
-
- Aplicacin de software
-
Un sistema de Hardware-Software
-
Un sistema de Negocios
Se refiere al dominio de aplicacin donde un sistema de software o H/S opera.
Sistema de Negocios Sistema H/S
-
Ejemplos:
- El sistema contable de una empresa
- El vehculo donde opera el GPS. -- El proceso industrial controlado por un controlador automtico
Sistema de Software
RAFMA, C.A. es una empresa especializada en la compra y venta de monedas antiguas de todo el mundo, con ms de 10 aos en el mercado. Durante su existencia, RAFMA ha conformado una de las ms completas colecciones de monedas antiguas a nivel mundial. Para operar RAFMA enva catlogos impresos de su coleccin a clientes selectos en todo el mundo, por los cuales deben cancelar $10. Los pedidos se hacan por correo electrnico y las monedas eran despachadas por correo courier a los clientes. Como estrategia para fortalecer el negocio RAFMA decidi cambiar su modelo de negocios por uno basado en comercio electrnico, para lo cual se contrat el desarrollo de la aplicacin web: oldcurrency.com
Oldcurrency.com es una aplicacin que permite la comercializacin de monedas antiguas de y desde cualquier parte del mundo.
Algunos requerimientos
Explcitos: Los requerimientos establecidos explcitamente se reflejan en el documento de Especificacin de Requerimientos del Sistema (ERS)
Requerimientos funcionales: Funciones a realizar por el software. Requerimientos no funcionales: Requerimientos de seguridad, rendimiento, interfaz, etc. Describen restricciones que limitan las opciones de solucionar el problema. Restricciones cuantitativas o precisin. Pseudorequerimientos: Impuestos por el cliente que restringen la implementacin del sistema
Implcitos: Los requerimientos implcitos no aparecen en la ERS, pero si no se cumplen con ellos la calidad del software queda en entredicho.
Los estndares y las normas de desarrollo permiten que se consiga una alta calidad tcnica.
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"
Requerimiento
Funcional
No Funcional
De Negocios
Del Usuario
Del Sistema
De Comportamiento
Restriccin
Atributo de Calidad
De Interfaz
Regla de Negocio
Requerimientos de Usuarios
Expresan que objetivos, metas o necesidades la empresa espera alcanzar con el uso del sistema.
Ejemplos:
La empresa RAFMA, C.A. quiere abrir su mercado a cualquier usuario interesado en la adquisicin de monedas antiguas. La aplicacin oldcurrency.com deber contribuir a abrir el mercado e incrementar el volumen de ventas anuales de monedas antiguas.
Requerimientos de Comportamiento
Son de alto nivel para productos que tienen componentes H/S. Se expresan desde la perspectiva del sistema H/S que contiene la aplicacin. Asumen que la el software es parte de un sistema mayor. Ejemplos:
La aplicacin oldcurrency.com deber enviar un mensaje electrnico cada vez que RAFMA, C.A. disponga de una moneda antigua de su inters.
Ejemplos:
El sistema oldcurrency.com, deber permitirle al cliente efectuar el pago de su pedido en lnea, usando cualquier tarjeta de crdito.
El sistema deber permitirle al usuario visualizar la moneda o monedas seleccionadas por el usuario de los contenidos en el catlogo de monedas.
Restricciones
Atributos de Calidad
Expresan las limitaciones que se le imponen al desarrollo del sistema. Describen aspectos tales como:
Plataforma de desarrollo y operacin. Uso de estndares, prcticas, mtodos de desarrollo. Tiempo mximo de desarrollo. Costo mximo de desarrollo.
Ejemplos:
oldcurrency.com, deber tener una confiabilidad mayor a 95%. oldcurrency.com deber ser fcil de usar..
Ejemplos:
oldcurrency.com deber ser una aplicacin web que debe ser desarrollado con las siguientes herramientas: Plataforma LAMP: Linux, Apache, MySql y PHP. Tiempo mximo de desarrollo 6 meses. Costo mximo de desarrollo 50.000 Bs.
Reglas de Negocio
De Interfaz
Expresan todas las regulaciones que la aplicacin deber acatar, entre otras:
Regulaciones gubernamentales decretos, providencias, etc.) (Leyes,
Expresan las caractersticas de la interaccin del usuario con el sistema. Se dividen en:
Requerimientos de interfaz grfica (GUI). Describen las propiedades generales de la interfaz grfica que permitir la interaccin entre el usuario y el sistema. Requerimientos de interfaces con otros sistemas. Describen con qu o cmo la aplicacin interactuar con otras aplicaciones de software o sistemas de hardware.
Regulaciones de la empresa (Polticas, normas, procedimientos, estrategias, etc.) Regulaciones propias de la aplicacin (Estndares, metodologa que debe seguirse, algoritmos o clases que deben usarse).
Ejemplos:
oldcurrency.com deber desarrollarse usando la metodologa RUP. Un cliente puede descargar gratuitamente las actualizaciones de un catlogo adquirido por el, durante los dos primeros meses a partir de la publicacin de la actualizacin.
Ejemplos:
oldcurrency.com deber usando una interfaz web. ser implementada
Requerimientos Funcionales
Requerimientos No Funcionales
Establecen:
Los objetivos de negocio respecto al sistema. Los servicios que el sistema debe proporcionarle a los usuarios.
la del
Determinan la funcionalidad del sistema. Determinan lo que el sistema deber hacer, es decir:
Su comportamiento. Su interaccin con los usuarios y su dominio de aplicacin (negocio) Sus respuestas a eventos.
Los Requerimientos deben ser: Completos. Todo lo que el software tiene que hacer est recogido en el conjunto de requerimientos, es decir, deben describir toda la funcionalidad que el sistema deber implementar y por lo tanto debe representar algo requerido por el usuario para el sistema que se construye y ser validado por este.
Traceables. Cada accin de diseo debe corresponderse con algn requerimiento del cliente (resuelve un problema de este). Verificables. Preferiblemente deben expresarse de manera cuantitativa, usando mtricas que faciliten su verificacin. Consistentes. Ningn requerimiento puede estar en conflicto con otro. Tipos de Inconsistencia: Trminos conflictivos: Si dos trminos se usan en contextos diferentes para la misma cosa. Caractersticas en conflicto: Si en dos partes de la ERS se pide que el producto muestre comportamientos contradictorios. Inconsistencia temporal: Si dos partes de la ERS piden que el producto obedezca restricciones de tiempo contradictorias.
EJEMPLOS DE REQUERIMIENTOS
1. El software normalmente est integrado por muchos componentes. En la mayor parte de los casos, es difcil para el ingeniero de software entender todos estos componentes al mismo tiempo.
$1 durante la fase de diseo. $2 durante la fase del diseo detallado. $3 durante la codificacin. $5 durante la prueba de unidades. $20 durante la validacin. $100 despus que el sistema ha entrado en produccin.
3. Problemas de Comunicacin.
El cliente o el usuario no entiende el lenguaje informtico de los analistas. Los analista no entienden el lenguaje del dominio de la aplicacin.
- Son inconsistentes.
- Son incompletos. - No son factibles.
1. Los mtodos tradicionales de desarrollo de software importancia del problema y su anlisis, debido a que: - Se centran en la solucin y sus requisitos.
subestiman
la
ESPACIO DE PROBLEMA
INGENIERIA DE REQUERIMIENTOS
MN
IR
El Modelado de Negocios (MN) es un proceso a travs del cual se representa el dominio de una aplicacin. Es el mecanismo por el cual un negocio trata de generar ingresos y/o beneficios. Es un resumen de cmo una organizacin planifica servir a sus clientes. En aplicaciones empresariales el MN representa diferentes aspectos del dominio de la aplicacin. - El dominio es denominado SISTEMA DE NEGOCIOS. El MN identifica y representa aspectos del sistema de negocios, tales como: - Objetivos de la organizacin. - Procesos de Negocio y sus actividades. - Reglas de Negocio.
El Problema
Sub-modelos
Objetivos
Procesos de Negocio
Objetos de Negocio
Actores
Reglas de Negocio
Eventos
Requerimientos Funcionales
Requerimientos No Funcionales
La Solucin
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"
En la fase de Ingeniera de Requerimientos, el Modelo de Negocios es usado para: Entender el proceso de negocio actual y establecer sus problemas de informacin. Descubrir las necesidades que los usuarios tienen. Se analiza cada proceso para determinar que informacin requiere. Facilitar la definicin y especificacin de requerimientos funcionales. Los diagramas de actividades permiten identificar aquellas acciones que se desean automatizar. Caracterizar el nuevo proceso de negocios y su flujo de trabajo.
La IR se encarga de establecer:
- Principios - Modelos - Mtodos
- Mejores prcticas
- Tcnicas y - Herramientas automatizadas que contribuyan especificacin de los requerimientos. a mejorar la definicin y
Transformar la definicin de necesidades en una descripcin completa y precisa de requerimientos denominada: Especificacin de Requerimientos de Software (ERS).
Lograr un entendimiento comn, entre usuarios y desarrolladores, de los requerimientos que debe satisfacer el sistema.
tiene
tres
El Producto: Qu se hace?
Qu produce la Ingeniera de Requerimientos? Su producto principal es el DOCUMENTO DE REQUERIMIENTOS. - Contiene el conjunto de requerimientos que debe satisfacer el sistema El Documento de Requerimientos (DR) es un documento manual o electrnico que describe y comunica de manera sencilla y comprensible los requerimientos para: - Los Clientes, usuarios y gerentes.
El Documento de Requerimientos debe describir: - Los servicios y funciones que debe ofrecer el sistema. - Las restricciones bajo las cuales deber operar el sistema. - Las propiedades o atributos de calidad que deber caracterizar al sistema. Normalmente el documento se divide en dos partes: - Documento de Definicin de Requerimientos (DDR) - Documento de Especificacin de Requerimientos (DER)
Documento de Definicin de Requerimientos (DDR) Describe los requerimientos de alto nivel desde la perspectiva de los clientes y/o usuarios. Est orientado usuarios. a los clientes y/o
Documento de Especificacin de Requerimientos (DER) Describe detalladamente los requerimientos contenidos en el DDR.
Existen varios estndares y modelos (plantillas o patrones) que ayudan a elaborar el DR. El estndar IEEE 830-1993 Propuesto por el Institute of Electrical and Electronics Engineers (IEEE) Agrupa los documentos DDR y DER en un solo documento. Es tambin un estndar ANSI La plantilla Volere. - Permite documentar cada requerimiento mediante un formato especial.
II.
Descripcin general
1. Perspectivas del producto - Interfaces del sistema - Interfaces del usuario - Interfaces de H/S - Interfaces de comunicacin
3. Requisitos de desempeo
4. Restricciones de diseo 5. Atributos de calidad del sistema 6. Otros requisitos
- Restricciones de memoria
- Operaciones - Requisitos de adaptacin del sitio.
Descripcin: Calcular el promedio diario, mensual y anual ingresos por concepto de venta de monedas antguas de cada una de las casa sucursales de RAFMA en los cinco continentes. Justificacin del requisito Es necesario elaborar los reportes de ingresos diarios, mensuales y anuales de venta de monedas antguas de cada sucursal. Fuente (que interesado lo propone) Unidad en la que se origina: Pedro Prez Departamento de Ventas Criterios de Validacin Los valores obtenidos se compararan con los obtenidos en aos pasados para determinar si hay inconsistencias. Grado de satisfaccin del usuario: Grado de insatisfaccin del interesado: 3 5 Dependencias (qu requisitos dependen de este): Conflictos (qu requisitos son incompatibles con este) 35, 56 Documentos de Soporte: Historico de cambios: Manual de Ventas 15/07/2010 Proyecto: oldcurrency.com Analista: Rafael Matos
Procesos Tcnicos
Validacin de Requisitos
Procesos de Gestin
Gestin de Requisitos Controlan y apoyan a los procesos tcnicos
Denominada tambin Captura de Requerimientos Consiste en la bsqueda y recoleccin de requerimientos Sus actividades principales son: Establecimiento de objetivos y descripcin del problema. Identificacin de actores o interesados (stakeholders). Entidades externas que interactan con el sistema Adquisicin de conocimientos sobre el dominio de la aplicacin. Organizacin del conocimiento Recoleccin de los requerimientos que tienen los interesados, es decir, Identificacin de escenarios. Descripcin concreta, enfocada e informal de una sola caracterstica del sistema desde el punto de vista de un solo actor.
estar
interesados
en:
cunto
costara
el
sistema?,
cul
ser
el
costo/beneficio?, cundo recuperaran la inversin y cmo la recuperaran?, etc. Este grupo es quien paga por el sistema. 2. Supervisores del contrato. Sugieren hitos de control y cronogramas que
sistema.
Actores 4. 5. Los Diseadores. Usarn los requerimientos como base del desarrollo. Los verificadores. Encargados de las sesiones de prueba destinadas a asegurar Un agente de cambio se puede definir como alguien que el sistema cumple los requerimientos.
que sirve de catalizador para el cambio, desarrolla un plan para el cambio y especialista que dems para 6. Analistas de Sistemas. Es un coopera con los estudia los problemas y necesidades de una organizacin para determinar como las personas, datos, facilitar el cambio
procesos y la tecnologa de la informacin pueden en conjunto mejorar un negocio. El analista desempea diversos roles, en ocasiones varios de ellos al mismo tiempo. Los tres principales roles del analista de sistemas son el de consultor, exporto en soporte tcnico y agente de cambio.
i.
j.
e. JAD
f. FPA
Identificar personas con puntos de vista precisos para representar el conjunto de los requerimientos:
Consiste en analizar los requerimientos recolectados durante el proceso de obtencin con el fin de: Determinar y resolver posibles conflictos entre requisitos.
Prototipos.
Tcnicas de Negociacin.
Consiste en la documentacin de los requerimientos. Est relacionado con la estructura, calidad y verificabilidad del Documento de Requisitos (El Producto) Premisa: La documentacin de requerimientos es la presentacin fundamental para el manejo exitoso de estos [Kotonya y Sommerville, 2000]
Actividades. Seleccin del estndar de documentacin Documentacin de los requerimientos del cliente. Documentacin de los requerimientos del desarrollador
IEEE P1233/D3
ISO/IEC 12119-1994 IEEE 1362-1998 Indicadores de Calidad Modelo de Calidad del Software (Marco ISO 9126)
Lenguajes y Notaciones
Lenguajes de Modelado Grfico Lenguaje Orientado a Objetos (UML) Lenguajes Estructurados: DFD, ER. Lenguajes Dinmicos: Redes de Petri, Diagramas de Estado
Consiste en examinar los productos elaborados durante la Ingeniera de Requerimientos para determinar si son descripciones vlidas y aceptables de los requisitos del sistema que se desea construir.
Productos de la IR que se validan en este proceso. Lista de requerimientos recolectados Modelos de requerimientos Modelo funcional, estructural y dinmico Prototipos Documentos de Requisitos Documento de Definicin de Requerimientos
Correctos
Satisfacen las necesidades reales de los usuarios Completos
Incluyen todos los requisitos que los usuarios necesitan
Consistentes
Actividades y Tcnicas utilizadas: Revisin Tcnica Inspeccin de modelos Inspeccin de documentos Validacin de Prototipos
El manejo de las dependencias entre el documento de requerimientos y otros documentos producidos en el desarrollo del sistema
Seguimiento o trazabilidad de requerimientos
Gestin de Cambios
Gestin de Almacenamiento de Requerimientos Identificacin de Requerimientos Uso de procesadores de texto Uso de bases de datos de requerimientos Rastreo o trazabilidad de Requisitos