Unidad 3

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?

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)
Modelos de Requerimientos
especificación
stakeholders
elicitación
y modelado

sistemas Documento de
existentes Requerimientos

documentos

análisis negociación y
LaFHIS - Uchitel y validación priorización 2
 ¿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 3

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

LaFHIS - Uchitel 4
 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 5

¿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

LaFHIS - Uchitel 6
 Contenido de un SRS
Adaptado de IEEE-STD-830

• 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 7

Standard de IEEE para un SRS

Adaptado de IEEE-STD-830

Identifica el producto y
1 Introduction el dominio de la aplicación

Purpose
Define el contenido y estructura
Scope del resto del documento
Definitions, acronyms,
abbreviations
Describe todas las interfaces externas:
Reference documents sistema, usuario, hardware, software
Overview
2 Overall Description
Product perspective Resumen de funciones
principales
Product functions
User characteristics Cualquier cosa que limitará las
Constraints opciones del desarrollador (ej.
Assumptions and Dependencies regulaciones, limitaciones de
hardware, etc)
3 Specific Requirements
Appendices La parte principal del documento. IEEE
STD provee 8 esqueletos diferentes
Index para esta sección

LaFHIS - Uchitel 8
 IEEE STD Sección 3 (ejemplo)
3.1 External Interface 3.3 Performance
Requirements Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces 3.4 Design Constraints
3.1.4 Communication Interfaces
3.2 Functional Requirements 3.4.1 Standards compliance
this section organized by mode, user 3.4.2 Hardware limitations
class, feature, etc. For example: etc.
3.2.1 User Class 1 3.5 Software System
3.2.1.1 Functional Requirement 1.1 Attributes
… 3.5.1 Reliability
3.2.2 User Class 2
3.5.2 Availability
3.5.3 Security
3.2.1.1 Functional Requirement 1.1
3.5.4 Maintainability
…
3.5.5 Portability
... 3.6 Other Requirements
LaFHIS - Uchitel 9

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, ...

LaFHIS - Uchitel 10
 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 11

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

LaFHIS - Uchitel 12
 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 13

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

LaFHIS - Uchitel 14
 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 15

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.

LaFHIS - Uchitel 16
 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 17

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.

LaFHIS - Uchitel 18
 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 19

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

LaFHIS - Uchitel 20
 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 21

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.
LaFHIS - Uchitel 22
 ¿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)

LaFHIS - Uchitel 23

Unidad 3

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?
 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 25

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

LaFHIS - Uchitel 26
 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 27

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

LaFHIS - Uchitel 28
 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 29

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
– ...

LaFHIS - Uchitel 30
 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)

Origen en funcione crítica F T F T F T F T

Ocurre durante ejecución de secuencia crítica F F T T F F T T
No hay respuesta de recuperación de fallas F F F F T T T T
Reportar a Operador? F F F F F T T T

LaFHIS - Uchitel 31

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
– ...

LaFHIS - Uchitel 32
 Diagramas: Árboles de Decisión
Origen en funciones críticas

F T

Ocurre durante ejecución No hay respuesta de

de secuencia crítica recuperación de fallas

F T F T

No Reportar No hay respuesta de No Reportar Reportar a

a Operador recuperación de fallas a Operador Operador

F T

No Reportar Reportar a
a Operador Operador

LaFHIS - Uchitel 33

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
Fusionar
Copia de restricciones Restricciones
Pedido de Pedido restricciones para la reunión
reunión inválido

Verificar Consultar Fijar

pedido restricciones Restricciones de cronograma
Pedido
participantes
válido
Pedido de Notificación
restricciones de reunión
Restricciones
personales Recolectar
Participante Participante
restricciones
LaFHIS - Uchitel 34
 Diagramas: SADT
• “Structured Analysis and Design Technique” (Ross & Schoman, 1977)
• Precursor en diagramas para requerimientos
• Dos diagramas que son vistas duales/complementarias entre si

Actigram Datagram
Datos y eventos Actividades de control
Datos de de control de integridad
entrada Actividades
Actividad productoras
Datos Datos
de salida Actividades
Componente consumidoras
responsable Recursos necesarios
para procesamiento

LaFHIS - Uchitel 35

Ejemplo SADT
Rango de
fechas
Restricciones
Pedido de reunión Gestionar de para reunión
restricciones
Rango de
fechas
plazo Rango de todas las
Consultar máximo fechas restricciones
Pedido de restricciones Informar de recibidas
reunión Pedido de restricciones Restricciones
restricciones para reunión
Scheduler Fusionar de
Restricciones restricciones
Participante personales

Scheduler
Controlar validez

Fusionar de restricciones Restricciones

para reunión Planificar reunión
Repositorio de restricciones

LaFHIS - Uchitel 36
 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 37

Diagrama de Contexto

• Visto previamente...

pedido de restricciones

Iniciador Scheduler Participante

notificación notificación
restricciones personales

pedido de reunión

LaFHIS - Uchitel 38
 Diagramas Estructurales del Dominio
• Ej. Diagramas de clase, modelos entidad relación
• Conceptos: Entidades y Relaciones entre entidades (asociaciones,
subclases, etc)

LaFHIS - Uchitel 39

Diagramas de Secuencia

• Conceptos:
– Tiempo, comunicación o interacción entre agentes
– Descripción basada en ejemplos.

LaFHIS - Uchitel 40
 Diagramas de Transición de Estados
• Conceptos: Estados, Eventos, Guardas y Transiciones

Pedido Denegado
[no autorizado]

Recolectando Datos Validando Datos

de Reunión [autorizado] de Reunión

pedido KO pedido OK
Reunión notificada
pedido de debilitar restricciones Restricciones
pedidas

[todas disponibles] notificación

[hay cronograma
Resolución de conflictos] fijado
Planificando Reunión planificada
conflictos [no hay
conflictos]

LaFHIS - Uchitel 41

Descripciones Gráficas: Limitaciones

¿Las descripciones gráficas que hemos visto,

son adecuadas para describir requerimientos?

• 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?

LaFHIS - Uchitel 42
 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 43

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

LaFHIS - Uchitel 44
 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 45

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

LaFHIS - Uchitel 46