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
Documento de Requerimientos

sistemas existentes

documentos

LaFHIS - Uchitel

análisis y validación

negociación y 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

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. – Escribirán especificaciones de otros sistemas que interactúan con este.
– El SRS sirve mas allá de la puesta en producción!

• Analistas (de sistemas, de requerimientos),

• Desarrolladores (ej. arquitectos, diseñadores, programadores, ...) • Testers

(V&V’ers) • Gerentes
– Deben implementar los requerimientos – Deben determinar la satisfacción de los
requerimientos – 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

• Legales

– Desarrollo de plan de capacitación – Generación de manuales de usuario –

Procedimientos de soporte online – Los que firman los contratos

• Subcontratistas • Entes reguladores • ...

¿Cómo se escribe un documento que le sirva a una audiencia tan variada?

5

LaFHIS - Uchitel

¿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

Standard de IEEE para un SRS

Adaptado de IEEE-STD-830

1 Introduction

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

2 Overall Description

Purpose Scope Definitions, acronyms, abbreviations Reference documents Overview

3 Specific Requirements Appendices Index

LaFHIS - Uchitel

Product perspective Product functions User characteristics Constraints Assumptions

and Dependencies

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
8
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.3 Performance Requirements 3.4 Design Constraints

3.4.1 Standards compliance 3.4.2 Hardware limitations etc.

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.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.2.2 User Class 2

3.2.1.1 Functional Requirement 1.1

…

...
LaFHIS - Uchitel

3.6 Other Requirements

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,... – ej.
llamado en espera, desvío de llamado, llamado en conferencia, contestador... – ej.
generar recibos de sueldo, reportes de costo, estado de cuentas... – ej. para una
biblioteca, organizar por tipo de libro – ej. Sistema de admin. de proyectos:
gerente, técnicos, admines, ... – ej. un procesador de palabras: page layout,
outline, normal, ... – ej. Auto: control, manejo de datos, comunicaciones,
entretenimientos, ...

• …Funcionalidad de alto nivel (top-down) • …Output del sistema • …Objeto externo •

…Tipo de usuario

• …Modo de operación • …Subsistema

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” • Trazabilidad
– debe ser entendible por todos los lectores potenciales. – 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) – Ítems
definidos antes de ser usados, índices, formateo, etc... – Debe ser fácil de
adaptar, extender, o achicar con modificaciones locales. – Impacto de modificar un
ítem debería ser fácil de estimar

• Buena Estructura • Modificabilidad

LaFHIS - Uchitel

14
Contraejemplos (1)
• Omisión de objetivos y requerimientos faltantes • Omisión de una reacción a un
input • Requerimientos inadecuados
– No hay un requerimiento sobre estado de las puertas en caso de emergencia – Qué
pasa si la alarma de emergencia es activada mientras las puertas se cierran – “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. • 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. • 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.

– …los proveedores potenciales:

– …el desarrollador seleccionado:

– …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.. • También los modelos
juegan un rol

– El SRS no es el único soporte físico a producir

– El SRS no se comienza a escribir el primer día.

– El SRS no es el elemento central para hacer análisis

• Más bien es un documento de referencia, enciclopédico.
LaFHIS - Uchitel

• Hay muchas actividades previas a la generación de la primer versión de un SRS

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

• Limitaciones:

– No hay límite en cuanto a poder expresivo – No hay una barrera evidente de

comunicación. – Ningún entrenamiento especial es necesario – 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
25

LaFHIS - Uchitel

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 soltierra
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 Ocurre durante ejecución de secuencia crítica No hay

respuesta de recuperación de fallas Reportar a Operador?

F F F F

T F F F

F T F F

T T F F

F F T F

T F T T

F T T T

T T T T

LaFHIS - Uchitel

31

Diagramas y Modelos Gráficos

• Altamente estructurados • Permiten análisis automáticos superficiales • 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 ... – Eg. Reglas de consistencia sintáctica

LaFHIS - Uchitel

32
Diagramas: Árboles de Decisión
Origen en funciones críticas
F T

Ocurre durante ejecución de secuencia crítica

No hay respuesta de recuperación de fallas

F No Reportar a Operador

F No Reportar a Operador

T Reportar a Operador

No hay respuesta de recuperación de fallas

F No Reportar a Operador

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

Verificar pedido

Pedido válido

Consultar restricciones Pedido de restricciones Participante

Restricciones de participantes

Fijar cronograma Notificación de reunión

Restricciones personales

Recolectar restricciones

Participante
34

LaFHIS - Uchitel
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 Datos de entrada Datos y eventos de control Actividad Datos de salida

Datagram Actividades de control de integridad Datos

Actividades productoras

Componente responsable

Recursos necesarios para procesamiento

Actividades consumidoras

LaFHIS - Uchitel

35

Ejemplo SADT
Rango de fechas Pedido de reunión Rango de fechas Consultar restricciones Gestionar
de restricciones Restricciones para reunión

plazo máximo Pedido de restricciones

Rango de fechas

Pedido de reunión Scheduler

Informar de restricciones

todas las restricciones recibidas

Participante

Fusionar de Restricciones restricciones personales

Restricciones para reunión

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 notificación Scheduler notificación Participante

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

[no autorizado] Recolectando Datos de Reunión

Pedido Denegado

[autorizado] pedido KO

Validando Datos de Reunión pedido OK Restricciones pedidas Reunión notificada

pedido de debilitar restricciones

Resolución de conflictos

[hay conflictos]

[todas disponibles] notificación cronograma fijado Planificando Reunión planificada

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

Ejemplos

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