1. El Documento de Requerimientos
¿De qué trata el Documento de Requerimientos?
¿Para qué sirve?
¿Qué diferencia tiene este documento con un modelo?
¿Qué técnicas de documentación pueden usarse?
¿Cuáles son sus limitaciones?
Unidad 3
LaFHIS - Uchitel 2
elicitación
y modelado
especificación
stakeholders
documentos
sistemas
existentes
análisis
y validación
Modelos de Requerimientos
Documento de
Requerimientos
negociación y
priorización
Documento de Requerimientos
En la práctica es común describir los requerimientos en un documento
llamado Especificación de Requerimientos del Software (SRS -
Software Requirements Specification)

2. LaFHIS - Uchitel 3
¿Para qué sirve un SRS?
• Comunicar de manera precisa los requerimientos, objetivos y
presunciones del dominio
• Contrato
– legal, documento interno o a modo de memorando
• Base para estimación (tamaño, costo, tiempo) y planificación de
proyecto
• Base para evaluación de producto final
– verificación y validación
– Debería tener suficiente información para decidir si el producto final es aceptable
(satisface los requerimientos)
• Base para el control de cambios
– Requerimientos cambian, software evoluciona, el entorno evoluciona
LaFHIS - Uchitel 4
Lectores de un SRS
• Clientes y Usuarios
– Interesados en validar objetivos del sistema y descripción de alto nivel de la
funcionalidad
– Generalmente no interesados en los requerimientos detallados del sistema.
• Analistas (de sistemas, de requerimientos),
– Escribirán especificaciones de otros sistemas que interactúan con este.
– El SRS sirve mas allá de la puesta en producción!
• Desarrolladores (ej. arquitectos, diseñadores,
programadores, ...)
– Deben implementar los requerimientos
• Testers (V&V’ers)
– Deben determinar la satisfacción de los requerimientos
• Gerentes
– Medir y controlar el proceso desarrollo

3. LaFHIS - Uchitel 5
Más lectores de un SRS
• Equipo de Operaciones
– Deberán dimensionar equipos y procedimientos de rutina.
• Equipo de soporte de usuario
– Desarrollo de plan de capacitación
– Generación de manuales de usuario
– Procedimientos de soporte online
• Legales
– Los que firman los contratos
• Subcontratistas
• Entes reguladores
• ...
¿Cómo se escribe un documento que le
sirva a una audiencia tan variada?
LaFHIS - Uchitel 6
¿Qué es un SRS apropiado?
• Consideremos dos proyectos:
A) Proyecto chico, 1 programador, 6 meses de trabajo
programador habla con el cliente y escribe un memo de 5 hojas
B) Proyecto grande, 50 programadores, 2 años de trabajo
Un equipo de analistas modelan los requerimientos y luego los
documentan en un SRS de 500 paginas

4. LaFHIS - Uchitel 7
Adaptado de IEEE-STD-830
Contenido de un SRS
• Un SRS deberá abarcar:
– Funcionalidad. Que es lo que el software hace?
– Interfases externas. Como debe interactuar con gente, con el
hardware del sistema, con demás hardware y con demás
software?
– Atributos de Calidad.
• Disponibilidad, tiempo de respuesta, tiempo de recuperación
después de fallas, etc..
• Consideraciones de portabilidad, correctitud, precisión,
mantenibilidad, seguridad y mas...
– Restricciones de diseño. Existen estándares a cumplir,
lenguaje de programación, recursos, sistemas operativos,
etc...?
LaFHIS - Uchitel 8
1 Introduction
Purpose
Scope
Definitions, acronyms,
abbreviations
Reference documents
Overview
2 Overall Description
Product perspective
Product functions
User characteristics
Constraints
Assumptions and Dependencies
3 Specific Requirements
Appendices
Index
Standard de IEEE para un SRS
1 Introduction
Purpose
Scope
Definitions, acronyms,
abbreviations
Reference documents
Overview
2 Overall Description
Product perspective
Product functions
User characteristics
Constraints
Assumptions and Dependencies
3 Specific Requirements
Appendices
Index
Identifica el producto y
el dominio de la aplicación
Define el contenido y estructura
del resto del documento
Describe todas las interfaces externas:
sistema, usuario, hardware, software
Resumen de funciones
principales
Cualquier cosa que limitará las
opciones del desarrollador (ej.
regulaciones, limitaciones de
hardware, etc)
La parte principal del documento. IEEE
STD provee 8 esqueletos diferentes
para esta sección
Adaptado de IEEE-STD-830

5. LaFHIS - Uchitel 9
IEEE STD Sección 3 (ejemplo)
3.1 External Interface
Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communication Interfaces
3.2 Functional Requirements
this section organized by mode, user
class, feature, etc. For example:
3.2.1 User Class 1
3.2.1.1 Functional Requirement 1.1
…
3.2.2 User Class 2
3.2.1.1 Functional Requirement 1.1
…
...
3.3 Performance
Requirements
3.4 Design Constraints
3.4.1 Standards compliance
3.4.2 Hardware limitations
etc.
3.5 Software System
Attributes
3.5.1 Reliability
3.5.2 Availability
3.5.3 Security
3.5.4 Maintainability
3.5.5 Portability
3.6 Other Requirements
LaFHIS - Uchitel 10
Ejemplos de Organización de Requerimientos Funcionales
- Sección 3.2. -
• …Estímulo o estado del mundo externo
– ej. Soporte de aterrizaje de aviones: viento, poca nafta, pista corta,...
• …Funcionalidad de alto nivel (top-down)
– ej. llamado en espera, desvío de llamado, llamado en conferencia,
contestador...
• …Output del sistema
– ej. generar recibos de sueldo, reportes de costo, estado de cuentas...
• …Objeto externo
– ej. para una biblioteca, organizar por tipo de libro
• …Tipo de usuario
– ej. Sistema de admin. de proyectos: gerente, técnicos, admines, ...
• …Modo de operación
– ej. un procesador de palabras: page layout, outline, normal, ...
• …Subsistema
– ej. Auto: control, manejo de datos, comunicaciones, entretenimientos, ...

6. LaFHIS - Uchitel 11
Cualidades de un SRS (1)
• Completitud
– con respecto a los objetivos (ver Jackson):
• Req, Dom |= G
• Correspondencia entre el mundo real y G,
• Correspondencia entre el mundo real y Dom
• Completitud de G con respecto al mundo real
– con respecto a inputs: el comportamiento requerido del
software ha sido especificado para todos los inputs posibles.
– con respecto a estructura: no hay secciones rotuladas: “A
completar...”
LaFHIS - Uchitel 12
Cualidades de un SRS (2)
• Pertinencia
– Cada requerimiento y presunción se necesita para la
satisfacción de objetivo
– El SRS no contiene elementos que no están relacionados con
la definición de requerimientos (ej. decisiones de diseño o
implementación)
• Consistencia
– No hay contradicciones en la formulación de objetivos,
requerimientos y presunciones
• “Medibilidad”
– Los requerimientos han sido formulados de manera tal que su
satisfacción pueda ser evaluada de manera no ambigua

7. LaFHIS - Uchitel 13
Cualidades de un SRS (3)
• Precisión (No ambiguo)
– No hay vocabulario ambiguo: cada término está definido y es
usado consistentemente.
– No hay aserciones ambiguas: Objetivos, requerimientos y
presunciones deben estar escritos de manera tal que no
permiten interpretaciones distintas
– No hay responsabilidades ambiguas: la separación de
responsabilidades entre el mundo y el software debe estar
indicado claramente.
• Factibilidad
– Los objetivos y requerimientos deberían ser realizables
dentro del presupuesto y cronogramas dispuestos
LaFHIS - Uchitel 14
Cualidades de un SRS (4)
• “Entendibilidad”
– debe ser entendible por todos los lectores potenciales.
• Trazabilidad
– debe identificar las fuentes de los objetivos, requerimientos, y
presunciones
– debe relacionar requerimientos y presunciones con los objetivos
– debe facilitar referenciar de requerimientos en documentación
futura (diseño, test, casos de test)
• Buena Estructura
– Ítems definidos antes de ser usados, índices, formateo, etc...
• Modificabilidad
– Debe ser fácil de adaptar, extender, o achicar con modificaciones
locales.
– Impacto de modificar un ítem debería ser fácil de estimar

8. LaFHIS - Uchitel 15
Contraejemplos (1)
• Omisión de objetivos y requerimientos faltantes
– No hay un requerimiento sobre estado de las puertas en caso
de emergencia
• Omisión de una reacción a un input
– Qué pasa si la alarma de emergencia es activada mientras las
puertas se cierran
• Requerimientos inadecuados
– “Si un libro no es devuelto a la semana del tercer aviso de
devolución, el usuario negligente será notificado y deberá
pagar una multa de x$”
vs.
– “Si un libro no es devuelto a la semana del tercer aviso de
devolución, x$ serán descontados a modo de multa de la cuenta
corriente del usuario.”
LaFHIS - Uchitel 16
Contraejemplos (2)
• Ruido
– “Cada vagón estará equipado con un panel de información
controlado vía software y con carteles de prohibido fumar en
cada ventana”
• Relleno
– Contenido sin información relevante. Ej. contenido con el
objeto de cumplir estándares.
• Mala Estructura
– Mezclar proceso de compra y préstamo de libros
– Referencias hacia adelante: Múltiples usos de “participante”
para luego introducir la definición de participante.
– Definiciones incidentales: “El sistema enviará minutas a los
participantes (aquellos que asistieron aunque sea parcialmente)
de la reunión.

9. LaFHIS - Uchitel 17
Contraejemplos (3)
• Poca Modificabilidad
– Uso de literales para valores cuantificables.
• Opacidad
– Un requerimiento como:
“el comando de velocidad del tren deberá ser siempre al menos
12kph por encima de la velocidad real del tren”
sin información contextual de por qué, la fuente y el impacto
sobre otros requerimientos.
• No medibilidad
– Los paneles de información serán proveerán información de
manera clara y precisa
LaFHIS - Uchitel 18
Una complicación: Contratación
• Un ‘SRS’ puede ser escrito por...
– …el contratante:
• el SRS sirve para llamar a licitación
• Debe ser suficientemente general para lograr suficientes pliegos…
• … y suficientemente específico para obviar pliegos no razonables.
– …los proveedores potenciales:
• Representa una propuesta para implementar un sistema que satisfaga algún
llamado a propuestas.
• Debe ser suficientemente especifico para demostrar factibilidad y
competencia técnica...
• …pero suficientemente general para no comprometerse demasiado.
– …el desarrollador seleccionado:
• refleja el entendimiento que tiene el desarrollador de las necesidades del
cliente.
• forma la base de una evaluación contractual de la performance del
desarrollador.
– …o por un con consultor independiente en IR.

10. LaFHIS - Uchitel 19
Una complicación: Contratación
• ¿Cuándo licitar/contratar?
– Temprano (etapa conceptual)
• sólo se pueden evaluar las propuestas sobre la aparente
competencia técnica
– Tarde (etapa de especificación de requerimientos
detallados)
• mas trabajo para el contratante; experiencia en IR no
necesariamente existe dentro de la organización
– IEEE recomienda que el SRS sea desarrollado
conjuntamente por el contratante y el desarrollador
LaFHIS - Uchitel 20
Algunas Observaciones
• El SRS será imperfecto
– contendrá inconsistencias y imprecisiones
– omitirá información, hará simplificaciones
• Mejorar la especificación tal vez no sea efectivo (costo
vs. beneficio)
– Análisis de requerimientos tiene un costo
– Para diferentes proyectos, el costo-beneficio es diferente.
• Análisis reduce el riesgo de que las imperfecciones
causen problema serios.
• Estas son muchas veces malas excusas para no invertir
en Ingeniería de Requerimientos

11. LaFHIS - Uchitel 21
Resumen
• Documento de Especificación de
Requerimientos
– Propósitos y audiencias
– Cualidades esperadas, errores y falencias
– Dificultades inherentes a la construcción de un SRS
de calidad
– Concepciones erróneas sobre el SRS
– Contratación
LaFHIS - Uchitel 22
Una Observación Importante
• Siendo el SRS el entregable más importante,
suele tomar un protagonismo desproporcionado
– El SRS no es el fin último de un proceso de IR
• Entendimiento del dominio de aplicación, identificación los
problemas reales existentes, elaboración los sistemas que
los resuelven, etc..
– El SRS no es el único soporte físico a producir
• También los modelos juegan un rol
– El SRS no se comienza a escribir el primer día.
• Hay muchas actividades previas a la generación de la primer
versión de un SRS
– El SRS no es el elemento central para hacer análisis
• Más bien es un documento de referencia, enciclopédico.

12. LaFHIS - Uchitel 23
¿Qué es un Modelo?
• Una descripción (de un problema o solución)...
– precisa
– abstracta
– manipulable formalmente
– interpretable en el mundo real
• Una descripción cuyo fin es lograr mayor
entendimiento
• Una entidad que puedo
– observar desde múltiples ángulos
– Hacerle preguntas (y obtener respuestas)
El Documento de Requerimientos
¿De qué trata el Documento de Requerimientos?
¿Para qué sirve?
¿Qué diferencia tiene este documento con un modelo?
¿Qué técnicas de documentación pueden usarse?
¿Cuáles son sus limitaciones?
Unidad 3

13. LaFHIS - Uchitel 25
Lenguaje Natural
• La técnica más popular
• Ventajas
– No hay límite en cuanto a poder expresivo
– No hay una barrera evidente de comunicación.
– Ningún entrenamiento especial es necesario
• Limitaciones:
– Falta de estructura favorece ruido, referencias futuras,
opacidad, definiciones incidentales, ...
– Información específica puede ser difícil de encontrar
– Ambigüedad : ”Frenado total será activado por cualquier tren
que recibe un comando de aceleración o que entra al sector de
estación a mas de X kmh y cuando el tren que lo precede está a
menos de Y metros”
– Análisis automatizado es imposible
– Provee poco soporte metodológico
LaFHIS - Uchitel 26
Algunas Recomendaciones Generales
• Existen muchas recomendaciones generales orientadas a mejorar
la calidad de una especificación en lenguaje natural. Ejemplos:
– Oraciones cortas
– No incluir en una oración mas de un requerimiento o presunción
– Evitar acrónimos
– Usar ecuaciones para relacionar información cuantitativa
– Usar ejemplos para clarificar aserciones abstractas
– Introducir un glosario/diccionario de datos para tener referencias e
interpretaciones únicas y concisas, además de precisión técnica
– Evitar combinaciones complejas de condiciones (ej. anidamiento y
asociatividad ambigua)
– Introducir figuras para proveer pantallazos
– Ayudar texto con diagramas
• No proveen una forma rigurosa de atacar los problemas de fondo

14. LaFHIS - Uchitel 27
Lenguaje Natural Controlado
• Restricciones gramaticales y de presentación
que buscan forzar el uso de texto simple con el
objeto de
– aumentar entendibilidad
– reducir ambigüedad
– permitir algunos análisis simples de manera
automática
– reducir el uso inconsistente de términos
LaFHIS - Uchitel 28
Ejemplo: Indentación
• El sistema proveerá información comparativa que es oportuna,
itemizada en suficiente detalle como para que variaciones
individuales de importancia no se pierdan entre otras variaciones,
identificación de la fuente de cada variación sea posible, y sea
identificable el área de investigación que maximizará los
beneficios globales
vs.
• El sistema proveerá información comparativa
– La información comparativa será oportuna,
– La información comparativa será itemizada en suficiente detalle como
para que
• Variaciones individuales de importancia no se pierdan entre otras
variaciones,
• Identificación de la fuente de cada variación sea posible
• Sea identificable el área de investigación que maximizará los beneficios
globales

15. LaFHIS - Uchitel 29
Ejemplo: Estructura Gramatical
• Especificación de requerimientos debe tener la
siguiente estructura:
– Localización
– Actor
– Acción
– Objeto/Dueño
– Restricción.
• Ejemplo: Cuando tres o más seguidores de estrellas
pierden su estrella de referencia, la nave
inmediatamente alineará su eje principal con el eje sol-
tierra salvo que la tapa de los instrumentos ópticos no
se encuentre abierta
LaFHIS - Uchitel 30
Ejemplo: Templates/Plantillas
• Cada aserción deberá ser estructurada con los
siguientes campos:
– Identificador
– Categoría
– Especificación
– Criterio de aceptación
– Fuente
– Justificación
– Interacción (positiva/negativa) con otras aserciones
– Prioridad
– ...

16. LaFHIS - Uchitel 31
Tablas de Decisión
“El sistema reportará al operador todas las fallas que se originan
en funciones críticas o que ocurren durante la ejecución de una
secuencia crítica y para las cuales no existen respuestas de
recuperación de fallas.”
(adaptado de la especificación de la base espacial internacional)
TTTFFFFFReportar a Operador?
TTTTFFFFNo hay respuesta de recuperación de fallas
TTFFTTFFOcurre durante ejecución de secuencia crítica
TFTFTFTFOrigen en funcione crítica
LaFHIS - Uchitel 32
Diagramas y Modelos Gráficos
• Altamente estructurados
• Permiten análisis automáticos superficiales
– Eg. Reglas de consistencia sintáctica
• Facilitan comunicación aunque requieren distintos grados de
capacitación previa
• Proveen descripciones concisas y abstractas
• Se complementan en cuanto a foco
– Lógica de control
– Flujo de datos
– Flujo de control
– Estructura
– Estados y cambios de estado
– Comunicación
– ...

17. LaFHIS - Uchitel 33
Diagramas: Árboles de Decisión
Origen en funciones críticas
Ocurre durante ejecución
de secuencia crítica
No hay respuesta de
recuperación de fallas
F
TF
No Reportar
a Operador
No Reportar
a Operador
T
No hay respuesta de
recuperación de fallas
Reportar a
Operador
F T
No Reportar
a Operador
Reportar a
Operador
F T
LaFHIS - Uchitel 34
Diagramas: Flujo de Datos (DFDs)
• Modelado de operaciones del sistema y sus dependencias de datos
– Operaciones modifican datos. Sus inputs y outputs son declarados con
flechas entrantes y salientes
– Componentes son iniciadores o terminadores de flujos de datos
• Error común: Inferir control de flujo a partir del de datos
Iniciador
Participante Participante
Verificar
pedido
Consultar
restricciones
Recolectar
restricciones
Fusionar
restricciones
Fijar
cronogramaRestricciones de
participantes
Pedido de
reunión
Copia de
restriccionesPedido
inválido
Pedido
válido
Restricciones
para la reunión
Pedido de
restricciones
Restricciones
personales
Notificación
de reunión

18. LaFHIS - Uchitel 35
Diagramas: SADT
• “Structured Analysis and Design Technique” (Ross & Schoman, 1977)
• Precursor en diagramas para requerimientos
• Dos diagramas que son vistas duales/complementarias entre si
Actividad
Datos de
entrada
Datos
de salidaComponente
responsable
Datos y eventos
de control
Datos
Actividades
productoras
Actividades
consumidorasRecursos necesarios
para procesamiento
Actividades de control
de integridad
Actigram Datagram
LaFHIS - Uchitel 36
Ejemplo SADT
Gestionar de
restricciones
Consultar
restricciones Informar de
restricciones
Fusionar de
restricciones
Pedido de reunión
Restricciones
para reunión
Rango de
fechas
Rango de
fechas
Pedido de
reunión
Scheduler
Pedido de
restricciones
Participante
Restricciones
personales
Scheduler
Restricciones
para reunión
plazo
máximo
todas las
restricciones
recibidas
Rango de
fechas
Restricciones
para reunión
Fusionar de restricciones
Planificar reunión
Repositorio de restricciones
Controlar validez

19. LaFHIS - Uchitel 37
SADT: Algunas Observaciones
• Diagramas semánticamente ricos (ej. más que DFDs)
– Distingue responsables, dato, restricciones de integridad, etc...
• Criterios de consistencia inter-diagrams.
– Ej. Una actividad del control de un datagrama debe aparecer como
actividad en un actigrama
• Noción de refinamiento gráfico
– Los datos de E/S de una actividad deben aparecer como E/S de
alguna sub-actividad
• Diagramaticamente deficientes
– Dirección absoluta de flechas (o posición absoluta de elementos) suele
no tener relevancia semántica en diagramas modernos
LaFHIS - Uchitel 38
Iniciador Scheduler Participante
pedido de reunión
notificación
pedido de restricciones
notificación
restricciones personales
Diagrama de Contexto
• Visto previamente...

20. LaFHIS - Uchitel 39
Diagramas Estructurales del Dominio
• Ej. Diagramas de clase, modelos entidad relación
• Conceptos: Entidades y Relaciones entre entidades (asociaciones,
subclases, etc)
LaFHIS - Uchitel 40
Diagramas de Secuencia
• Conceptos:
– Tiempo, comunicación o interacción entre agentes
– Descripción basada en ejemplos.

21. LaFHIS - Uchitel 41
Diagramas de Transición de Estados
• Conceptos: Estados, Eventos, Guardas y Transiciones
Recolectando Datos
de Reunión
Pedido Denegado
Validando Datos
de Reunión
Restricciones
pedidas
Planificando Reunión planificada
Reunión notificada
Resolución de
conflictos
[no autorizado]
[autorizado]
pedido OKpedido KO
[todas disponibles]
[hay
conflictos]
pedido de debilitar restricciones
[no hay
conflictos]
cronograma
fijado
notificación
LaFHIS - Uchitel 42
Descripciones Gráficas: Limitaciones
• No describen cual es el propósito. Se quedan en el “qué” y “cómo”
• Requerimientos implícitos
– Justificación de requerimientos implícita o inexistente
– Relación entre requerimientos implícita
• Falta de distinción entre descripción y prescripción
• Imposibilidad de representar múltiples opciones
• Poca guía para el análisis y elaboración
– ¿Criterios de verificación y validación? ¿Grado de completitud?
¿Las descripciones gráficas que hemos visto,
son adecuadas para describir requerimientos?

22. LaFHIS - Uchitel 43
Especificaciones Formales
- Lógica de Primer Orden -
• Sintaxis
– Operadores booleanos (disyunción, conjunción, negación, implicación)
– Variables tipadas
– Cuantificación universal y existencial sobre el universo de instancias
– Predicados booleanos y Funciones
• Ejemplo
– !tr1, tr2: Tren: SigueA(tr1, tr2) -> Dist(tr1, tr2) < Dist-Frenado(tr1)
– SigueA(tr1, tr2) " tr1.via() = tr2.via() && tr1.dirección = tr2.dirección
– DistFrenado(tr) " ....tr1.velocidad()....tr1.peso()...., tr.modelo(), ....
• Semántica
– Dado una valuación para elementos atómicos de la lógica, tenemos un
mecanismo preciso para decidir si una fórmula es verdadera
• Técnicas de manipulación sintáctica que preserven la semántica
– modus ponens, ecadenamiento, instanciación, ...
LaFHIS - Uchitel 44
Especificaciones Formales
- Lógicas Temporales -
• Sintaxis
– [] P : siempre en el futuro vale P.
– <> P : en algún momento en el futuro vale P.
– P U Q : siempre en el futuro vale P hasta que valga Q.
– X P : En el próximo estado vale P.
• Ejemplos
– Presunción: “Una persona esperada a una reunión efectivamente participará de
la reunión si la fecha y lugar de reunión le es conveniente y ha sido notificado
de la reunión”
! p: persona, r: reunión: Esperado(p, r) && Notificado(r, m) &&
Conveniente(r, p) -> <> Participa(p, r)
– Q vale después de que P valga pero antes de que R valga:
[] !P || <>(P && !R U (Q || []!R)))
• Semántica
– Dado una secuencia de valuaciones para elementos atómicos de la
lógica, tenemos un mecanismo preciso para decidir si una fórmula es
verdadera

23. LaFHIS - Uchitel 45
Especificaciones Formales
• Beneficios
– Tienden a facilitar la reducción de problemas clásicos de
especificación de requerimientos como
• ambigüedad, ruido, referencias a futuro, aserciones no medibles
– Proveen mecanismos de análisis más sofisticados: Animación,
verificación de correctitud vía deducción o exploración exhaustiva
– Permiten la generación automática de contraejemplos, casos de falla,
casos de prueba, modelos/vistas alternativas y fragmentos de código
– El proceso de formalización puede ayudar a tener un mejor
entendimiento informal del problema
• Desventajas
– Tienen poder expresivo limitado. Ej. aspectos cuantitativos
– Son difíciles de escribir y de leer. Obtención de especificaciones
consistentes y adecuadas requiere mucho entrenamiento. Inaccesible
para clientes, usuarios, etc.
– Integración limitada de especificaciones con prácticas convencionales
LaFHIS - Uchitel 46
Lo que se viene...
• Un modelo que trata de ...
– resolver limitaciones y combinar beneficios de algunas de las
técnicas de especificación mencionadas
– estructurar conocimiento de una manera alternativa, para
facilitar las actividades de Ingeniería de Requerimientos
• ... el modelo de objetivos