IEEE 830 vL4
Práctica Recomendada para la Especificación
de Requerimientos de Software
Fuente:
• IEEE Recommendad Practice for Software Requirements
Specifications
Preparó: Ing. Ismael Castañeda Fuentes
Objetivos de Aprendizaje
Conocer la norma IEEE 830
Aprender a formular especificaciones de software
Escribir especificaciones de software que
Indiquen exactamente lo quedesea el cliente
Permitan al proveedor entender exactamente lo que quiere el cliente
Aprender a establecer las bases de acuerdo entre cliente y
proveedor sobre lo que debe hacer un determinado software
Aprender a elaborar una línea base para validación y verificación
Definiciones
Contrato
Documento legalmente obligatorio en el cual cliente y proveedor
llegan a acuerdos.
Incluyerequisitos técnicos, requerimientos de la organización, costo
y tiempo para un producto.
También puede contener la información informal pero útil como los
compromisos o expectativas de las partes involucradas.
Cliente
Persona(s) que paga(n) por el producto
Normalmente (pero no necesariamente) definen los requisitos.
En la práctica el cliente y el proveedor pueden ser miembros de la
mismaorganización.
Definiciones
Proveedor:
Persona(s) que produce(n) un producto para un cliente
Usuario:
Persona(s) que operan o actúan recíprocamente directamente con el
producto.
El(los) usuario(s) y el(los) cliente(s) a menudo no son la(s) misma(s)
persona(s).
Consideraciones para una buena ERS*
Naturaleza de la ERS
Ambiente de la ERS
Características de una buena ERS
Preparación conjunta dela ERS
Evolución de la ERS
Prototipos
Diseño en la ERS
Requisitos del proyecto en la ERS
* ERS Especificación de Requerimientos de software
Naturaleza de la ERS*
La SRS son especificaciones para un producto particular de software,
programa o juego de programas que realizan ciertas funciones en un
ambiente específico.
La SRS puede escribirse por
Uno o más representantes delproveedor
Uno o más representantes del cliente o
Por ambos (proveedor y cliente).
Aspectos básicos que se deben tener en cuenta:
Funcionalidad
Interfases externas
Rendimiento
Atributos.
Restricciones de diseño, impuestas en la implementación
* ERS Especificación de Requerimientos de software
Ambiente de la ERS*
El software puede contener toda la funcionalidad del proyecto o
Puedeser parte de un sistema más grande
En el último caso habrá una ERS que
Declara las interfases entre el sistema y ese software modular, e
Indica la funcionalidad del software modular
La ERS tiene un rol específico en el proceso de desarrollo de
software, quien la define, debe tener cuidado para no ir más allá de
los límites de ese rol
La ERS
Debe definir todos los requisitos delsoftware correctamente
No debe describir detalles de diseño o implementación
No debe imponer restricciones adicionales al software (van en otro
documento, por ejemplo en el de aseguramiento de la calidad)
* ERS Especificación de Requerimientos de software
Características de una buena ERS*
Una buena ERS debe ser:
Correcta
Inequívoca
Completa
Con todos los requisitos relacionados confuncionalidad, rendimiento,
restricciones de diseño, atributos e interfases externas.
Respuestas a todas los posibles entradas (válidas e inválidas)
Con todas las etiquetas y referencias a figuras, tablas, diagramas en la ERS
Definición de las unidades de medida.
Consistente
Organizada por orden de importancia y/o estabilidad
Esencial, condicionada a u opcional – Con/sin cambios
Comprobable
Modificable
Trazable
* ERS de Requerimientos de software
Preparación conjunta de la ERS*
Cliente y Proveedor en trabajo conjunto
* ERS Especificación de Requerimientos de software
Evolución de la ERS*
Cambios a medida que
Se conozca más a cerca del contenido del proyecto
Se llegue a detalles
Avance el proyecto
Se detecten deficiencias
Se detecten inexactitudes
*...
Regístrate para leer el documento completo.