Jesus Nolberto Ruelas Vargas

Contrato

Un documento es legalmente obligatorio y en el estarn de acuerdo las partes del cliente y proveedor. La persona (s) que pagan por el producto y normalmente (pero no necesariamente) definen los requisitos.

Naturaleza del SRS

El SRS son especificaciones para un producto del software en particular, programa, o juego de programas que realizan ciertas funciones en un ambiente especfico.

Correcto
Un SRS es correcto si, y slo si, cada requisito declarado se encuentra en el software. No hay herramienta que asegura la exactitud.

Definiciones

Cliente

Proveedor
La persona (s) que producen un producto para un cliente

Ambiente del SRS

Es importante considerar la parte que el SRS representa en el diseo del proyecto total que se define en IEEE Std 610.12-1990. Un SRS debe ser:

Inequvoco
Un SRS es inequvoco si, y slo si, cada requisito declarado tiene slo una Interpretacin.

Usuario
La persona (s) que operan o actan recprocamente directamente con el producto.

Completo
Un SRS est completo si, y slo si, incluye los elementos siguientes: a) estn relacionados a la funcionalidad, el desarrollo, las restricciones del diseo, los atributos y las interfaces externas. b) La definicin de las respuestas del software a todos los posibles datos de la entrada del sistema y a toda clase de situaciones. c) Tener todas las etiquetas llenas y referencias a todas las figuras, tablas, diagramas en el SRS

Caractersticas de un buen SRS

Preparacin de los JOIN del SRS

El proceso de desarrollo de software debe empezar con el proveedor y con el acuerdo del cliente en lo que el software completado debe hacer.

IEEE-STD-830-1998 : ESPECIFICACIONES DE LOS REQUISITOS DEL SOFTWARE

Evolucin de SRS

Consistente
La consistencia se refiere a la consistencia interior. Si un SRS no est de acuerdo con algn documento del superior-nivel, como una especificacin de requisitos de sistema, entonces no es correcto.

Las consideraciones para producir un buen SRS.

El SRS puede necesitar evolucionar as como el desarrollo de las actualizaciones del producto de software. del cliente en lo que el software completado debe hacer.

Prototipos
El cliente puede ver el prototipo y reaccionar a l que leer el SRS y reaccionar a l

Delinear que tiene importancia

Un SRS debe delinear la importancia y/o estabilidad si cada requisito en l tiene un identificador para indicar la importancia o estabilidad de ese requisito en particular.

Generando el diseo en el SRS

a) el Costo; b) Los tiempos de la entrega; Requisitos del proyecto generados en el SRS c) Informando los procedimientos; d) Los mtodos de desarrollo de Software; e) La conviccin de Calidad; El Propsito f) La Aprobacin y criterio de la comprobacin; g) Los procedimientos de aceptacin. El Alcance El diseador del SRS debe distinguir claramente entre identificar las restricciones del diseo requeridos y proyectar un plan especfico.

Comprobable
Un requisito es comprobable si, y slo si, all existe algn proceso rentable finito con que una persona o la mquina puede verificar que el producto del software rene el requisito. En general cualquier requisito ambiguo no es comprobable.

Esta seccin normalmente consiste en seis subdivisiones, como sigue:

Modificable
Para que sea modificable se requiere un SRS que contenga: a) Tiene un coherente y fcil de usar en la organizacin de volmenes de informacin b) no sea redundante c) Exprese cada requisito separadamente

Las Definiciones, siglas, y abreviaciones Las Referencias La Apreciacin global.

Perspectiva del producto Funciones del producto Caractersticas del usuario Restricciones Atencin y dependencias

Identificable
Un SRS es identificable si el origen de cada uno de sus requisitos est claro.

Introduccin
La introduccin del SRS debe proporcionar una apreciacin global del SRS completo.

Interfaces externas Funciones

a) las interfaces del Sistema; b) las interfaces del Usuario; c) las interfaces del Hardware; d) las interfaces del Software; e) las interfaces de Comunicaciones; f) la Memoria; g) los Funcionamientos; h) los requisitos de adaptacin del Site.

Descripcin global
La introduccin del SRS debe proporcionar una apreciacin global del SRS completo.

Requisitos del desarrollo Requisitos del banco de datos lgicos Restricciones del diseo Atributos del software del sistema Organizar los requisitos especficos Comentarios adicionales

Las partes de un SRS

Un SRS no tiene que seguir este contorno o usar los nombres dado aqu para sus partes, un buen SRS debe incluir toda la informacin que se mencion aqu.

Requisitos especficos
Debe contener todos los requisitos del software a un nivel de detalle suficiente para permitirles a los diseadores disear un sistema para satisfacer esos requisitos

Debe describir cmo el software opera dentro de las varias restricciones