Requerimientos de Información
Descargar como PPT, PDF1 recomendación6,314 vistas
Este documento presenta una introducción al estándar IEEE 830 para la especificación de requisitos de software. Explica que un requisito de software es una declaración de lo que un sistema debe hacer, no cómo lo hará. También describe los problemas comunes en la especificación de requisitos como funcionalidad incompleta, atributos de calidad sin criterios y restricciones sin documentar. Finalmente, resume las consideraciones clave para producir un buen documento de requisitos como prepararlo conjuntamente con el cliente y proveedor, gestionar cambios y usar prototipos
![Proyecto de Sistemas de Información Ing. Julio César Álvarez Reyes [email_address] http://juliozet.blogspot.com www.twitter.com/juliozet](https://image.slidesharecdn.com/sesion3-091124173148-phpapp02/85/Requerimientos-de-Informacion-1-320.jpg)
Requerimientos de Información
- 1. Proyecto de Sistemas de Información Ing. Julio César Álvarez Reyes [email_address] http://juliozet.blogspot.com www.twitter.com/juliozet
- 2. Sesión Nro. 3 Contenido. Análisis de Requerimientos.
- 3. IEEE-Estándar 830: Introducción Definiciones Contrato: 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
- 4. 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.
- 5. IEEE-Estándar 830: Introducción Estos problemas impactan en el presupuesto, calidad, plazos y en necesidades insatisfechas.
- 6. 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.
- 7. 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.
- 8. IEEE-Estándar 830: Introducción Partes 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í.