Proyecto de Sistemas de Información

Ing. Julio César Álvarez Reyes

juliozet@hotmail.com

http://juliozet.blogspot.com

www.twitter.com/juliozet

Sesión Nro. 3 Contenido.

Análisis de Requerimientos.

IEEE-Estándar 830: Introducción

DefinicionesContrato: Incluye lo requisitos técnicos y requerimientos de la organización, costo y tiempo

para un producto.Cliente: La persona (s) que pagan por el producto y normalmente (pero no necesariamente)

definen los requisitos. Proveedor: La persona (s) que producen un producto para un cliente.Usuario: La persona (s) que operan o actúan recíprocamente directamente con el producto. El

usuario (s) y el cliente (s) no es (son) a menudo la (s) misma (s) persona (s).

¿Qué es un Requisito de software? Un requisito de software es una especificación de lo que se debería implementar. Existen

básicamente dos tipos de requisitos (funcionales y no funcionales). Son una declaración de lo que debería hacer un sistema y no como lo debería hacer.

Es un conjunto de condiciones o capacidades que pueden ser esenciales, necesarias o deseadas y que es satisfecha por un sistema de software o componente con la finalidad de satisfacer un contrato u otro documento formal.

Los requisitos deben ser INEQUIVOCOS, CONSISTENTES Y COMPROBABLES

IEEE-Estándar 830: Introducción

Problemas de la especificación de requisitos de software (SRS)

Los problemas de la SRS son: Funcionalidad: se encuentran incompletos, erróneos o ambiguos. Interfaces externas: no han identificados completamente involucrados

(personas), hardware del sistemas, hardware de otros sistemas y otros software.

Atributos de calidad: estos se encuentran incompletos y/o sin criterios de aceptación por ejemplo tenemos rendimiento, portabilidad y otros.

Restricciones de diseño: como estándares, procedimientos, normas, idiomas, etc.

No administrados: problemas con el control de cambios y falta de capacidad de trazabilidad.

IEEE-Estándar 830: Introducción

Estos problemas impactan en el presupuesto, calidad, plazos y en necesidades insatisfechas.

Fuente de errores

Requerimientos56%

Diseño27%

Programación7%

Otros10%

IEEE-Estándar 830: Introducción

a) Consideraciones para producir un buen SRS. Naturaleza del SRS: SRS son especificaciones para un producto de software

b) Ambiente del SRS: Es importante considerar la parte que el SRS representa en el diseño del proyecto total y es parte del ciclo de vida del software.

c) Características de un buen SRS: Correcto Inequívoco Completo Consistente Establecer su importancia Comprobable Modificable Identificable.

IEEE-Estándar 830: Introducción

d) Preparación conjunta del SRS: El proceso de desarrollo de software debe empezar con el acuerdo entre el proveedor y cliente acerca de lo que el software deberá hacer. Este acuerdo, en la forma de un SRS, debe prepararse conjuntamente. Esto es importante porque ni el cliente ni el proveedor son calificables para escribir exclusivamente un buen SRS.

e) Evolución de SRS: Gestión de cambios a los requisitos del software.

f) Prototipos: Un prototipo debe usarse como una manera de sacar los requisitos del software. Pueden extraerse algunas características de pantallas y/o reportes.

IEEE-Estándar 830: IntroducciónPartes de un SRS Las partes del SRS se muestran en el cuadro. Un SRS no tiene porque usar los nombres mostrados en el siguiente cuadro, pero

si un buen SRS debe incluir toda la información que se menciona aquí.