Este documento presenta un resumen de la Norma IEEE 830 para la Especificación de Requerimientos de Software. La norma provee lineamientos para la elaboración de un documento llamado Especificación de Requerimientos de Software (SRS) que describe claramente lo que un cliente desea de un software. El SRS es útil para definir las necesidades del cliente, facilitar el desarrollo del software, y establecer las bases para un contrato. La norma también describe las características que debe tener un buen SRS, como ser correcto, no ambiguo, completo, consistente

1. NORMA IEEE 830 PARA
ESPECIFICACIÓN DE
REQUERIMIENTOS DE
SOFTWARE
AYODORO BALTAZAR LEONEL
CORONADO ROJAS GRACIELA
GARCIA TORRES CESAR

2. IEEE 830



El estándar 830-1998 fue generado por un equipo
de trabajo del IEEE (Instituto de Ingenieros Eléctricos
y Electrónicos), su finalidad es la integración de los
requerimientos del sistema desde la perspectiva del
usuario, cliente y desarrollador.
El propósito principal es ayudarnos a elaborar un
documento muy útil: el SRS (Especificación de
Requerimientos de Software).
Es esencialmente una guía para redacción.

3. IEEE 830

Quién la puede usar:
 Un
cliente/usuario que vaya a definir requerimientos
(características) de un software que necesite
 Un
desarrollador (interno/externo) que haga software
“a la medida” mediante proyecto
 Un
desarrollador que haga software “de paquete” que
se venda masivamente

4. IEEE 830 SIRVE PARA:

Un cliente describa claramente lo que quiere

Un proveedor entienda claramente lo que el cliente quiere

Se establezcan bases para un contrato de desarrollo (o de compra-venta)

Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos)

Se tenga una base o referencia para validar o probar el software solicitado

Se facilite el traspaso del software a otros clientes/usuarios

Se le puedan hacer mejoras (o innovaciones) a ese software

5. CONSIDERACIONES PARA REDACTAR
EL SRS








Su naturaleza
Su ambiente
Características deseables del documento
Preparación conjunta del SRS
Evolución del documento
Prototipos
Diseño “implícito” en el SRS
Requerimientos de proyecto “implícitos”

6. NATURALEZA DEL SRS





El SRS es una especificación para un producto de
software en particular, ya sea un sólo programa, o un
conjunto de programas, que realicen ciertas funciones
en un ambiente específico
A veces el usuario no sabe si necesitará un solo
programa o más de uno
El SRS puede escribirse por uno o más representantes
del proveedor, uno o más del cliente, o por ambos
Lo más recomendable es que haya representantes de
ambas partes
El usuario/cliente puede redactar un borrador inicial y
después revisarlo con el proveedor

7. NATURALEZA DEL SRS





Funcionalidades deseadas
Interfaces externas
Desempeño
Atributos
(seguridad, portabilidad, mantenibilidad, etc.)
Restricciones de diseño impuestas a la
implementación (estándares técnicos propios o
internacionales, lenguaje de progr., sistema
operativo, límites de recursos, políticas internas).

8. AMBIENTE DEL SRS




El SRS es la fuente principal para hacer el plan detallado de un
proyecto de software
Un SRS puede referirse a los requerimientos deseados de todos los
componentes de un sistema grande, o a componentes (módulos)
individuales del mismo
Si se hacen SRS por separado para varios módulos, tiene que
mantenerse la consistencia en los documentos
Si un software necesita interactuar con otro, tienen que especificarse
los requerimientos de esa interacción (interfaces), definiendo sus
funcionalidades y el nivel de desempeño deseado

9. CARACTERÍSTICAS DE UN BUEN SRS








Correcto
No ambiguo
Completo
Consistente
Ordenado con base en importancia y/o
estabilidad
Verificable
Modificable
Rastreable

10. CARACTERISITICAS DE UN BUEN SRS
CORRECTEZ


El SRS es correcto si los
requerimientos escritos son
aquellos que el software
deberá cumplir.
No hay un método para
saber si el SRS es
correcto; lo importante es
que se pida lo que
realmente se necesita.
NO AMBIGUO


Un SRS es no ambiguo si cada
requerimiento establecido en él
tiene una sola interpretación
posible,
tanto
por
el
cliente/usuario como por el
desarrollador
En casos donde alguna palabra
pudiera
tener
múltiples
significados, se debe incluir su
definición precisa en un glosario
que se adicione al SRS.
 Ejemplos:
planta, obra, maestro, carga,
flecha

11. CARACTERISTICAS DE UN BUEN SRS
COMPLETO

El SRS es completo si incluye:




Todos los requerimientos significativos
sobre
funcionalidades, desempeño, restricci
ones de diseño, atributos, o interfaces
externas.
Las respuestas que debería dar el
software a todas las posibles
entradas de datos en todas las
situaciones
posibles
(entradas
aceptables
o
no
aceptables:
validación).
Especificación de unidades de
medida (si son aplicables).
En caso de que el SRS tenga
diagramas o tablas informativas, hay
que darles número o identificación.
CONSISTENTE


Los diversos requerimientos escritos
tienen que ser compatibles entre sí;
no debe haber contradicciones ni
conflictos entre ellos.
Para lograr la consistencia deben
evitarse los siguientes conflictos:
 En características especificadas
de objetos del mundo real.
 De lógica o de tiempo entre dos
actividades.
 Referencia a un mismo objeto del
mundo real pero usando
diferentes palabras para el
mismo objeto.

12. CARACTERISITICAS DE UN BUEN SRS
ORDENADO CON BASE DE
IMPORTANCIA O ESTABILIDAD




Cada requerimiento especificado debe
tener
alguna
identificación
(número, letra, secuencia alfanumérica)
para indicar su grado de importancia o
de estabilidad.
Algunos
requerimientos
son
más
importantes que otros.
Grado de estabilidad:
número de
cambios que se podrían esperar para un
requerimiento, debido a eventos futuros
que afecten a la organización, las
responsabilidades, y las personas que
usarán el software.
Grado de necesidad:
 Esencial
 Condicional
 Opcional
VERIFICABLE


Un requerimiento es verificable si
existe algún método rentable
mediante el cual se pueda
analizar si el software cumple
ese requerimiento.
Si no existe algún método para
saber si el software cumple o no
un requerimiento, entonces ese
requerimiento debe ser revisado
o eliminado.

13. CARACTERISTICAS DE UN BUEN SRS
MODIFICABLE


RASTEABLE
Es modificable si la estructura y
estilo de redacción permiten la
realización de cambios en forma
fácil, completa y consistente

Para esto es recomendable:




Incluir índice, tabla de contenido y
tabla de referencias cruzadas.
Cada requerimiento debe aparecer
sólo una vez (la redundancia propicia
errores de inconsistencia).
Poner cada requerimiento separado
de los demás.
Un SRS es rastreable si el origen
de cada requerimiento es
claro, y si facilita el seguimiento
de cada requerimiento a lo
largo del proyecto de software.
Dos tipos de rastreabilidad:


Hacia
atrás:
en
cada
requerimiento
se
menciona
explícitamente
su
fuente
documental
Hacia delante: los documentos
que se deriven del SRS deben
usar las identificaciones de
requerimientos como
fueron
dadas en el SRS

14. PREPARACIÓN CONJUNTA DEL SRS

El desarrollo de un software solamente debería
iniciar cuando el cliente y el proveedor estén de
acuerdo acerca de lo que el software deberá
hacer.

15. EVOLUCIÓN DEL SRS





Un SRS puede necesitar cambios mientras el software está en etapas de
diseño o de desarrollo.
Los cambios pueden estar motivados por: deficiencias, errores, omisiones o
imprecisiones en el documento original.
Cada requerimiento debe documentarse tan completo como sea
posible, aún si pudiera necesitar cambios posteriormente.
Los cambios en los requerimientos tienen que documentarse con el propósito
de: identificarlos, controlarlos, rastrearlos, y reportarlos.
Tanto el cliente como el proveedor deben designar a su respectivo
responsable de autorizar (o rechazar) cambios en los requerimientos.

16. CREACIÓN DE PROTOTIPOS

Un prototipo es un pequeño programa parecido al
software solicitado que sirve de ejemplo, muestra o
modelo para que el cliente vaya especificando sus
requerimientos en forma progresiva junto con el
desarrollador.

17. PROTOTIPOS

El prototipo es útil para:



Prever aspectos de la conducta del sistema, haciendo que el SRS sea más
completo y preciso.


Que el cliente/usuario vea y describa más fácilmente las funcionalidades que
desea.
Reducir la cantidad de cambios durante las etapas de diseño o desarrollo.
Un prototipo puede ayudar al usuario a definir detalles específicos de la interfaz
humana o de las funcionalidades que requiera.
Puede facilitarle al desarrollador el diseño y la programación del software.

18. DISEÑO IMPLÍCITO EN EL SRS

Aunque el SRS no constituye un documento de
diseño, implícitamente está diciéndole a los
desarrolladores lo que se espera que ellos diseñen


Establece restricciones
El SRS tiene que especificar las funcionalidades que
se aplicarán sobre ciertos datos para producir
resultados en cierto lugar para determinados
usuarios

19. REQUERIMIENTOS DE PROYECTO
IMPLÍCITOS


El SRS se enfoca en el
software como
producto, no en su
proceso de creación.
Implícitamente
establece restricciones
sobre la planeación y
administración del
proyecto
correspondiente.

El SRS da origen a otros
documentos (por separado)
relacionados con el ciclo de
vida de un software
 Estimación de costos
 Fechas de entrega
 Reportes de avances
 Métodos de desarrollo
 Aseguramiento de la
calidad
 Criterios de validación y
verificación
 Procedimientos de
aceptación

20. CONTENIDO Y
ORGANIZACIÓN TÍPICOS DE
UN SRS

21. CONTENIDO DE UN SRS

SECCIÓN 1: INTRODUCCIÓN
 Debe
incluir una descripción general
SRS, mostrando lo siguiente:
1.1 Propósito del documento
1.2 Alcance
1.3 Definiciones, acrónimos, y abreviaturas
1.4 Referencias
1.5 Descripción general del documento
del

22. CONTENIDO DE UN SRS

SECCIÓN 2: DESCRIPCIÓN GRAL. DEL SOFTWARE
 Usualmente se incluyen estas 6 subsecciones:
2.1 Perspectiva del software
2.2 Funciones del software
2.3 Características del usuario
2.4 Restricciones
2.5 Suposiciones y dependencias
2.6 Posposición de requerimientos

23. CONTENIDO DE UN SRS
2.1 Perspectiva del software
 Describir
las condiciones (restricciones) dentro de las
cuales deberá funcionar el software:
2.1.1 Interfaces de sistema
2.1.2 Interfaces de usuario
2.1.3 Interfaces de hardware
2.1.4 Interfaces de software
2.1.5 Interfaces de comunicaciones
2.1.6 Restricciones de memoria
2.1.7 Operaciones
2.1.8 Requerimientos de adaptación a un lugar

24. ORGANIZACIÓN DE LOS
REQUERIMIENTOS ESPECÍFICOS
Para lograr un mejor entendimiento de los
requerimientos, conviene organizarlos con base en
alguno de los siguientes criterios:
 Por modo de operación del sistema
 Por clase de usuario
 Por objetos
 Por características
 Por estímulos
 Por respuestas
 Por jerarquía funcional

25. GRACIAS POR SU
ATENCIÓN