Temas

• Importancia de los Requerimientos

• Elementos del documento del Requerimientos (SRS)
• Características de un buen SRS

IEEE SRS (Software Requirements Specifications)

 Importancia de los
Requerimientos

• Los sistemas siguen fallando

– Retrasos
– Presupuestos no respetados
– Altas expectativas
– Problemas de calidad
– Usuarios no satisfechos
 Importancia de los
Requerimientos

• The Standish Group's CHAOS Reports from 1994 and 1997

established that the most significant contributors to project failure
relate to requirements.
• In December 1997, Computer Industry Daily reported on a Sequent
Computer Systems, Inc. study of 500 IT managers in the U.S. and
U.K. that found 76 percent of the respondents had experienced
complete project failure during their careers. The most frequently
named cause of project failure was "changing user requirements."
 Importancia de los
Requerimientos

• El correcto manejo de los requerimientos es un factor del que

depende el éxito del proyecto
 Definición

• Un requerimiento es una condición o capacidad que el sistema

debe cumplir
• De forma más refinada
– Una capacidad del sistema requerida por el usuario para resolver
un problema o alcanzar un objetivo
– Capacidad que el sistema debe poseer o brindar a fin de
satisfacer un contrato, especificación, estándar o alguna otra
documentación formalmente impuesta
 Elementos del documento del
Requerimientos (SRS)

• En general los siguientes pero se sugiere seleccionar una plantilla del

estándar de la IEEE
1. Enunciado resumen del proyecto
– “El propósito de ester proyecto es crear una terminal de ventas a
ser utilizada en tiendas supermercado”
2. Cliente o Clientes
– Por ejemplo: “Tiendas Ramírez y Asociados.”
 Elementos (cont)

3. Requerimientos funcionales del sistema

– Lo que se supone debe hacer el sistema, como:
1. El sistema debe autorizar créditos OBLIGATORIO
IMPORTANTE: Los requerimientos funcionales en una metodología
orientada a objetos se capturan por medio de casos de uso (siguiente
tema).
4. Otros requerimientos
– Participantes
– Grupos afectados
– Acepciones
– Riesgos
– Glosario
– Casos de uso
– Modelo conceptual
 Creación del SRS

• Los requerimientos del sistema se documentan en el SRS (Software

Requirements Specification)
• El SRS es resultado de la fase de análisis y servirá como contrato
entre el cliente y el desarrollador
• En esta presentación se indican cuáles son los tipos de
requerimientos que deben de cubrirse y las características que debe
de cumplir el documento, según el estándar IEEE Std 830-1993:
IEEE Recommended Practice for Software Requirements
Specifications
 Requerimientos a cubrir

Los siguientes requerimientos pueden capturarse en forma de lista o tabla donde

cada requerimiento tenga un identificador, en el caso de los requerimientos
funcionales se recomienda en vez de la tabla utilizar casos de uso para su
documentación.
• Funcionales
– Qué va a hacer el sistema Interfaces externas
– Cómo interactúa el sistema con el hardware, personas, y otros sistemas
• Desempeño
– Velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperación, etc.
• Atributos
– Portabilidad, mantenimiento, seguridad, etc.
• Limitaciones de diseño
– Estándares, lenguaje de implementación, políticas de integridad de la base de
datos, límite de recursos, sistemas operativos, etc.
Características de un buen SRS

• Correcto
– Los requerimientos son reflejan una necesidad real
– Cada requerimiento es uno que el software deberá implementar
• No ambiguo
– Una sola interpretación
– No usar más de una palabra para un mismo término (pedido u
orden, por ejemplo)
– Glosario si es necesario
 Características de un buen SRS

• Completo
– El SRS es completo si se incluyen todos los requerimientos de
todos los tipos
– Se especificaron todas las respuestas del software a valores de
entrada válidos e inválidos
– Etiquetas y referencias a todas las tablas, figuras, diagramas.
Definición de los términos y unidades de medida.
• En casos muy especiales poner TBD (to be determined) y justificar
cómo se va a eliminar el TBD
 Características de un buen SRS

• Consistente
– Vaya de acuerdo con cualquier otro documento relacionado
– Los requerimientos no entren en conflicto uno con otro (se
contradigan)
– Se usen en los requerimientos distintos términos para la misma
cosa
 Características de un buen SRS

• Ordenables (ranked)
– Por importancia –grado de necesidad- (esenciales, deseables,
etc.)
– por estabilidad (qué tanto se espera que cambie el
requerimiento)
 Características de un buen SRS

• Verificable
– Cada requerimiento es verificable si existe un proceso efectivo
en costos, tal que una persona o máquina pueda llevar a cabo
para validar que software cumpla el requerimiento
 Características de un buen SRS

• Modificable
– Se pueden hacer cambios al SRS fácilmente, completamente
manteniendo el estilo y estructura.
• Organizado en forma fácil de usar con tabla de contenido,
índices, referencias
• No sea redundante, el mismo requerimiento no aparezca más
de una vez
• Cada requerimiento se especifique separadamente (no
mezclar requerimientos)
 Características de un buen SRS

• Rastreble
– Se puede conocer el origen de cada requerimiento
– Facilite referenciar cada requerimientos en futuros documentos
– Para lograr que sea rastrable se sugiere agregar un identificador
a cada requerimiento
Fin de la presentación

IEEE SRS (Software Requirements Specifications)