Ing. Esp. Edgar R.

Enríquez Rosero

ANALISIS DE REQUERIMIENTOS
IEEE STD 830-1998 - SRS
IEEE STD 830-1998 - SRS
 Software Requirements Specifications
 Desarrollado por el Instituto de Ingenieros Eléctricos y Electrónicos (1988)
y actualizado de manera constante
 Describe las especificaciones para el análisis de requisitos
 Compuesto por 5 partes
 Parte 1. Explicación del alcance del estándar
 Parte 2. Referencias adicionales al estándar
 Parte 3. Definición de términos
 Parte 4. Información básica para desarrollar el Análisis de requerimientos
 Parte 5. Partes necesarias para el desarrollo del Análisis de requisitos
 Anexo 1. Plantillas opcionales para el trabajo
 Anexo 2. Directrices para el cumplimiento con la norma IEEE / EIA 12207.1-1997.
EXPLICACIÓN DEL ESTÁNDAR
 Práctica recomendada para desarrollar buenos análisis de
requerimientos
 Define los lineamientos necesarios para especificar los
requisitos
 Presta asistencia en la selección de los software
desarrollado a nivel interno de la empresa y los software
comerciales que se pueden adquirir
 se puede utilizar para crear ese SRS directamente o se
puede utilizar como un modelo para una norma más
específica
REFERENCIAS ADICIONALES AL ESTÁNDAR
 ASTM E1340-96, Standard Guide for Rapid Prototyping of Computerized Systems.
 IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology.
 IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans.
 IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning.
 IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans.
 IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable
Software.
 IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of
Measures to Produce Reliable
 Software.
 IEEE Std 1002-1987 (Reaff 1992), IEEE Standard Taxonomy for Software
Engineering Standards.
REFERENCIAS ADICIONALES AL ESTÁNDAR
 IEEE Std 1012-1998, IEEE Standard for Software Verification and Validation.
 IEEE Std 1012a-1998, IEEE Standard for Software Verification and Validation: Content Map
to IEEE/EIA
 12207.1-1997.
 IEEE Std 1016-1998, IEEE Recommended Practice for Software Design Descriptions.
 IEEE Std 1028-1997, IEEE Standard for Software Reviews.
 IEEE Std 1042-1987 (Reaff 1993), IEEE Guide to Software Configuration Management.
 IEEE P1058/D2.1, Draft Standard for Software Project Management Plans, dated 5 August
1998.
 IEEE Std 1058a-1998, IEEE Standard for Software Project Management Plans: Content Map
to IEEE/EIA
 12207.1-1997.
 IEEE Std 1074-1997, IEEE Standard for Developing Software Life Cycle Processes.
 IEEE Std 1233, 1998 Edition, IEEE Guide for Developing System Requirements
Specifications.
DEFINICIONES - IEEE STD 610.12-1990
 Contract: (contrato)
Documento jurídicamente vinculante acordado
por el cliente y el proveedor.
 Incluye técnica y requisitos de organización, el
costo y el calendario de un producto.
 Puede sr informal, pero debe contener informa-
ción útil, y los compromisos o expectativas de las
partes implicadas
 Customer: (cliente)
Persona(s) que pagan por el producto y por lo
general (pero no necesariamente) decidir los
requisitos.
 El cliente y el proveedor pueden ser miembros de
la misma organización
 Supplier: (proveedor)
Persona(s), que produce(n) un producto de
software para un cliente.
 El cliente y el proveedor pueden ser miembros de
la misma organización.
 User: (usuario)
Persona(s) que actúan o interactúan directamente
con el producto.
 El usuario (s) y el cliente (s) no son la misma
persona generalmente
CONSIDERACIONES PARA PRODUCIR UN BUEN SRS (ANALISIS
DE REQUERIMIENTOS)

 Naturaleza del SRS

 Medio Ambiente del SRS
 Características de un buen SRS
 La preparación conjunta del SRS;
 evolución;
 Prototipos
 Diseño embebido en el SRS
 Inserción de los requisitos del proyecto en el SRS
NATURALEZA DEL SRS
 El SRS es un especificación para un producto de
software en particular, programa o conjunto de
programas que realiza ciertas funciones en un
entorno especifico.
 Puede ser elaborado por uno o más:
 Representantes del proveedor
 Representantes de los clientes
 Subsección 4.4 recomienda ambos.
Funcionalidad.
¿Qué debe hacer el software?

Interfaces externas.
¿Cómo funciona el software al interactuar con la gente, el hardware sistemas Operativos, hardware
y otros software?

Rendimiento.
¿Cuál es la velocidad, la disponibilidad, tiempo de respuesta, tiempo de recuperación de las
funciones de software, etc?

Atributos
¿Cuáles son las consideraciones que se deben tener para su desarrollo, como por ejemplo:
portabilidad, la corrección, mantenimiento, seguridad, etc?

Restricciones de diseño impuestas a una aplicación.

¿Existen normas exigidas en efecto, la aplicación, el idioma, las políticas de integridad de base de
datos, los límites de los recursos, el sistema operativo (s), etc?
EL ENTORNO DEL SRS
 Considerar el papel que desempeña el SRS en el plan del proyecto total, que es definido en
IEEE Std 610.12-1990.
 El software puede contener esencialmente toda la funcionalidad del proyecto o puede ser parte
de un sistema más amplio. En este último caso, normalmente habrá un SRS que el estado de
las interfaces entre los sistemas y parte del software, y pondrá el desempeño y requisitos de
funcionalidad a la parte de software que se incorpora. Por supuesto, el SRS debe entonces
estar de acuerdo y ampliar estos requisitos de sistema.

 En el estándar IEEE Std. 1074-1997 se describen los pasos en el ciclo de vida del software y
de los insumos aplicables a cada paso.

 Otras normas, tales como los enumerados en la cláusula 2, se refieren a otras partes del ciclo
de vida del software y así podrá complementar los requisitos de software.

 El escritor del SRS tiene un papel que desempeñar en el proceso de desarrollo de software, el
escritor SRS (s) deben tener cuidado de no ir más allá de los límites de ese papel.
 Esto significa que el SRS:
 Debe definir correctamente todos los requisitos del software. Un requisito de
software puede existir debido a la naturaleza de la tarea que hay que resolver, o
por una característica especial del proyecto.
 No debe describir cualquier diseño o detalles de aplicación. Estos deben ser
descritos en la etapa de diseño del proyecto.
 No debe imponer restricciones adicionales en el software. Estos son
adecuadamente especificados en otros documentos tales como el plan de
garantía de calidad delsoftware
 Por lo tanto, el SRS correctamente escrito, limita el rango de diseños
válidos, pero no especifica ningún diseño en particular.
CARACTERÍSTICAS DE UN BUEN SRS
 Correcto
 Inequívoco o no ambiguo
 Completa
 Consistente
 Clasificado por importancia y/o estabilidad
 Verificable
 Modificable
 Trazables.
CORRECTO
 Un SRS es correcto si, y sólo si, todos los requisitos establecidos en el
mismo son los que el software reunirá.
 No hay ninguna herramienta o un procedimiento que garantice las
correcciones.
 El SRS se debe comparar con cualquier aplicación de especificación
superior, por ejemplo una especificación de requisitos del sistema, con
la documentación de otro proyecto y con otras normas aplicables para
garantizar que está de acuerdo.
 Alternativamente el cliente o el usuario puede determinar si el SRS
refleja correctamente las necesidades reales. La Trazabilidad hace que
este procedimiento sea más fácil y menos propenso a errores. (véase
4.3.8).
INEQUÍVOCA
 Un SRS es ambiguo, si y sólo si, todos los
requisitos establecidos en el mismo sólo tiene una
interpretación.
 Como mínimo, esto requiere que cada
característica del producto final sea descrito con
un término único