Sei sulla pagina 1di 17

Temas

Importancia de los Requerimientos


Elementos del documento del Requerimientos (SRS)
Caractersticas 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
Definicin

Un requerimiento es una condicin o capacidad que el sistema


debe cumplir
De forma ms 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, especificacin, estndar o alguna otra
documentacin formalmente impuesta
Elementos del documento del
Requerimientos (SRS)

En general los siguientes pero se sugiere seleccionar una plantilla del


estndar de la IEEE
1. Enunciado resumen del proyecto
El propsito de ester proyecto es crear una terminal de ventas a
ser utilizada en tiendas supermercado
2. Cliente o Clientes
Por ejemplo: Tiendas Ramrez y Asociados.
Elementos (cont)

3. Requerimientos funcionales del sistema


Lo que se supone debe hacer el sistema, como:
1. El sistema debe autorizar crditos OBLIGATORIO
IMPORTANTE: Los requerimientos funcionales en una metodologa
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
Creacin del SRS

Los requerimientos del sistema se documentan en el SRS (Software


Requirements Specification)
El SRS es resultado de la fase de anlisis y servir como contrato
entre el cliente y el desarrollador
En esta presentacin se indican cules son los tipos de
requerimientos que deben de cubrirse y las caractersticas que debe
de cumplir el documento, segn el estndar 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
documentacin.
Funcionales
Qu va a hacer el sistema Interfaces externas
Cmo interacta el sistema con el hardware, personas, y otros sistemas
Desempeo
Velocidad, disponibilidad, tiempo de respuesta, tiempo de recuperacin, etc.
Atributos
Portabilidad, mantenimiento, seguridad, etc.
Limitaciones de diseo
Estndares, lenguaje de implementacin, polticas de integridad de la base de
datos, lmite de recursos, sistemas operativos, etc.
Caractersticas 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 interpretacin
No usar ms de una palabra para un mismo trmino (pedido u
orden, por ejemplo)
Glosario si es necesario
Caractersticas 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 vlidos e invlidos
Etiquetas y referencias a todas las tablas, figuras, diagramas.
Definicin de los trminos y unidades de medida.
En casos muy especiales poner TBD (to be determined) y justificar
cmo se va a eliminar el TBD
Caractersticas 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 trminos para la misma
cosa
Caractersticas de un buen SRS

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

Verificable
Cada requerimiento es verificable si existe un proceso efectivo
en costos, tal que una persona o mquina pueda llevar a cabo
para validar que software cumpla el requerimiento
Caractersticas de un buen SRS

Modificable
Se pueden hacer cambios al SRS fcilmente, completamente
manteniendo el estilo y estructura.
Organizado en forma fcil de usar con tabla de contenido,
ndices, referencias
No sea redundante, el mismo requerimiento no aparezca ms
de una vez
Cada requerimiento se especifique separadamente (no
mezclar requerimientos)
Caractersticas 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 presentacin

IEEE SRS (Software Requirements Specifications)

Potrebbero piacerti anche