IEEE 830 vL4

Páginas: 5 (1108 palabras) Publicado: 19 de junio de 2015
IEEE-std-830-1998
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

*...
Leer documento completo

Regístrate para leer el documento completo.

Estos documentos también te pueden resultar útiles

  • IEEE 830
  • Esquema IEEE 830
  • Norma IEEE 830 2
  • Estándar IEEE-830
  • Ensayo IEEE 830
  • Requisitos de Software IEEE 830
  • Ieee 830
  • Guia general- ieee 830-1998

Conviértase en miembro formal de Buenas Tareas

INSCRÍBETE - ES GRATIS