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?
Unidad 3
LaFHIS - Uchitel 2
elicitacin y modelado
especificacin
stakeholders
documentos
sistemas
existentes
anlisis y validacin
Modelos de Requerimientos
Documento de
Requerimientos
negociacin y priorizacin
Documento de RequerimientosEn la prctica es comn describir los requerimientos en un documentollamado Especificacin de Requerimientos del Software (SRS -Software Requirements Specification)
LaFHIS - Uchitel 3
Para qu sirve un SRS?
Comunicar de manera precisa los requerimientos, objetivos ypresunciones del dominio
Contrato legal, documento interno o a modo de memorando
Base para estimacin (tamao, costo, tiempo) y planificacin deproyecto
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 4
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 5
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 6
Qu es un SRS apropiado?
Consideremos dos proyectos:A) Proyecto chico, 1 programador, 6 meses de trabajo
programador habla con el cliente y escribe un memo de 5 hojas
B) Proyecto grande, 50 programadores, 2 aos de trabajoUn equipo de analistas modelan los requerimientos y luego los
documentan en un SRS de 500 paginas
LaFHIS - Uchitel 7
Adaptado de IEEE-STD-830
Contenido de un SRS
Un SRS deber abarcar: Funcionalidad. Que es lo que el software hace? Interfases externas. Como debe interactuar con gente, con el
hardware del sistema, con dems hardware y con demssoftware?
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 8
1 IntroductionPurposeScopeDefinitions, acronyms,
abbreviationsReference documentsOverview
2 Overall DescriptionProduct perspectiveProduct functionsUser characteristicsConstraintsAssumptions and Dependencies
3 Specific RequirementsAppendicesIndex
Standard de IEEE para un SRS
1 IntroductionPurposeScopeDefinitions, acronyms,
abbreviationsReference documentsOverview
2 Overall DescriptionProduct perspectiveProduct functionsUser characteristicsConstraintsAssumptions and Dependencies
3 Specific RequirementsAppendicesIndex
Identifica el producto yel dominio de la aplicacin
Define el contenido y estructuradel resto del documento
Describe todas las interfaces externas:sistema, usuario, hardware, software
Resumen de funcionesprincipales
Cualquier cosa que limitar lasopciones del desarrollador (ej.regulaciones, limitaciones de
hardware, etc)
La parte principal del documento. IEEESTD provee 8 esqueletos diferentes
para esta seccin
Adaptado de IEEE-STD-830
LaFHIS - Uchitel 9
IEEE STD Seccin 3 (ejemplo)
3.1 External InterfaceRequirements
3.1.1 User Interfaces3.1.2 Hardware Interfaces3.1.3 Software Interfaces3.1.4 Communication Interfaces
3.2 Functional Requirementsthis 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 PerformanceRequirements
3.4 Design Constraints3.4.1 Standards compliance
3.4.2 Hardware limitations
etc.
3.5 Software SystemAttributes
3.5.1 Reliability3.5.2 Availability3.5.3 Security3.5.4 Maintainability3.5.5 Portability
3.6 Other Requirements
LaFHIS - Uchitel 10
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 11
Cualidades de un SRS (1)
Completitud con respecto a los objetivos (ver Jackson):
Req, Dom |= G
Correspondencia entre el mundo real y G,
Correspondencia entre el mundo real y Dom
Completitud de G con respecto al mundo real
con respecto a inputs: el comportamiento requerido delsoftware ha sido especificado para todos los inputs posibles.
con respecto a estructura: no hay secciones rotuladas: Acompletar...
LaFHIS - Uchitel 12
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 oimplementacin)
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 13
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 nopermiten interpretaciones distintas
No hay responsabilidades ambiguas: la separacin deresponsabilidades entre el mundo y el software debe estarindicado claramente.
Factibilidad Los objetivos y requerimientos deberan ser realizables
dentro del presupuesto y cronogramas dispuestos
LaFHIS - Uchitel 14
Cualidades de un SRS (4)
Entendibilidad debe ser entendible por todos los lectores potenciales.
Trazabilidad debe identificar las fuentes de los objetivos, requerimientos, y
presunciones debe relacionar requerimientos y presunciones con los objetivos debe facilitar referenciar de requerimientos en 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 modificacioneslocales.
Impacto de modificar un tem debera ser fcil de estimar
LaFHIS - Uchitel 15
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 laspuertas se cierran
Requerimientos inadecuados Si un libro no es devuelto a la semana del tercer aviso de
devolucin, el usuario negligente ser notificado y deberpagar 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 cuentacorriente del usuario.
LaFHIS - Uchitel 16
Contraejemplos (2)
Ruido Cada vagn estar equipado con un panel de informacin
controlado va software y con carteles de prohibido fumar encada 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 17
Contraejemplos (3)
Poca Modificabilidad Uso de literales para valores cuantificables.
Opacidad Un requerimiento como:
el comando de velocidad del tren deber ser siempre al menos12kph por encima de la velocidad real del trensin informacin contextual de por qu, la fuente y el impactosobre otros requerimientos.
No medibilidad Los paneles de informacin sern proveern informacin de
manera clara y precisa
LaFHIS - Uchitel 18
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 19
Una complicacin: Contratacin
Cundo licitar/contratar? Temprano (etapa conceptual)
slo se pueden evaluar las propuestas sobre la aparentecompetencia tcnica
Tarde (etapa de especificacin de requerimientosdetallados)
mas trabajo para el contratante; experiencia en IR nonecesariamente existe dentro de la organizacin
IEEE recomienda que el SRS sea desarrolladoconjuntamente por el contratante y el desarrollador
LaFHIS - Uchitel 20
Algunas Observaciones
El SRS ser imperfecto contendr inconsistencias y imprecisiones omitir informacin, har simplificaciones
Mejorar la especificacin tal vez no sea efectivo (costovs. beneficio) Anlisis de requerimientos tiene un costo Para diferentes proyectos, el costo-beneficio es diferente.
Anlisis reduce el riesgo de que las imperfeccionescausen problema serios.
Estas son muchas veces malas excusas para no invertiren Ingeniera de Requerimientos
LaFHIS - Uchitel 21
Resumen
Documento de Especificacin deRequerimientos 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 22
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 quelos 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 23
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 mayorentendimiento
Una entidad que puedo observar desde mltiples ngulos Hacerle preguntas (y obtener respuestas)
El Documento de Requerimientos
De qu trata el Documento de Requerimientos?Para qu sirve?
Qu diferencia tiene este documento con un modelo?Qu tcnicas de documentacin pueden usarse?
Cules son sus limitaciones?
Unidad 3
LaFHIS - Uchitel 25
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 deestacin a mas de X kmh y cuando el tren que lo precede est amenos de Y metros
Anlisis automatizado es imposible Provee poco soporte metodolgico
LaFHIS - Uchitel 26
Algunas Recomendaciones Generales
Existen muchas recomendaciones generales orientadas a mejorarla 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 27
Lenguaje Natural Controlado
Restricciones gramaticales y de presentacinque buscan forzar el uso de texto simple con elobjeto de aumentar entendibilidad reducir ambigedad permitir algunos anlisis simples de manera
automtica reducir el uso inconsistente de trminos
LaFHIS - Uchitel 28
Ejemplo: Indentacin
El sistema proveer informacin comparativa que es oportuna,itemizada en suficiente detalle como para que variacionesindividuales de importancia no se pierdan entre otras variaciones,identificacin de la fuente de cada variacin sea posible, y seaidentificable el rea de investigacin que maximizar losbeneficios 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 29
Ejemplo: Estructura Gramatical
Especificacin de requerimientos debe tener lasiguiente estructura: Localizacin Actor Accin Objeto/Dueo Restriccin.
Ejemplo: Cuando tres o ms seguidores de estrellaspierden su estrella de referencia, la naveinmediatamente alinear su eje principal con el eje sol-tierra salvo que la tapa de los instrumentos pticos nose encuentre abierta
LaFHIS - Uchitel 30
Ejemplo: Templates/Plantillas
Cada asercin deber ser estructurada con lossiguientes campos: Identificador Categora Especificacin Criterio de aceptacin Fuente Justificacin Interaccin (positiva/negativa) con otras aserciones Prioridad ...
LaFHIS - Uchitel 31
Tablas de DecisinEl sistema reportar al operador todas las fallas que se originanen funciones crticas o que ocurren durante la ejecucin de unasecuencia crtica y para las cuales no existen respuestas derecuperacin de fallas.
(adaptado de la especificacin de la base espacial internacional)
TTTFFFFFReportar a Operador?TTTTFFFFNo hay respuesta de recuperacin de fallas
TTFFTTFFOcurre durante ejecucin de secuencia crtica
TFTFTFTFOrigen en funcione crtica
LaFHIS - Uchitel 32
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 33
Diagramas: rboles de DecisinOrigen en funciones crticas
Ocurre durante ejecucin
de secuencia crtica
No hay respuesta de
recuperacin de fallas
F
TF
No Reportar
a Operador
No Reportar
a Operador
T
No hay respuesta de
recuperacin de fallas
Reportar a
Operador
F T
No Reportar
a Operador
Reportar a
Operador
F T
LaFHIS - Uchitel 34
Diagramas: Flujo de Datos (DFDs)
Modelado de operaciones del sistema y sus dependencias de datos Operaciones modifican datos. Sus inputs y outputs son declarados con
flechas entrantes y salientes Componentes son iniciadores o terminadores de flujos de datos
Error comn: Inferir control de flujo a partir del de datos
Iniciador
Participante Participante
Verificar
pedido
Consultar
restricciones
Recolectar
restricciones
Fusionar
restricciones
Fijar
cronogramaRestricciones de
participantes
Pedido de
reunin
Copia de
restriccionesPedido
invlido
Pedido
vlido
Restricciones
para la reunin
Pedido de
restriccionesRestricciones
personales
Notificacin
de reunin
LaFHIS - Uchitel 35
Diagramas: SADT
Structured Analysis and Design Technique (Ross & Schoman, 1977) Precursor en diagramas para requerimientos Dos diagramas que son vistas duales/complementarias entre si
Actividad
Datos de
entrada
Datos
de salidaComponente
responsable
Datos y eventos
de control
Datos
Actividades
productoras
Actividades
consumidorasRecursos necesarios
para procesamiento
Actividades de control
de integridad
Actigram Datagram
LaFHIS - Uchitel 36
Ejemplo SADT
Gestionar de
restricciones
Consultar
restricciones Informar de
restricciones
Fusionar de
restricciones
Pedido de reunin
Restricciones
para reunin
Rango de
fechas
Rango de
fechas
Pedido de
reunin
Scheduler
Pedido de
restricciones
ParticipanteRestricciones
personales
Scheduler
Restricciones
para reunin
plazo
mximotodas las
restricciones
recibidas
Rango de
fechas
Restricciones
para reunin
Fusionar de restricciones
Planificar reunin
Repositorio de restricciones
Controlar validez
LaFHIS - Uchitel 37
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 dealguna sub-actividad
Diagramaticamente deficientes Direccin absoluta de flechas (o posicin absoluta de elementos) suele
no tener relevancia semntica en diagramas modernos
LaFHIS - Uchitel 38
Iniciador Scheduler Participante
pedido de reunin
notificacin
pedido de restricciones
notificacin
restricciones personales
Diagrama de Contexto
Visto previamente...
LaFHIS - Uchitel 39
Diagramas Estructurales del Dominio
Ej. Diagramas de clase, modelos entidad relacin Conceptos: Entidades y Relaciones entre entidades (asociaciones,
subclases, etc)
LaFHIS - Uchitel 40
Diagramas de Secuencia
Conceptos: Tiempo, comunicacin o interaccin entre agentes Descripcin basada en ejemplos.
LaFHIS - Uchitel 41
Diagramas de Transicin de Estados
Conceptos: Estados, Eventos, Guardas y Transiciones
Recolectando Datos
de Reunin
Pedido Denegado
Validando Datos
de Reunin
Restricciones
pedidas
Planificando Reunin planificada
Reunin notificada
Resolucin de
conflictos
[no autorizado]
[autorizado]
pedido OKpedido KO
[todas disponibles]
[hay
conflictos]
pedido de debilitar restricciones
[no hay
conflictos]
cronograma
fijado
notificacin
LaFHIS - Uchitel 42
Descripciones Grficas: Limitaciones
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?
Las descripciones grficas que hemos visto,son adecuadas para describir requerimientos?
LaFHIS - Uchitel 43
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 44
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 notificadode 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 esverdadera
LaFHIS - Uchitel 45
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 mejorentendimiento 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. Inaccesiblepara clientes, usuarios, etc.
Integracin limitada de especificaciones con prcticas convencionales
LaFHIS - Uchitel 46
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
Top Related