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 tcnicas de documentacin pueden usarse?
Cules son sus limitaciones?

Documento de Requerimientos
En la prctica es comn describir los requerimientos en un documento
llamado Especificacin de Requerimientos del Software (SRS Software Requirements Specification)
Modelos de Requerimientos
especificacin
stakeholders

elicitacin
y modelado

sistemas
existentes

Documento de
Requerimientos

documentos

LaFHIS - Uchitel

anlisis
y validacin

negociacin y
priorizacin

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 estimacin (tamao, costo, tiempo) y planificacin de

proyecto

Base para evaluacin de producto final

verificacin y validacin

Debera tener suficiente informacin 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 descripcin de alto nivel de la

funcionalidad
Generalmente no interesados en los requerimientos detallados del sistema.

Analistas (de sistemas, de requerimientos),

Escribirn especificaciones de otros sistemas que interactan con este.

El SRS sirve mas all de la puesta en produccin!

Desarrolladores (ej. arquitectos, diseadores,

programadores, ...)
Deben implementar los requerimientos

Testers (V&Vers)

Deben determinar la satisfaccin de los requerimientos

Gerentes

Medir y controlar el proceso desarrollo

LaFHIS - Uchitel

Ms lectores de un SRS
Equipo de Operaciones

Debern dimensionar equipos y procedimientos de rutina.

Equipo de soporte de usuario

Desarrollo de plan de capacitacin

Generacin de manuales de usuario
Procedimientos de soporte online

Legales

Los que firman los contratos

Subcontratistas
Entes reguladores
...

Cmo 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 aos de trabajo

Un equipo de analistas modelan los requerimientos y luego los
documentan en un SRS de 500 paginas

LaFHIS - Uchitel

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 dems hardware y con dems
software?
Atributos de Calidad.
Disponibilidad, tiempo de respuesta, tiempo de recuperacin
despus de fallas, etc..
Consideraciones de portabilidad, correctitud, precisin,
mantenibilidad, seguridad y mas...

Restricciones de diseo. Existen estndares a cumplir,

lenguaje de programacin, recursos, sistemas operativos,
etc...?

LaFHIS - Uchitel

Standard de IEEE para un SRS

Adaptado de IEEE-STD-830

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

Identifica el producto y
el dominio de la aplicacin
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 seccin
8

IEEE STD Seccin 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

9

LaFHIS - Uchitel

Ejemplos de Organizacin de Requerimientos Funcionales

- Seccin 3.2. Estmulo 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, desvo 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, tcnicos, admines, ...

Modo de operacin

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

11

LaFHIS - Uchitel

Cualidades de un SRS (2)

Pertinencia
Cada requerimiento y presuncin se necesita para la
satisfaccin de objetivo
El SRS no contiene elementos que no estn relacionados con
la definicin de requerimientos (ej. decisiones de diseo o
implementacin)

Consistencia
No hay contradicciones en la formulacin de objetivos,
requerimientos y presunciones

Medibilidad
Los requerimientos han sido formulados de manera tal que su
satisfaccin pueda ser evaluada de manera no ambigua

LaFHIS - Uchitel

12

Cualidades de un SRS (3)

Precisin (No ambiguo)
No hay vocabulario ambiguo: cada trmino 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 separacin de
responsabilidades entre el mundo y el software debe estar
indicado claramente.

Factibilidad
Los objetivos y requerimientos deberan ser realizables
dentro del presupuesto y cronogramas dispuestos

13

LaFHIS - Uchitel

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 documentacin
futura (diseo, test, casos de test)

Buena Estructura

tems definidos antes de ser usados, ndices, formateo, etc...

Modificabilidad

Debe ser fcil de adaptar, extender, o achicar con modificaciones

locales.
Impacto de modificar un tem debera ser fcil de estimar

LaFHIS - Uchitel

14

Contraejemplos (1)
Omisin de objetivos y requerimientos faltantes

No hay un requerimiento sobre estado de las puertas en caso

de emergencia

Omisin de una reaccin 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

devolucin, 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
devolucin, x$ sern descontados a modo de multa de la cuenta
corriente del usuario.

15

LaFHIS - Uchitel

Contraejemplos (2)
Ruido
Cada vagn estar equipado con un panel de informacin
controlado va software y con carteles de prohibido fumar en
cada ventana

Relleno
Contenido sin informacin relevante. Ej. contenido con el
objeto de cumplir estndares.

Mala Estructura
Mezclar proceso de compra y prstamo de libros
Referencias hacia adelante: Mltiples usos de participante
para luego introducir la definicin de participante.
Definiciones incidentales: El sistema enviar minutas a los
participantes (aquellos que asistieron aunque sea parcialmente)
de la reunin.
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 informacin contextual de por qu, la fuente y el impacto
sobre otros requerimientos.

No medibilidad
Los paneles de informacin sern proveern informacin de
manera clara y precisa

17

LaFHIS - Uchitel

Una complicacin: Contratacin

Un SRS puede ser escrito por...
el contratante:

el SRS sirve para llamar a licitacin

Debe ser suficientemente general para lograr suficientes pliegos
y suficientemente especfico para obviar pliegos no razonables.

los proveedores potenciales:

Representa una propuesta para implementar un sistema que satisfaga algn

llamado a propuestas.
Debe ser suficientemente especifico para demostrar factibilidad y
competencia tcnica...
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 evaluacin contractual de la performance del
desarrollador.

o por un con consultor independiente en IR.

LaFHIS - Uchitel

18

Una complicacin: Contratacin

Cundo licitar/contratar?
Temprano (etapa conceptual)
slo se pueden evaluar las propuestas sobre la aparente
competencia tcnica

Tarde (etapa de especificacin de requerimientos

detallados)
mas trabajo para el contratante; experiencia en IR no
necesariamente existe dentro de la organizacin

IEEE recomienda que el SRS sea desarrollado

conjuntamente por el contratante y el desarrollador

19

LaFHIS - Uchitel

Algunas Observaciones
El SRS ser imperfecto
contendr inconsistencias y imprecisiones
omitir informacin, har simplificaciones

Mejorar la especificacin tal vez no sea efectivo (costo

vs. beneficio)
Anlisis de requerimientos tiene un costo
Para diferentes proyectos, el costo-beneficio es diferente.

Anlisis reduce el riesgo de que las imperfecciones

causen problema serios.
Estas son muchas veces malas excusas para no invertir
en Ingeniera de Requerimientos
LaFHIS - Uchitel

20

Resumen
Documento de Especificacin de
Requerimientos
Propsitos y audiencias
Cualidades esperadas, errores y falencias
Dificultades inherentes a la construccin de un SRS
de calidad
Concepciones errneas sobre el SRS
Contratacin

21

LaFHIS - Uchitel

Una Observacin Importante

Siendo el SRS el entregable ms importante,
suele tomar un protagonismo desproporcionado
El SRS no es el fin ltimo de un proceso de IR

Entendimiento del dominio de aplicacin, identificacin los

problemas reales existentes, elaboracin los sistemas que
los resuelven, etc..

El SRS no es el nico soporte fsico a producir

Tambin los modelos juegan un rol

El SRS no se comienza a escribir el primer da.

Hay muchas actividades previas a la generacin de la primer

versin de un SRS

El SRS no es el elemento central para hacer anlisis

Ms bien es un documento de referencia, enciclopdico.

LaFHIS - Uchitel

22

Qu es un Modelo?
Una descripcin (de un problema o solucin)...

precisa
abstracta
manipulable formalmente
interpretable en el mundo real

Una descripcin cuyo fin es lograr mayor

entendimiento
Una entidad que puedo
observar desde mltiples ngulos
Hacerle preguntas (y obtener respuestas)

23

LaFHIS - Uchitel

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 tcnicas de documentacin pueden usarse?
Cules son sus limitaciones?

Lenguaje Natural
La tcnica ms popular
Ventajas

No hay lmite en cuanto a poder expresivo

No hay una barrera evidente de comunicacin.
Ningn entrenamiento especial es necesario

Limitaciones:

Falta de estructura favorece ruido, referencias futuras,

opacidad, definiciones incidentales, ...
Informacin especfica puede ser difcil de encontrar
Ambigedad : Frenado total ser activado por cualquier tren
que recibe un comando de aceleracin o que entra al sector de
estacin a mas de X kmh y cuando el tren que lo precede est a
menos de Y metros
Anlisis automatizado es imposible
Provee poco soporte metodolgico
25

LaFHIS - Uchitel

Algunas Recomendaciones Generales

Existen muchas recomendaciones generales orientadas a mejorar
la calidad de una especificacin en lenguaje natural. Ejemplos:

Oraciones cortas
No incluir en una oracin mas de un requerimiento o presuncin
Evitar acrnimos
Usar ecuaciones para relacionar informacin cuantitativa
Usar ejemplos para clarificar aserciones abstractas
Introducir un glosario/diccionario de datos para tener referencias e
interpretaciones nicas y concisas, adems de precisin tcnica
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 presentacin
que buscan forzar el uso de texto simple con el
objeto de
aumentar entendibilidad
reducir ambigedad
permitir algunos anlisis simples de manera
automtica
reducir el uso inconsistente de trminos

27

LaFHIS - Uchitel

Ejemplo: Indentacin
El sistema proveer informacin comparativa que es oportuna,
itemizada en suficiente detalle como para que variaciones
individuales de importancia no se pierdan entre otras variaciones,
identificacin de la fuente de cada variacin sea posible, y sea
identificable el rea de investigacin que maximizar los
beneficios globales
vs.

El sistema proveer informacin comparativa

La informacin comparativa ser oportuna,

La informacin comparativa ser itemizada en suficiente detalle como
para que
Variaciones individuales de importancia no se pierdan entre otras
variaciones,
Identificacin de la fuente de cada variacin sea posible
Sea identificable el rea de investigacin que maximizar los beneficios
globales

LaFHIS - Uchitel

28

Ejemplo: Estructura Gramatical

Especificacin de requerimientos debe tener la
siguiente estructura:

Localizacin
Actor
Accin
Objeto/Dueo
Restriccin.

Ejemplo: Cuando tres o ms 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
29

LaFHIS - Uchitel

Ejemplo: Templates/Plantillas
Cada asercin deber ser estructurada con los
siguientes campos:

LaFHIS - Uchitel

Identificador
Categora
Especificacin
Criterio de aceptacin
Fuente
Justificacin
Interaccin (positiva/negativa) con otras aserciones
Prioridad
...

30

Tablas de Decisin
El sistema reportar al operador todas las fallas que se originan
en funciones crticas o que ocurren durante la ejecucin de una
secuencia crtica y para las cuales no existen respuestas de
recuperacin de fallas.
(adaptado de la especificacin de la base espacial internacional)

Origen en funcione crtica

Ocurre durante ejecucin de secuencia crtica

No hay respuesta de recuperacin de fallas

Reportar a Operador?

31

LaFHIS - Uchitel

Diagramas y Modelos Grficos

Altamente estructurados
Permiten anlisis automticos superficiales
Eg. Reglas de consistencia sintctica

Facilitan comunicacin aunque requieren distintos grados de

capacitacin previa
Proveen descripciones concisas y abstractas
Se complementan en cuanto a foco

LaFHIS - Uchitel

Lgica de control
Flujo de datos
Flujo de control
Estructura
Estados y cambios de estado
Comunicacin
...

32

Diagramas: rboles de Decisin

Origen en funciones crticas
F

Ocurre durante ejecucin

de secuencia crtica

No hay respuesta de
recuperacin de fallas

No hay respuesta de
recuperacin de fallas

No Reportar
a Operador

No Reportar
a Operador

Reportar a
Operador

No Reportar
a Operador

Reportar a
Operador

33

LaFHIS - Uchitel

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 comn: Inferir control de flujo a partir del de datos

Iniciador
Pedido de
reunin

Pedido
invlido

Verificar
pedido

Pedido
vlido

Consultar
restricciones
Pedido de
restricciones
Participante

LaFHIS - Uchitel

Fusionar
restricciones

Copia de
restricciones

Restricciones de
participantes

Restricciones
para la reunin

Fijar
cronograma
Notificacin
de reunin

Restricciones
personales

Recolectar
restricciones

Participante
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 de
entrada

Datos y eventos
de control
Actividad

Componente
responsable

Actividades
productoras

Datos
de salida

Actividades de control
de integridad
Datos

Recursos necesarios
para procesamiento

Actividades
consumidoras

35

LaFHIS - Uchitel

Ejemplo SADT
Rango de
fechas
Pedido de reunin
Rango de
fechas
Consultar
restricciones

Pedido de
reunin
Scheduler

Gestionar de
restricciones

plazo
mximo
Pedido de
restricciones

Restricciones
para reunin

Rango de
fechas

Informar de
restricciones

Participante

todas las
restricciones
recibidas

Fusionar de
Restricciones restricciones
personales

Restricciones
para reunin

Scheduler
Controlar validez
Fusionar de restricciones Restricciones
para reunin Planificar reunin
Repositorio de restricciones
LaFHIS - Uchitel

36

SADT: Algunas Observaciones

Diagramas semnticamente ricos (ej. ms 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

Nocin de refinamiento grfico

Los datos de E/S de una actividad deben aparecer como E/S de
alguna sub-actividad

Diagramaticamente deficientes
Direccin absoluta de flechas (o posicin absoluta de elementos) suele
no tener relevancia semntica en diagramas modernos

37

LaFHIS - Uchitel

Diagrama de Contexto
Visto previamente...

pedido de restricciones
Iniciador

notificacin

Scheduler

notificacin

Participante

restricciones personales
pedido de reunin

LaFHIS - Uchitel

38

Diagramas Estructurales del Dominio

Ej. Diagramas de clase, modelos entidad relacin
Conceptos: Entidades y Relaciones entre entidades (asociaciones,
subclases, etc)

39

LaFHIS - Uchitel

Diagramas de Secuencia
Conceptos:
Tiempo, comunicacin o interaccin entre agentes
Descripcin basada en ejemplos.

LaFHIS - Uchitel

40

Diagramas de Transicin de Estados

Conceptos: Estados, Eventos, Guardas y Transiciones

[no autorizado]
Recolectando Datos
de Reunin

[autorizado]
pedido KO

pedido de debilitar restricciones

Resolucin de
conflictos

[hay
conflictos]

Pedido Denegado

Validando Datos
de Reunin
pedido OK
Restricciones
pedidas

Reunin notificada

[todas disponibles]
notificacin
cronograma
fijado
Planificando
Reunin planificada
[no hay
conflictos]

41

LaFHIS - Uchitel

Descripciones Grficas: Limitaciones

Las descripciones grficas que hemos visto,
son adecuadas para describir requerimientos?

No describen cual es el propsito. Se quedan en el qu y cmo

Requerimientos implcitos
Justificacin de requerimientos implcita o inexistente
Relacin entre requerimientos implcita

Falta de distincin entre descripcin y prescripcin

Imposibilidad de representar mltiples opciones
Poca gua para el anlisis y elaboracin
Criterios de verificacin y validacin? Grado de completitud?

LaFHIS - Uchitel

42

Especificaciones Formales
- Lgica de Primer Orden Sintaxis

Operadores booleanos (disyuncin, conjuncin, negacin, implicacin)

Variables tipadas
Cuantificacin 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.direccin = tr2.direccin
DistFrenado(tr) " ....tr1.velocidad()....tr1.peso()...., tr.modelo(), ....

Semntica
Dado una valuacin para elementos atmicos de la lgica, tenemos un
mecanismo preciso para decidir si una frmula es verdadera

Tcnicas de manipulacin sintctica que preserven la semntica

modus ponens, ecadenamiento, instanciacin, ...

43

LaFHIS - Uchitel

Especificaciones Formales
- Lgicas Temporales

Sintaxis

Ejemplos

Semntica
Dado una secuencia de valuaciones para elementos atmicos de la
lgica, tenemos un mecanismo preciso para decidir si una frmula es
verdadera

[] P : siempre en el futuro vale P.

<> P : en algn momento en el futuro vale P.
P U Q : siempre en el futuro vale P hasta que valga Q.
X P : En el prximo estado vale P.
Presuncin: Una persona esperada a una reunin efectivamente participar de
la reunin si la fecha y lugar de reunin le es conveniente y ha sido notificado
de la reunin
! p: persona, r: reunin: Esperado(p, r) && Notificado(r, m) &&
Conveniente(r, p) -> <> Participa(p, r)
Q vale despus de que P valga pero antes de que R valga:
[] !P || <>(P && !R U (Q || []!R)))

LaFHIS - Uchitel

44

Especificaciones Formales
Beneficios
Tienden a facilitar la reduccin de problemas clsicos de
especificacin de requerimientos como
ambigedad, ruido, referencias a futuro, aserciones no medibles

Proveen mecanismos de anlisis ms sofisticados: Animacin,

verificacin de correctitud va deduccin o exploracin exhaustiva
Permiten la generacin automtica de contraejemplos, casos de falla,
casos de prueba, modelos/vistas alternativas y fragmentos de cdigo
El proceso de formalizacin puede ayudar a tener un mejor
entendimiento informal del problema

Desventajas
Tienen poder expresivo limitado. Ej. aspectos cuantitativos
Son difciles de escribir y de leer. Obtencin de especificaciones
consistentes y adecuadas requiere mucho entrenamiento. Inaccesible
para clientes, usuarios, etc.
Integracin limitada de especificaciones con prcticas convencionales
45

LaFHIS - Uchitel

Lo que se viene...
Un modelo que trata de ...
resolver limitaciones y combinar beneficios de algunas de las
tcnicas de especificacin mencionadas
estructurar conocimiento de una manera alternativa, para
facilitar las actividades de Ingeniera de Requerimientos

... el modelo de objetivos

LaFHIS - Uchitel

46