ndice

Introduccin. Requisitos de sistema. El proceso de ingeniera de requisitos. IEEE Std. 830-1998. Gestin de requisitos.

6. Ingeniera de requisitos

Ingeniera de requisitos Introduccin

Entender la naturaleza de un problema por lo general es algo difcil es difcil establecer que debe hacer un sistema software La descripcin de los servicios y restricciones son los requisitos del sistema El proceso para identificar dichos requisitos es el anlisis de requisitos

Ingeniera de requisitos Introduccin

Podemos identificar dos tipos de requisitos:
- Requisitos de usuario. - Requisitos de sistema.

Los requisitos de usuario son frases en lenguajes natural junto a diagramas de los servicios que el sistema debe proporcionar, as como las restricciones bajo las que debe operar

Ingeniera de requisitos Introduccin

Los requisitos de sistema determinan los servicios del sistema y las restricciones en detalle. Sirven como contrato. Es decir, son los mismo, pero a distinto nivel de detalle
- e.g. req. usuario: el sistema debe hacer prstamos - e.g. reg. sistema: funcin prstamo; entrada: cd. socio, cd. ejemplar; salida: fecha devolucin; ......

Ingeniera de requisitos Requisitos de sistema

Hay tres tipos de requisitos de sistema:
- Requisitos funcionales. - Requisitos no funcionales - Requisitos del dominio.

Los requisitos funcionales describen:

- Los servicios que proporciona el sistema (funciones). - La respuesta del sistema ante determinadas entradas. - El comportamiento del sistema en situaciones particulares.

Ingeniera de requisitos Requisitos de sistema

- En algunos casos, tambin determinan lo que no debera hacer el sistema. - e.g.
funcin: prstamo. descripcin: presta un ejemplar a un socio de la biblioteca. entrada: cdigo socio, cdigo ejemplar. salida: fecha devolucin. origen:operador consola. destino: sistema. requisito: base de datos de socios y ejemplares. precondicin: usuario y ejemplar dados de alta, usuario sin prstamos pendientes, usuario sin lmite alcanzado. postcondicion: ejemplar prestado al usuario. efectos laterales: retirar carn durante 7 das si el usuario tiene prstamos pendientes.

Ingeniera de requisitos Requisitos de sistema

Los requisitos no funcionales son restricciones de los servicios o funciones que ofrece el sistema (e.g. tiempo, proceso de desarrollo, etc.)
- e.g. la biblioteca debe ser capaz de atender simultneamente a todas las bibliotecas de la UCM

Ingeniera de requisitos Requisitos de sistema

A su vez, hay tres tipos de requisitos no funcionales:
- Requisitos del producto. Especifican el comportamiento del producto (e.g. prestaciones, memoria, tasa de fallos, etc.) - Requisitos organizativos. Se derivan de las polticas y procedimientos de las organizaciones de los clientes y desarrolladores (e.g. estndares de proceso, lenguajes de programacin, etc.) - Requisitos externos. Se derivan de factores externos al sistema y al proceso de desarrollo (e.g. requisitos legislativos, ticos, etc.)

Ingeniera de requisitos Requisitos de sistema

Los requisitos del dominio se derivan del dominio de la aplicacin y reflejan caractersticas de dicho dominio. Pueden ser funcionales o no funcionales
- e.g. El sistema de biblioteca de la UCM debe ser capaz de exportar datos mediante el Lenguaje de Intercomunicacin de Bibliotecas de Espaa (LIBE). - e.g. El sistema de biblioteca no podr acceder a bibliotecas con material censurado.

Ingeniera de requisitos El proceso de ingeniera de req.

La ingeniera de requisitos debe centrarse sobre lo que hay que hacer, no sobre el cmo Tiene distintas fases que producen resultados diferentes

Ingeniera de requisitos El proceso de ingeniera de req.

Estudio de viabilidad Anlisis de requisitos Especificacin de requisitos Requisitos de usuario Validacin de requisitos Requisitos de sistema

Informe de viabilidad

El proceso de ingeniera de requisitos

Especificacin de requisitos software (SRS)

Ingeniera de requisitos El proceso de ingeniera de req.

Estudio de viabilidad
- Estimacin sobre si se puede resolver el problema del usuario con las tecnologas software y hardware disponible - El estudio decide si el sistema es rentable y puede desarrollarse cumpliendo las restricciones econmicas

Ingeniera de requisitos El proceso de ingeniera de req.

Anlisis de requisitos
- Se derivan los requisitos de la aplicacin mediante la observacin de sistemas existentes, discusiones con usuarios potenciales, analistas y dems implicados. - Podran desarrollarse modelos y/o prototipos del sistema. - Se genera un documento introductorio con los requisitos i.e., los requisitos de usuario.

Ingeniera de requisitos El proceso de ingeniera de req.

Ingeniera de requisitos El proceso de ingeniera de req.

El proceso de anlisis de requisitos
1. Comprensin del dominio. Los analistas deben comprender el dominio de la aplicacin. 2. Recoleccin de requisitos. Interaccin con stakeholders* del sistema para descubrir sus requisitos. 3. Clasificacin. Recolectar el conjunto no estructurado de requisitos y organizarlos en agrupaciones coherentes.

El proceso de anlisis de requisitos

*Cualquier persona que puede tener influencia directa o indirecta en los requisitos del sistema.

Ingeniera de requisitos El proceso de ingeniera de req.

4. Resolucin de conflictos. Resolver los conflictos que pudieran producirse entre stakeholders. 5. Priorizacin. Interaccin con los stakeholders para identificar los requisitos ms importantes del sistema. 6. Comprobacin de requisitos. Comprobar los requisitos para comprobar si son completos y consistentes con los deseos de los stakeholders

Ingeniera de requisitos El proceso de ingeniera de req.

Especificacin de requisitos
- Se fija una descripcin detallada y precisa de los requisitos del sistema, de tal forma que sirva de base para un contrato entre el cliente y el desarrollador de software - El objetivo es obtener la especificacin de requisitos del sistema.

Ingeniera de requisitos El proceso de ingeniera de req.

- Pueden utilizarse distintos lenguajes para especificar los requisitos:
- Lenguaje natural. - Lenguaje natural estructurado. - Lenguaje de descripcin de diseo. - Lenguaje de especificacin de requisitos. - Notaciones grficas. - Especificaciones matemticas.

Ingeniera de requisitos El proceso de ingeniera de req.

Validacin de requisitos
- Se encarga de comprobar si los requisitos se ajustan a los deseos de los stakeholders. - Si la validacin es inadecuada, se propagarn errores al diseo e implementacin. - Evidentemente, tiene una fuerte repercusin sobre el coste. - El objetivo es obtener la especificacin de requisitos software SRS (Software Requirements Specification)

Ingeniera de requisitos El proceso de ingeniera de req.

Hay distintos tipos de comprobaciones en el proceso de validacin de requisitos:
- Validez. Comprobar la necesidad de las funciones definidas en la SRS. - Consistencia. Comprobar que no hay restricciones contradictorias o distintas descripciones de la misma funcin. - Completitud. Comprobar que todos los requisitos y restricciones estn incluidos en la SRS

Ingeniera de requisitos El proceso de ingeniera de req.

- Realismo. Comprobar que se pueden implementar los requisitos con las tecnologas y plantilla disponible. - Verificabilidad. Comprobar que los requisitos pueden ser verificables con el fin de evitar problemas entre clientes y desarrolladores.

Ingeniera de requisitos El proceso de ingeniera de req.

Hay distintas tcnicas para verificar los requisitos, que pueden utilizarse conjunta o individualmente:
- Revisin de requisitos. Anlisis sistemtico de los requisitos por parte de un equipo de revisores. - Prototipado. Creacin de un modelo ejecutable del sistema.

Ingeniera de requisitos El proceso de ingeniera de req.

- Generacin de casos de prueba. Si no somos capaces de disear un caso de prueba para un requisitos, probablemente el requisito sea problemtico. - Anlisis automtico de la consistencia. Supuesto que se haya utilizado una herramienta formal de especificacin de requisitos.

Ingeniera de requisitos IEEE Std. 830-1998

El IEEE Std. 830-1998 se encarga de proporcionar unas normas para la creacin de la Especificacin de Requisitos Software (SRS: Software Requirements Specification) Objetivos de la SRS:
- Establecer la base para un acuerdo entre clientes y desarrolladores sobre que debe hacer el software.

Ingeniera de requisitos IEEE Std. 830-1998

- Reducir el esfuerzo de desarrollo. - Proporcionar una base para la estimacin de costes y planificacin. - Proporcionar una gua para la validacin y verificacin - Facilitar la transferencia de software. - Servir como base para mejoras posteriores.

Segn el IEEE una SRS debera identificar las siguientes caractersticas del sistema:

Ingeniera de requisitos IEEE Std. 830-1998

- Funcionalidad. Lo que hace el sistema. - Interfaces externas. Forma de interactuar del sistema con las personas, el hardware del sistema, otro hardware y otro software. - Prestaciones. Entre otras, velocidad, disponibilidad y tiempo de respuesta del sistema. - Atributos. Portabilidad, correccin, mantenibilidad, seguridad y otros atributos.

Ingeniera de requisitos IEEE Std. 830-1998

- Restricciones de diseo impuestas a la implementacin. Entre otras, estndares, lenguajes de implementacin, entornos operativos, etc.

Hay otras cuestiones que deben excluirse de la SRS:

- Requisitos del diseo o del proyecto. - Detalles de diseo o implementacin. - El proceso de produccin del sistema.

Ingeniera de requisitos IEEE Std. 830-1998

La SRS debe centrarse en qu hace el sistema, no en cmo lo hace, ni en cmo se construir El estndar identifica una serie de caractersticas de una buena SRS:
- Correcta. Cada requisito identificado es un requisitos del sistema. - No ambigua. Cada requisito identificado tiene una nica interpretacin.

Ingeniera de requisitos IEEE Std. 830-1998

- Completa. La SRS debe incluir:
- Todos los requisitos relativos a funcionalidad, prestaciones, restricciones de diseo, atributos o interfaces externos. - Definicin de las respuestas del sistema a todos los tipos posibles de datos de entrada en todas las posibles situaciones. - Todas las etiquetas y referencias a todas las figuras, tablas y diagramas en la SRS, as como definiciones de todos los trminos y unidades de medida.

Ingeniera de requisitos IEEE Std. 830-1998

- Consistente. Consistencia interna con todos los requisitos en todos los documentos (i.e. requisitos de usuario vs. requisitos de sistema). - Priorizada. La SRS deber priorizar la importancia y/o la estabilidad de cada requisito mediante un identificador de importancia y/o estabilidad para cada requisito. - Verificable. Cada requisito identificado es verificable (i.e. se puede comprobar que el sistema implementa el requisito).

Ingeniera de requisitos IEEE Std. 830-1998

- Modificable. La estructura y estilo permiten cambios en los requisitos de forma fcil, completa y consistente manteniendo la estructura y estilo. - Trazable. El origen de cada requisito est claro y facilita la referencia de cada requisito en desarrollos futuros o en mejoras de la documentacin.

Ingeniera de requisitos IEEE Std. 830-1998

Los interfaces entre distintos sistemas software, tales como interfaces de comunicacin, interfaces software o interfaces de BDs pueden especificarse en un documento de especificacin de interfaces que puede ser referenciado por diferentes SRS.

Ingeniera de requisitos IEEE Std. 830-1998

No es buena idea utilizar los requisitos de usuario en sustitucin de la SRS, ya que
- Puede ser correcta, consistente, verificable y modificable. - Pero no es no ambigua, completa y trazable.

Los beneficios de la especificacin de requisitos software se derivan del concepto de calidad

Ingeniera de requisitos IEEE Std. 830-1998

El IEEE Std. 610.12 define calidad como:
- Grado en que un sistema, componente o proceso cumple las especificaciones. - Grado en que un sistema, componente o proceso cumple las necesidades o deseos de clientes y usuarios.

Ingeniera de requisitos IEEE Std. 830-1998

Sin una SRS es difcil o imposible:
- Disear software. - Validar el software. - Gestionar el proyecto de software.

La SRS es vital para la calidad ya que es el documento que captura los criterios mediante los cuales de mide la calidad

La SRS es la base del desarrollo tcnico Consecuentemente la SRS est inherentemente ligada al desarrollo de software

Ingeniera de requisitos IEEE Std. 830-1998

Audiencia:
- Cliente. La persona o personas que pagan por el producto y usualmente (pero no necesariamente) deciden los requisitos. - Desarrollador. La persona o personas que producen un producto para un cliente. El cliente y el desarrollador pueden pertenecer a la misma organizacin. - Usuario. La persona, o personas que utilizan o interactan directamente con el producto. El usuario y el cliente habitualmente no son la misma persona.

Ingeniera de requisitos IEEE Std. 830-1998

Clientes y desarrolladores deben realizar conjuntamente la SRS, ya que:
- Frecuentemente, los clientes no entienden suficientemente bien las actividades de diseo y desarrollo como para proporcionar una SRS. - Frecuentemente, los desarrolladores no entienden el problema del cliente ni el dominio para especificar los requisitos de un sistema satisfactorio.

Ingeniera de requisitos IEEE Std. 830-1998

Segn el IEEE, la SRS se desarrolla durante la fase de Anlisis de Requisitos Dicha SRS es la entrada de la fase de Diseo La SRS tambin se utiliza en las fases de Implementacin y Prueba Es posible que la SRS tenga que ser actualizada segn avanza el proyecto (GCS)

Ingeniera de requisitos IEEE Std. 830-1998

Descripcin detallada:
Tabla de contenidos 1. Introduccin 1.1 Propsito 1.2 Alcance 1.3 Definiciones,acrnimos y abreviaciones 1.4 Referencias 1.5 Resumen 2. Descripcin general 2.1 Perspectiva del producto 2.2 Funciones del producto 2.3 Caractersticas del usuario 2.4 Restricciones 2.5 Supuestos y dependencias 2.6 Requisitos futuros

Ingeniera de requisitos IEEE Std. 830-1998

3. Requisitos especficos 3.1 Interfaces externos 3.2 Funciones 3.3 Requisitos de rendimiento 3.4 Requisitos de base de datos lgica 3.5 Restricciones de diseo 3.6 Atributos del sistema software Apndices ndice

Ingeniera de requisitos IEEE Std. 830-1998

La Introduccin (1) de la SRS proporciona una descripcin de dicha SRS. La Introduccin debe incluir:
- 1.1 Propsito
- Describe el propsito de la SRS. - Especifica la audiencia de la SRS.

- 1.2 Alcance
- Identifica el producto software por un nombre.

Ingeniera de requisitos IEEE Std. 830-1998

- Explica lo que har, y si es necesario, lo que no har el producto. - Describe el uso del software desarrollado, incluyendo beneficios relevantes y objetivos. - Es consistente con el resto de la SRS.

Ingeniera de requisitos IEEE Std. 830-1998

- 1.4 Referencias
- Proporciona una lista completa de todos los documentos referenciados en la SRS. - Identifica cada documento por ttulo, nmero de informe (si es necesario), fecha y organizacin que lo publica. - Especifica las fuentes donde se pueden obtener las referencias.

- 1.3 Definiciones acrnimos y abreviaturas

- Proporciona las definiciones de todos los trminos.

- 1.5 Resumen
- Describe el resto de la SRS. - Explica cmo est organizada la SRS.

Ingeniera de requisitos IEEE Std. 830-1998

La Descripcin General (2) describe los factores generales que afectan al producto y sus requisitos No define requisitos especficos Proporciona un background para estos requisitos y los hace ms comprensibles

Ingeniera de requisitos IEEE Std. 830-1998

La Descripcin General debe incluir:
- 2.1 Perspectiva del producto
- Define el contexto de implantacin del producto. - Describe adems:
- Interfaces del sistema. Funcionalidad del sistema. - Interfaces de usuario. Caractersticas de configuracin y uso de la interfaz - Interfaces hardware. Caractersticas de cada interfaz entre el software y el hardware.

Ingeniera de requisitos IEEE Std. 830-1998

- Interfaces software. Uso de otros productos software e interfaces (nombre, alias, numero especificacin, nmero versin, origen) - Interfaces de comunicacin. Tales como protocolos de red local, etc. - Memoria. Caractersticas y lmites de las memorias primaria y secundaria. - Operaciones. Modos normales y especiales de operacin por el usuario (e.g. niveles, operaciones de backup) - Requisitos de adaptacin. De instalaciones particulares.

Ingeniera de requisitos IEEE Std. 830-1998

- 2.2 Funciones del producto
- Describe las principales funciones del producto. - Podemos asimilarla a los requisitos de usuario.

- 2.3 Caractersticas de usuario

- Nivel educativo, experiencia, capacidades.

- 2.4 Restricciones
- Polticas de regulacin. - Limitaciones hardware. - Interfaces con otras aplicaciones.

Ingeniera de requisitos IEEE Std. 830-1998

- Operaciones en paralelo. - Funciones de auditoria. - Funciones de control. - Requisitos de lenguaje de alto nivel. - Protocolos de signal handshake. - Requisitos de fiabilidad. - Criticidad de la aplicacin. - Consideraciones de robustez y seguridad.

Ingeniera de requisitos IEEE Std. 830-1998

- 2.5 Supuestos y dependencias
- Factores que afectan a los requisitos.

- 2.6 Requisitos futuros

- Versiones futuras.

Los Requisitos Especficos (3) contienen todos los requisitos del sistema Es el ncleo de la SRS

Ingeniera de requisitos IEEE Std. 830-1998

Caractersticas de los requisitos especficos:
- Deben cumplir las caractersticas de toda SRS (t73). - Referencian a la informacin previa. - Son unvocamente identificables. - Deben organizarse de tal forma que facilite su legibilidad.

Ingeniera de requisitos IEEE Std. 830-1998

Los Requisitos Especficos deben incluir:
- 3.1 Interfaces externas
- Descripcin detallada de todas las entradas y salidas del sistema software. - Debe complementar la descripciones de interfaces de la seccin 2 (Descripcin General). - Debe incluir:
- Nombre del elemento.

- Descripcin del propsito.

- Origen de entrada o destino de salida.

Ingeniera de requisitos IEEE Std. 830-1998

- Rango vlido, precisin y/o tolerancia. - Unidades de medida. - Temporizacin. - Relaciones con otras entradas/salidas. - Organizacin/formatos de pantalla. - Organizacin/formatos de ventana. - Formato de fechas. - Formato de comandos. - Mensajes de fin.

Ingeniera de requisitos IEEE Std. 830-1998

- 3.2 Funciones
- Definen las acciones fundamentales que deben tener lugar en el software durante la aceptacin y procesamiento de la entrada y durante el procesamiento y generacin de la salida. - Incluyen:
- Controles de validez para las entradas. - Secuencia exacta de operaciones. - Respuestas ante situaciones anormales (desbordamiento, comunicacin y manejo y recuperacin de errores)

Ingeniera de requisitos IEEE Std. 830-1998

- Efectos de los parmetros. - Relaciones de salidas a las entradas (secuencias de entrada/salida y formulas de conversin de entrada en salida).

Ingeniera de requisitos IEEE Std. 830-1998

- 3.4 Requisitos de base de datos lgica.
- Requisitos lgicos para cualquier informacin que resida en una base de datos (e.g.):
- Tipos de informacin utilizada por diversas funciones. - Frecuencia de uso. - Capacidades de acceso. - Entidades de datos y sus relaciones. - Restricciones de integridad. - Requisitos de retencin de datos.

- 3.3 Requisitos de rendimiento

- Requisitos numricos estticos (e.g. nmero de terminales, nmero de usuarios, etc.) y dinmicos (e.g. nmero de transacciones por segundo) de rendimiento

Ingeniera de requisitos IEEE Std. 830-1998

- 3.5 Restricciones de diseo
- Impuestas por otros estndares, limitaciones hardware, etc. - Debe indicar si se ajusta a algn estndar.

Ingeniera de requisitos IEEE Std. 830-1998

Los Requisitos Especficos (3) se pueden organizar de diferentes formas:
- Modo del sistema. Caracteriza al sistema en funcin del modo de operacin. - Clase de usuario. Funciones en base al tipo de usuario. - Objetos. Objetos del mundo real.

- 3.6 Atributos del sistema software (e.g.)

- Fiabilidad. - Disponibilidad. - Seguridad. - Mantenibilidad. - Portabilidad.

Ingeniera de requisitos IEEE Std. 830-1998

- Caracterstica. Servicio externo del sistema que puede requerir una secuencia de entradas para producir el resultado esperado (e.g. llamada local). - Estmulo/Respuesta funcional. Describe las funciones en trminos de estmulos/respuestas funcionales (e.g. dibujar). Es muy natural en software con una IGU (Interfaz Grfica de Usuario).

Ingeniera de requisitos IEEE Std. 830-1998

- Jerarqua funcional. Descrito en trminos de una descomposicin funcional.

Se puede elegir la organizacin que ms se ajuste a cada proyecto El estndar proporciona plantillas para cada organizacin

Ingeniera de requisitos IEEE Std. 830-1998

e.g., para la organizacin por estmulos:
3. Requisitos especficos 3.1 Requisitos de interfaces externas 3.2 Requisitos funcionales 3.2.1 Estmulo 1 3.2.1.1 Requisito funcional 1.1 ................................................. 3.2.1.n Requisito funcional 1.n .......................................................... 3.2.m Estmulo m 3.2.m.1 Requisito funcional m.1 ................................................. 3.2.m.k Requisito funcional m.k

Ingeniera de requisitos IEEE Std. 830-1998

3.3 Requisitos de rendimiento 3.4 Restricciones de diseo 3.5 Atributos del sistema software 3.6 Otros requisitos

El estndar no determina el lenguaje en el que se debe describir cada requisito funcional (t63)

Ingeniera de requisitos IEEE Std. 830-1998

Supuesto que elijamos Lenguaje Natural Estructurado, para cada requisito funcional deberamos incluir:
- Descripcin de la funcin. - Descripcin de la entrada y su origen. - Descripcin de la salida y su destino. - Indicacin de otras entidades utilizadas. - Pre y post condiciones. - Efectos laterales, si hay.

Ingeniera de requisitos IEEE Std. 830-1998

e.g.
funcin: prstamo. descripcin: presta un ejemplar a un socio de la biblioteca. entrada: cdigo socio, cdigo ejemplar. salida: fecha devolucin. origen:operador consola. destino: sistema. necesita: base de datos de socios y ejemplares. precondicin: usuario y ejemplar dados de alta, usuario sin prstamos pendientes, usuario sin lmite alcanzado. postcondicion: ejemplar prestado al usuario. efectos laterales: retirar carn durante 7 das si el usuario tiene prstamos pendientes.

Ingeniera de requisitos Gestin de requisitos software

Como ya hemos comentado, los requisitos pueden cambiar y evolucionar, ya que:
- Puede haber requisitos variables en funcin del usuario. - El cliente no suele ser el usuario. - El producto evoluciona.

Ingeniera de requisitos Gestin de requisitos software

La gestin de requisitos es el proceso de entender y controlar los cambios en los requisitos del sistema Tiene en cuenta aspectos tcnicos no contemplados por la Gestin de la Configuracin Software

Ingeniera de requisitos Gestin de requisitos software

Desde un punto de vista evolutivo los requisitos pueden ser:
- Estables. Se derivan de la actividad principal del sistema y estn directamente relacionados con el dominio. - Voltiles. Probablemente cambiarn durante el desarrollo del sistema o despus de su entrega.

Ingeniera de requisitos Gestin de requisitos software

A su vez los voltiles pueden ser:
- Mutables. Cambian debido a cambios en el entorno en el que la organizacin opera (e.g. un nuevo sistema de numeracin de signaturas de las bibliotecas). - Emergentes. Aparecen durante el desarrollo del sistema por el mayor entendimiento por parte del cliente. - De consecuencia. Aparecen por la introduccin del sistema. - De compatibilidad. Dependen de los procesos de negocio de la organizacin.

Ingeniera de requisitos Gestin de requisitos software

En la gestin de requisitos debemos ser capaces de:
- Identificar los requisitos. - Tener un proceso de gestin del cambio. - Disponer de polticas de traza. - Disponer de soporte CASE

Ingeniera de requisitos Gestin de requisitos software

La identificacin de cada requisito se supone al disponer de una SRS El proceso de gestin de cambio es comn al de cualquier Elemento de Configuracin Software (ECS) Las polticas de traza deben llevar cuenta de diversa informacin de traza:

Ingeniera de requisitos Gestin de requisitos software

- De origen. Liga el requisito al stakeholder. - De requisitos. Determina las dependencias entre requisitos. - De diseo. Liga los requisitos a los mdulos de diseo.

Ingeniera de requisitos Gestin de requisitos software

La informacin de traza de requisitos puede representarse mediante una matriz de traza

Una matriz de traza

U: utiliza la informacin R: relacin ms dbil

Ingeniera de requisitos Gestin de requisitos software

Las herramientas CASE facilitan:
- El almacenamiento de requisitos. - La gestin del cambio. - La gestin de la traza.

Conclusiones
Ingeniera de requisitos: fundamental en IS Requisitos de usuario y del sistema

Pueden ser herramientas especficas, o gestionar el cambio de la SRS como el cambio de cualquier otro ECS

Conclusiones
Requisitos funcionales, no funcionales y del dominio Fases en ingeniera de requisitos IEEE Std. 830-1998 Lenguaje requisitos especficos Gestin de requisitos del software Requisitos estables y voltiles