1 Ingeniería de Requisitos Tema 1: Fundamentos de Ingeniería de Requisitos.

1

Ingeniería de Requisitos

Tema 1: Fundamentos de Ingeniería de Requisitos

2

Temas

Definición de Requisito Desarrollo y Administración de Requisitos Características de Requisitos excelentes Los Requisitos desde la perspectiva del

cliente Buenas prácticas de la Ingeniería de

Requisitos.

Definición de Requisito

En el trabajo día a día suele utilizarse el término “Requisito”* sin clara distinción de un tipo específico.

Esto conlleva a la necesidad de su definición más precisa.

* Requisito=Requerimiento

3


Def. IEEE: Incluye la vista del usuario –stakeholder- (externa) y del desarrollador (interna):

1. Una condición o capacidad necesaria por un usuario para resolver un problema o alcanzar un objetivo.

2. Una condición o capacidad que debe ser satisfecha o poseída mediante un sistema o un componente de un sistema para satisfacer un contrato, especificación u otro documento formalmente impuesto.

3. Una representación documentada de una condición o capacidad tal como 1 o 2.

4


Def. Sommerville y Sawyer:

“Los Requisitos son una especificación de lo que debe ser implementado. Son descripciones de cómo el sistema se debe comportar, o de una propiedad o atributo del sistema. Podrían ser restricciones sobre el proceso de desarrollo del sistema”

5


Claramente no hay una definición universal de lo que es un Requisito, para facilitar la comunicación se necesita acordar un conjunto de adjetivos que modifiquen el término Requisito.

Además es importante apreciar el valor de registrar los Requisitos en una forma compartida.

IMPORTANTE: “El equipo debe establecer claramente los tipos de requisitos a fin de lograr comunicación común”

6

Niveles de Requisitos

Tres son los niveles que se suelen utilizar para los Requisitos software:1. Requisitos del Negocio (Business

requirements).2. Requisitos de Usuario (User

Requirements).3. Requisitos Funcionales (Functional

Requirements). Además de los Requisitos No

Funcionales.

7

Niveles de Requisitos

8

Tipos de Requisitos

Contenedores de Requisitos

Requisitos del Negocio

Son los Objetivos de Alto Nivel de la organización o cliente que solicita el sistema.

Típicamente provienen del patrocinador del proyecto, del cliente.

Describen porqué la organización está implementando el sistema.

Suelen documentarse en un Documento de Visión y Alcance.

9

Requisitos de Usuario

Describen los Objetivos de Usuario o Tareas que los usuarios deben ser capaces de realizar con el producto.

Formas valiosas de representarlos son: Casos de Uso, Escenarios y Tablas Evento-Respuesta.

10

Requisitos Funcionales

Especifican la Funcionalidad Software que los desarrolladores deben construir en el producto para habilitar a los usuarios para que cumplan sus Tareas y al hacerlo satisfacer los Objetivos del Negocio.

Suelen llamárseles “Requisitos de comportamiento”.

Se documentan en el “Documento de Especificación de Requisitos Software (DERS)”

11

Otros Requisitos

Requisitos de Sistema: describen requisitos de alto nivel para un producto que contiene múltiples subsistemas (software, hardware, personas)

12

Reglas del Negocio (RN)

Incluyen las políticas corporativas, regulaciones gubernamentales, estándares de la industria, prácticas contables, algoritmos computacionales.

IMPORTANTE: no son en sí mismas Requisitos software porque existen fuera de las fronteras de un típico sistema software. Sin embargo suelen restringir quien puede realizar ciertos casos de uso o dictan que el sistema contenga funcionalidad para cumplir con las reglas pertinentes.

13

Reglas del Negocio (RN)

Alguna veces las RN son el origen de ciertos atributos de calidad que son implementados en funcionalidad.

Por lo que se debe poder trazar la génesis de ciertos requisitos funcionales hacia atrás a una cierta RN.

14

Requisitos No Funcionales

Incluyen Objetivos de Desempeño y Descripciones de Atributos de Calidad.

Los Atributos de Calidad aumentan la descripción de la funcionalidad del producto describiendo las características del mismo en varias dimensiones importantes a usuarios o desarrolladores.

Las características incluyen: usabilidad, portabilidad, integridad, eficiencia y robustez.

15

Requisitos No Funcionales

Otros Requisitos No Funcionales describen interfases entre el sistema y el mundo exterior y restricciones de diseño e implementación.

Las restricciones imponen límites en las opciones disponibles al desarrollador para el diseño y construcción del producto.

16

Features (Características)

Es un conjunto lógicamente relacionado de Requisitos Funcionales que proveen una capacidad al usuario y le posibilita la satisfacción de un objetivo de negocios.

IMPORTANTE: Una lista de “Features” deseados de un producto no es el equivalente a la descripción de las necesidades y sus tareas-de-usuario relacionadas. Un “Feature” puede abarcar múltiples CU. Cada CU requiere la implementación de múltiples Requisitos Funcionales para permitir que el usuario realice la tarea.

17

Ejemplo-Todos los Requisitos

Considere un “Procesador de palabras (PP)”:

RN: “El producto permitirá a los usuarios corregir eficientemente errores ortográficos en el documento”

Feature: el PP incluye un “Corrector ortográfico”.

18

Ejemplo-Todos los Requisitos

RU: “Buscar errores ortográficos”, “Agregar una palabra al diccionario”.

RF: “Buscar y resaltar una palabra con error ortográfico”, “Desplegar un cuadro diálogo con reemplazos sugeridos”, “Reemplazar palabras erróneas con correctas”.

Atributo de calidad: usabilidad: ¿Qué se entiende por “eficiente” en el RN?

19

Requisitos y roles

Los niveles estratégicos y de gestión de la organización definen los RN.

Los RU se deben alinear a los RN. A partir de los RU el analista deriva los RF

que permitirán a los usuarios realizar sus tareas con el producto.

A partir de los RF y RNF los desarrolladores diseñan las soluciones que implementan la funcionalidad requerida y logran los objetivos de calidad y desempeño, dentro los límites que imponen las restricciones.

20

Lo que NO son Requisitos

Los Requisitos no incluyen: Detalles de diseño o implementación Información de planeación del

proyecto. Información de pruebas.

IMPORTANTE: Separe esta información de los Requisitos de tal manera que las actividades de Requisitos se enfoquen en entender lo que los equipos intentan construir.

21

22

Temas

Definición de Requisito Desarrollo y Administración de

Requisitos Características de Requisitos excelentes Los Requisitos desde la perspectiva del


Requisitos.

Desarrollo y Administración de Requisitos

La Ingeniería de Requisitos cubre todas las actividades relacionadas con su Desarrollo y Administración.

23

Desarrollo y Administración de Requisitos-Gráficamente

24

Desarrollo de Requisitos

Comprende todas las actividades involucradas en la obtención, evaluación y documentación de un sistema software, incluyendo:1. Identificar las clases de usuarios del

producto esperadas.2. Levantar las necesidades de individuos que

representan cada clase de usuario.3. Analizar la información recibida de los

usuarios para distinguir objetivos de requisitos funcionales, no funcionales, reglas de negocio, soluciones sugeridas e información extraña.

25

Desarrollo de Requisitos

(Cont…):4. Asignar porciones de los requisitos de alto nivel a

componentes software definidos en la arquitectura del sistema.

5. Entender la importancia relativa de los atributos de calidad.

6. Negociar las prioridades de implementación.7. Traducir las necesidades de usuario recolectadas

en modelos de especificación de requisitos escritos.8. Revisar los requisitos documentados para asegurar

un entendimiento común de los requisitos de usuario y para corregir todos los problemas antes de que el grupo de desarrollo los acepte.

26

La importancia del enfoque iterativo

En el caso de proyectos nuevos el enfoque iterativo es clave para el éxito.

Se debe planear para múltiples ciclos de exploración de requisitos, refinamiento de requisitos de alto nivel en detalles y confirmar su certeza con los usuarios.

27

Administración de Requisitos

Abarca “establecer y mantener un acuerdo con el cliente sobre los requisitos del proyecto software”

El acuerdo está en las especificaciones escritas y los modelos.

28


La aceptación del cliente es la mitad de la ecuación necesaria para la aprobación de los requisitos, la otra mitad es la aceptación de la especificación y el acuerdo de los desarrolladores para construirlos en el producto.

29

Actividades de la Administración de Requisitos

1. Definir la línea base de los Requisitos (una “foto en el tiempo” que representa el cuerpo de los requisitos acordados para el release actual).

2. Revisar los cambios propuestos a los requisitos y evaluar el impacto de cada cambio antes de aprobarlo.

3. Incorporar de forma controlada los cambios aprobados al proyecto.

4. Mantener los planes del proyecto actuales con los Requisitos.

30

Actividades de la Administración de Requisitos

5. Negociar nuevos compromisos basados en el impacto de los cambios de Requisitos.

6. Trazar los Requisitos individuales a los diseños, código fuente y casos de prueba correspondientes.

7. Monitorear el status de los Requisitos y su actividad de cambio a lo largo de todo el proyecto.

31

Desarrollo y Administración de Requisitos

32

33

Temas

Definición de Requisito Desarrollo y Administración de Requisitos Características de Requisitos

excelentes Los Requisitos desde la perspectiva del


Requisitos.

Características de Requisitos Excelentes

En un “mundo ideal” cada RN, RU y RF debería exhibir las siguientes cualidades:

Completo: debe describir completamente la funcionalidad a entregar. Debe contener toda la información necesaria para que el desarrollador diseñe e implemente esa fracción de funcionalidad. Si algo faltare señálelo (TBD-”To be determined”).

34


Correcto: debe describir exactamente la funcionalidad a ser construida. Solamente representantes de usuarios pueden determinar la exactitud de los RU (por eso la importancia de su participación).

35


Factible: debe ser posible implementar cada requisito dentro de las capacidades y limitaciones del sistema y su ambiente operativo. Para esto es importante que el desarrollador trabaje con el analista a lo largo del proyecto. Él puede determinar lo que se puede hacer o no técnicamente o de lo que se puede hacer solamente a un costo muy alto. Las “pruebas de concepto” pueden ayudar en este rubro también.

36


Necesario: cada Requisito debe documentar una capacidad que los clientes realmente necesiten o uno que es requerido para satisfacer un requisito de sistema externo o un estándar. Cada requisito debe partir de una fuente autorizada. Traza cada requisito una “entrada de voz autorizada de cliente” (CU, RN o algún otro origen).

37


Priorizado: se debe asignar una prioridad de implementación a cada RF, Feature o CU para indicar que tan esencial es para un cierto release.

Si todos tuvieran la misma prioridad será difícil para el líder de proyecto responder a recortes de presupuesto, tiempos “ajustados”, pérdida de personal o nuevos requisitos agregados durante el desarrollo.

38


No ambiguos: todos los lectores del requisito deben llegar a una única interpretación consistente de él, pero el lenguaje natural es muy propenso a la ambigüedad.

Los requisitos se deben escribir de forma simple, concisa, en un lenguaje directo apropiado al dominio del usuario. “Comprensibilidad” es un atributo de calidad relacionado con la “no ambigüedad”: los lectores deben ser capaces de entender lo que cada requisito está diciendo. Defina los términos especializados y términos que puedan confundir a los lectores en un glosario.

39


Verificable: busque definir pruebas o estrategias de verificación (inspección o demostración) para determinar si un producto implementa apropiadamente cada requisito.

40

Características de Especificación de Requisitos

Además de requisitos individuales excelente, se requiere que en conjunto exhiban otras características excelente.

41


Completo: ningún requisito o información necesaria debería estar ausente. Enfocarse en tareas de usuario más que en funciones de sistema puede ayudar a evitar falta de completitud.

42


Consistente: requisitos consistentes no tienen conflicto con otros del mismo tipo o con otros de más alto nivel (RN, RS o CU).

Los desacuerdos entre requisitos se deben resolver antes de proceder al desarrollo.

43


Modificable: debes ser capaz de revisar el DERS y mantener una historia de los cambios hechos a cada requisito. Esto implica etiquetar de forma individual cada requisito y expresarlos de forma separada a otros requisitos. En lugar de duplicar establezca referencias cruzadas.

44


Trazable: un requisito trazable se puede enlazar hacia atrás a su origen y hacia adelante a sus elementos de diseño y código fuente que lo implementan y a los casos de prueba que verifican que su implementación es correcta.

45

Siguientes pasos …

Escribe los problemas relacionados con requisitos que has encontrado en tus proyectos. Clasifícalos como de desarrollo o administración de requisitos. ¿Cuál ha sido el impacto que han tenido cada problema y sus causas raíz?

46

47

Temas

Definición de Requisito Desarrollo y Administración de Requisitos Características de Requisitos excelentes Los Requisitos desde la perspectiva

del cliente Buenas prácticas de la Ingeniería de

Requisitos.

Introducción

Lea la siguiente historia. ¿Ha tenido usted alguna experiencia

similar? Comente en el grupo.

48

Introducción

Parte del problema que presenta Gerhard es que no distingue entre RN, RU y RF, porque finalmente él no será un usuario del sistema.

Los usuarios, en cambio, pueden describir las tareas que realizarán con el sistema, pero quizá no podrán describir todos los RF que los desarrolladores deben implementar para posibilitar dichas tareas.

El involucramiento comprometido del usuario es fundamental para el éxito del sistema (práctica común en métodos ágiles).

49

¿Quién es el cliente?

Def.- Es el individuo u organización quien deriva directa o indirectamente beneficios del producto.

Los clientes software incluyen los stakeholders del proyecto que solicitan, pagan, seleccionan, especifican o reciben la salida generada por un producto software.

Los clientes pueden estar a diferente nivel: Ejecutivo: los que definen los RN. Usuario final: los que usan directamente el producto (RU)

El gran problema es que suele ser común que ambos “nunca tengan tiempo” y todo se deja al analista con consecuencias finales fatales: requisitos pobres.

50

¿Quién es el cliente?

En ocasiones ambos tipos de usuarios presentan conflictos porque: el usuario final desconoce el trasfondo de los RN del Ejecutivo y suelen tener conflictos con los desarrolladores que pueden no entender cabalmente las razones del usuario final.

Clara comunicación acerca de los objetivos del proyecto y sus restricciones pueden ayudar a disminuir las tensiones.

El analista de sistemas debe trabajar con representantes claves de usuarios y patrocinadores del producto para reconciliar cualquier conflicto.

51

La paternidad cliente-desarrollador

Excelentes productos software son el resultado de diseños bien ejecutados basados en excelente requisitos.

Requisitos de alta-calidad resultan de la comunicación y colaboración efectiva entre desarrolladores y clientes (una paternidad).

52

La paternidad cliente-desarrollador

La “Carta de los Derechos de los Clientes Software” lista las 10 expectativas que los clientes pueden tener legítimamente respecto a sus interacciones con los clientes y los desarrolladores durante las actividades de Ingeniería de Requisitos.

Cada derecho del cliente implica una responsabilidad de los desarrolladores o analistas.

53

Carta de los Derechos de los Clientes Software-Tiene derecho a…

1. Esperar que los analistas hablen su lenguaje.2. Esperar que los analistas aprendan sobre el

negocio y objetivos del sistema.3. Esperar que los analistas estructuren la

información que les presentas (en especificación de requisitos software) durante el levantamiento de requisitos.

4. Que los analistas expliquen todos los work-products creados durante el proceso de requisitos.

5. Esperar que los analistas y desarrolladores te traten con respeto y mantener una actitud colaborativa y profesional a través de las interacciones

54

Carta de los Derechos de los Clientes Software-Tiene derecho a…

6. Que los analistas y desarrolladores provean ideas y alternativas para tus requisitos y para la implementación del producto.

7. Describir las características del producto que lo harán fácil y disfrutable de utilizar.

8. Dar oportunidades para ajustar tus requisitos para permitir el reuso de componentes software existentes.

9. Recibir estimaciones de “buena-fe” de los costos, impactos y negociaciones cuando solicites un cambio en los requisitos.

10. Recibir un sistema que satisfaga tus necesidades funcionales y de calidad en la medida en que tales necesidades han sido comunicadas y acordadas con los desarrolladores.

55

Carta de las Responsabilidades de los Clientes Software-Eres responsable de…

1. Educar a los analistas y desarrolladores sobre el negocio y definir los términos del dominio.

2. Invertir el tiempo que requiere la provisión de requisitos, clarificarlos e iterativamente obtenerlos.

3. Ser específico y preciso cuando ofrezcas entradas sobre los requisitos del sistema.

4. Tomar decisiones a tiempo sobre los requisitos cuando se te pida.

5. Respetar la evaluación de los desarrolladores sobre el costo y factibilidad de los requisitos.

56

Carta de las Responsabilidades de los Clientes Software-Eres responsable de…

6. En colaboración con los desarrolladores, establecer prioridades para requisitos funcionales, características del sistema o casos de uso.

7. Revisar los documentos de requisitos y evaluar prototipos.

8. Comunicar cambios en los requisitos tan pronto como sabes de ellos.

9. Seguir el procedimiento indicado para la solicitud de cambios de requisitos.

10. Respetar los procesos que los analistas utilizan para Ingeniería de Requisitos.

57

¿Qué con respecto a la firma del “documento de requisitos”?

Muchas organizaciones utilizan una firma del compromiso del documento de requisitos como una señal de la aprobación del cliente de tales requisitos.

Es importante que todos los que firman tengan claro el significado de tal firma, de lo contrario pueden surgir problemas (evitar problemas como “firmé sin leer lo que firmaba…”)

58


Igualmente problemático es el jefe de desarrollo que ve la firma como una forma de “congelar los requisitos”.

Una actitud así de ambas partes ignora la realidad de que es imposible conocer todos los requisitos desde el inicio del proyecto y que los requisitos cambiarán sin lugar a duda.

59


Más importante que firmar es el concepto de establecer una línea base del acuerdo de los requisitos: una imagen de ellos en el tiempo (un milestone).

Con esto se establece que el documento es “el mejor entendimiento actual de los requisitos” y que cualquier cambio tendrá que pasar por el proceso definido de cambios y que implicará una renegociación de los compromisos de costos, tiempos y recursos.

60


Es decir después que el analista define la línea base, colocará los requisitos bajo el control de cambios.

Esto permitirá al equipo modificar el alcance del proyecto cuando sea necesario de una forma controlada que incluya analizar el impacto de cada cambio propuesto.

61

Siguientes pasos …

1. Identifica los clientes responsables de los RN y los RU de tus proyectos. ¿Cuáles puntos de las cartas de derechos y responsabilidades practican? ¿Cuáles no? ¿Porqué?

2. Discute con tus clientes las cartas de derechos y responsabilidades. Ajústala a tu contexto.

3. Escribe una definición de lo que significa la firma para la aprobación de tu documento de requisitos.

62

63

Temas

Definición de Requisito Desarrollo y Administración de Requisitos Características de Requisitos excelentes Los Requisitos desde la perspectiva del


Requisitos.

Buenas prácticas de la Ingeniería de Requisitos

Se pueden dividir en las siguientes: Conocimiento Elicitación de requisitos. Análisis de requisitos Especificación de requisitos. Validación de requisitos. Administración de requisitos. Administración de proyectos.

64

Conocimiento

Los analistas deben recibir entrenamiento en IR.

Todos los stakeholders del proyecto deberían entender los conceptos y prácticas de la IR.

Un buen analista de requisitos es paciente y bien organizado, tiene habilidades interpersonales y de comunicación efectivas, entiende el dominio de la aplicación y tiene un buen bagaje de técnicas de IR.

65

Buenas prácticas de Elicitación de requisitos

Definir el proceso de desarrollo de requisitos: como se levantarán, analizarán, especificaran y validarán los requisitos.

Escribir el documento de visión y alcance: centrado en los RN.

Identificar clases de usuarios y sus características.

Seleccionar un campeón de producto por cada tipo de usuario.

Trabaja con representantes de usuarios para identificar los CU.

66

Buenas prácticas de Elicitación de requisitos

Manejar talleres de requisitos. Observar a los usuarios

realizando sus trabajos. Examinar reportes de

problemas de los sistemas actuales para ideas de requisitos.

Reutilizar requisitos a través de todos los proyectos.

67

Buenas prácticas de Análisis de requisitos

El Análisis de Requisitos implica refinar los requisitos para asegurarse de que todos los stakeholders los entienden y escudriñan para localizar errores, omisiones u otras deficiencias.

El Análisis incluye descomponer requisitos de alto-nivel en detalles, construir prototipos, evaluar factibilidad y negociar prioridades.

El objetivo es desarrollar los requisitos con suficiente calidad y detalle que los administradores puedan construir estimaciones realistas del proyecto y el staff técnico pueda diseñar, construir y probar.

68


Frecuentemente es útil representar los requisitos en múltiples formas (textual o gráfica). Estas vistas diferentes revelan aspectos internos y problemas que una sola vista no puede proveer.

69


Las múltiples representaciones conllevan a las prácticas de Análisis de Requisitos: Construir el Diagrama de Contexto. Crear el Diccionario de Datos. Modelar los requisitos. Crear prototipos técnicos e interfases de usuario. Priorizar los requisitos. Asignar los requisitos a los subsistemas.

70

Buenas prácticas de Especificación de requisitos

No importa como se obtienen los requisitos, se deben documentar de una forma consistente, accesible y revisable.

71

Buenas prácticas de Especificación de requisitos

Adoptar una plantilla del Documento de Especificación de Requisitos Software (DERS).

Identificar las fuentes de los requisitos. Etiquetar de forma única cada requisito. Registrar las Reglas del Negocio. Especificar los Atributos de Calidad

(desempeño, eficiencia, confiabilidad, usabilidad, etc.).

72

Buenas prácticas de Validación de requisitos

La Validación asegura que los estatutos de requisitos son correctos, que demuestran las características de calidad deseadas y que satisfacerán las necesidades de los usuarios.

73

Buenas prácticas de Validación de requisitos

Inspección de los documentos de requisitos: un pequeño equipo multidisciplinario (analistas, clientes, desarrolladores y testers) examina el DERS, modelos, etc. buscando defectos.

Probar los requisitos: crear, ejecutar los casos de prueba para validar los requisitos.

Definir el criterio de aceptación: pedir a los usuarios que describan como determinarán si el producto satisface sus necesidades.

74


Una vez que se cuenta con el cuerpo inicial de requisitos, lo siguiente es definir mecanismos que permitan manejar de forma organizada los inevitables cambios.

La Administración efectiva de Cambios demanda un proceso para proponer cambios y evaluar su potencial costo e impacto en el proyecto.

75


La figura del Change Control Board (CCB) decide cuales cambios incorporar.

El CCB está compuesto por stakeholders clave.

También es importante monitorear el status de cada requisito conforme pasa del desarrollo a las pruebas (su ciclo de vida).

Aquí se pueden utilizar las mismas prácticas de gestión de configuración (control de cambios) que se utilizan para el código.

76

Buenas prácticas de Administración de Requisitos

Definir un proceso de control de cambios de requisitos.

Establecer un CCB. Realizar análisis de impacto de los

cambios de requisitos. Establecer líneas base y control de

versiones de los documentos de requisitos. Mantener una historia de los cambios de

requisitos. Monitorear el status de cada requisito.

77

Buenas prácticas de Administración de Requisitos

Medir la volatilidad de los requisitos. Usar una herramienta de gestión de

requisitos. Crear una matriz de trazabilidad de

requisitos.

78

Administración de Proyectos

Los procesos de Administración de Proyectos están muy relacionados con los procesos de Administración de Requisitos.

Basa los recursos del proyecto, sus cronogramas y compromisos en los requisitos que se van a implementar.

Como los cambios de requisitos afectarán los planes del proyecto, los planes deberían anticipar cambios de requisitos y alcance.

79

Buenas prácticas de Admon. De Proyectos (en relación con requisitos)

Selecciona un ciclo de vida de desarrollo de software apropiado (cascada, iterativo, etc.).

Basa los planes del proyecto en los requisitos. Renegocia los compromisos del proyecto cuando

los requisitos cambien. Documenta y gestiona los riesgos relacionados

con los requisitos. Monitorea el esfuerzo invertido en IR. Revisa las lecciones aprendidas respecto a los

requisitos de tus proyectos.

* Muchas de las prácticas que sugiere PMP soportan estás buenas prácticas.

80

Iniciando con las Buenas Prácticas

Aunque todas las prácticas pueden ser benéficas, se puede empezar con aquellas que tienen alto impacto y que resultan fáciles de implementar.

Revise la siguiente tabla.

81

Un proceso de Desarrollo de Requisitos

No se espera que todas las prácticas se realicen de forma secuencial.

En la práctica se realizan entrelazadas, incrementales e iterativas

82


Típicamente, como analista:1. Haces preguntas, escuchas

respuestas. Ves lo que se hace (elicitación).

2. Procesas la información para entenderla, la clasificas en categorías y relacionas necesidades y requisitos software (análisis).

83


Además, como analista:3. Estructuras la entrada del cliente y

derivas requisitos como documentos escritos y diagramas (especificación).

4. Finalmente pedirás a representes de clientes que confirmen que lo que has escrito es correcto y completo y corriges cualquier error (validación)

84

Un proceso de Desarrollo de Requisitos iterativo-Gráficamente

85

Un proceso de Desarrollo de Requisitos basado en CU priorizados

86

Realizar por cada incremento o

release

Realizar 1 vez al inicio del proyecto

1 Ingeniería de Requisitos Tema 1: Fundamentos de Ingeniería de Requisitos.

Documents

Transcript of 1 Ingeniería de Requisitos Tema 1: Fundamentos de Ingeniería de Requisitos.