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

documentos

anlisis negociacin y
LaFHIS - Uchitel y validacin priorizacin 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 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 3

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 4
 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?
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 aos 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 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 7

Standard de IEEE para un SRS

Adaptado de IEEE-STD-830

Identifica el producto y
1 Introduction el dominio de la aplicacin

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 seccin

LaFHIS - Uchitel 8
 IEEE STD Seccin 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 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...

LaFHIS - Uchitel 11

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

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

LaFHIS - Uchitel 15

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

LaFHIS - Uchitel 17

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

LaFHIS - Uchitel 19

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

LaFHIS - Uchitel 21

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)

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

LaFHIS - Uchitel 25

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

LaFHIS - Uchitel 27

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 sol-
tierra salvo que la tapa de los instrumentos pticos no
se encuentre abierta

LaFHIS - Uchitel 29

Ejemplo: Templates/Plantillas

Cada asercin deber ser estructurada con los

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

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

Ocurre durante ejecucin de secuencia crtica F F T T F F T T
No hay respuesta de recuperacin 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 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
Lgica de control
Flujo de datos
Flujo de control
Estructura
Estados y cambios de estado
Comunicacin
...

LaFHIS - Uchitel 32
 Diagramas: rboles de Decisin
Origen en funciones crticas

F T

Ocurre durante ejecucin No hay respuesta de

de secuencia crtica recuperacin de fallas

F T F T

No Reportar No hay respuesta de No Reportar Reportar a

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

Iniciador
Fusionar
Copia de restricciones Restricciones
Pedido de Pedido restricciones para la reunin
reunin invlido

Verificar Consultar Fijar

pedido restricciones Restricciones de cronograma
Pedido
participantes
vlido
Pedido de Notificacin
restricciones de reunin
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 reunin Gestionar de para reunin
restricciones
Rango de
fechas
plazo Rango de todas las
Consultar mximo fechas restricciones
Pedido de restricciones Informar de recibidas
reunin Pedido de restricciones Restricciones
restricciones para reunin
Scheduler Fusionar de
Restricciones restricciones
Participante personales

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

LaFHIS - Uchitel 37

Diagrama de Contexto

Visto previamente...

pedido de restricciones

Iniciador Scheduler Participante

notificacin notificacin
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)

LaFHIS - Uchitel 39

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

Pedido Denegado
[no autorizado]

Recolectando Datos Validando Datos

de Reunin [autorizado] de Reunin

pedido KO pedido OK
Reunin notificada
pedido de debilitar restricciones Restricciones
pedidas

[todas disponibles] notificacin

[hay cronograma
Resolucin de conflictos] fijado
Planificando Reunin planificada
conflictos [no hay
conflictos]

LaFHIS - Uchitel 41

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

LaFHIS - Uchitel 43

Especificaciones Formales
- Lgicas Temporales -
Sintaxis
[] 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.
Ejemplos
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)))
Semntica
Dado una secuencia de valuaciones para elementos atmicos de la
lgica, tenemos un mecanismo preciso para decidir si una frmula es
verdadera

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

LaFHIS - Uchitel 45

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