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?
Unidad 3
LaFHIS - Uchitel 2
elicitación y modelado
especificación
stakeholders
documentos
sistemas
existentes
análisis y validación
Modelos de Requerimientos
Documento de
Requerimientos
negociación y priorización
Documento de RequerimientosEn la práctica es común describir los requerimientos en un documentollamado Especificación 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 estimación (tamaño, costo, tiempo) y planificación deproyecto
• 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 4
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 5
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 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 años 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 demás hardware y con demássoftware?
– 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 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 aplicación
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 sección
Adaptado de IEEE-STD-830
LaFHIS - Uchitel 9
IEEE STD Sección 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 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 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 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 oimplementació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 13
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 nopermiten interpretaciones distintas
– No hay responsabilidades ambiguas: la separación deresponsabilidades entre el mundo y el software debe estarindicado claramente.
• Factibilidad– Los objetivos y requerimientos deberían 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 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 modificacioneslocales.
– Impacto de modificar un ítem debería ser fácil de estimar
LaFHIS - Uchitel 15
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 laspuertas 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 cuentacorriente del usuario.”
LaFHIS - Uchitel 16
Contraejemplos (2)
• Ruido– “Cada vagón estará equipado con un panel de información
controlado vía software y con carteles de prohibido fumar encada 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 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 tren”sin información contextual de por qué, la fuente y el impactosobre otros requerimientos.
• No medibilidad– Los paneles de información serán proveerán información de
manera clara y precisa
LaFHIS - Uchitel 18
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 19
Una complicación: Contratación
• ¿Cuándo licitar/contratar?– Temprano (etapa conceptual)
• sólo se pueden evaluar las propuestas sobre la aparentecompetencia técnica
– Tarde (etapa de especificación de requerimientosdetallados)
• mas trabajo para el contratante; experiencia en IR nonecesariamente existe dentro de la organización
– 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á información, hará simplificaciones
• Mejorar la especificación tal vez no sea efectivo (costovs. beneficio)– Análisis de requerimientos tiene un costo– Para diferentes proyectos, el costo-beneficio es diferente.
• Análisis reduce el riesgo de que las imperfeccionescausen problema serios.
• Estas son muchas veces malas excusas para no invertiren Ingeniería de Requerimientos
Top Related