IEEE-STD-830-1998: PRÁCTICA RECOMENDADA PARA LAS ESPECIFICACIONES DE REQUISITOS DEL SOFTWARE

1. IEEE-STD-830-1998: PRÁCTICA RECOMENDADA PARA LAS ESPECIFICACIONES DE REQUISITOS DEL SOFTWARE JUAN GUILLERMO CARVAJAL PATIÑO - 257299 TATIANA FRANCO VILLAMIZAR - 257311 DIANA CAROLINA MARTINEZ ZAMBRANO - 257328

2. CONTENIDO • INTRODUCCIÓN • DEFINICIONES PRELIMINARES • CONSIDERACIONES PARA PRODUCIR UN BUEN SRS • PARTES DE UN SRS • ANEXOS

3. INTRODUCCIÓN • QUÉ ES SRS? • QUÉ VENTAJAS TIENE?

4. DEFINICIONES PRELIMINARES • CONTRATO • CLIENTE • PROVEEDOR • USUARIO

5. CONSIDERACIONES PARA PRODUCIR UN BUEN SRS NATURALEZA DEL SRS

6. CONSIDERACIONES PARA PRODUCIR UN BUEN SRS AMBIENTE DEL SRS • Debe definir todos los requisitos del software correctamente. • No debe describir cualquier plan o detalles de aplicación. • No debe imponer las restricciones adicionales en el software.

7. Correcto Inequívoco Identificable SRS Completo Modificable Consistente Comprobable Delinear que tiene importancia y/o estabilidad CONSIDERACIONES PARA PRODUCIR UN BUEN SRS CARACTERÍSTICAS DEL SRS

8. CARACTERÍSTICAS DEL SRS-CORRECTO

9. CARACTERÍSTICAS DEL SRS-INEQUÍVOCO

10. CARACTERÍSTICAS DEL SRS-COMPLETO

11. CARACTERÍSTICAS DEL SRS-CONSISTENTE

12. CARACTERÍSTICAS DEL SRS -IMPORTANCIA Y ESTABILIDAD

13. CARACTERÍSTICAS DEL SRS - COMPROBABLE

14. CARACTERÍSTICAS DEL SRS - MODIFICABLE

15. CARACTERÍSTICAS DEL SRS - IDENTIFICABLE IDENTIFICABLE DIRIGIDO HACIA ATRÁS DELANTERO

16. CONSIDERACIONES PARA PRODUCIR UN BUEN SRS PREPARACIÓN CONJUNTA DEL SRS

17. CONSIDERACIONES PARA PRODUCIR UN BUEN SRS EVOLUCIÓN DEL SRS Evolución de SRS Deben especificarse los requisitos completamente Un proceso de cambio formal debe comenzarse para identificar el control

18. CONSIDERACIONES PARA PRODUCIR UN BUEN SRS PROTOTIPOS • El cliente puede ver el prototipo y reaccionar a este. • El prototipo despliega aspectos que se anticipan a la conducta de los sistemas. • Un SRS basado en un prototipo tiende a sufrir menos cambios durante el desarrollo.

19. CONSIDERACIONES PARA PRODUCIR UN BUEN SRS GENERACIÓN DEL DISEÑO DEL SRS • Un diseño describe un subcomponente particular de un sistema y/o sus interfaces con otros subcomponentes.

20. CONSIDERACIONES PARA PRODUCIR UN BUEN SRS REQUISITOS DEL PLAN NECESARIOS • En casos especiales, algunos requisitos pueden restringir el plan severamente. Por ejemplo, seguridad o requisitos de seguridad pueden verse reflejados directamente en el plan.

21. CONSIDERACIONES PARA PRODUCIR UN BUEN SRS REQUISITOS DEL PROYECTO GENERADOS EN EL SRS • El costo • Los tiempos de entrega • Información de los procedimientos • Métodos de desarrollo del software • Convicción de calidad • Aprobación y criterio de la comprobación • Procedimientos de aceptación

22. PARTES DE UN SRS • Tabla de Contenido • 1. Introducción • 1.1 Propósito • 1.2 Alcance • 1.3 Definiciones, siglas, y abreviaciones • 1.4 Referencias • 1.5 Apreciación global

23. INTRODUCCIÓN

24. INTRODUCCIÓN

25. PARTES DE UN SRS • 2. Descripción global • 2.1 Perspectiva del producto • 2.2 Funciones del producto • 2.3 Características del usuario • 2.4 Restricciones • 2.5 Atención y dependencias • 2.6. Repartir proporcionalmente los requisitos

26. DESCRIPCIÓN GLOBAL

27. DESCRIPCIÓN GLOBAL

28. DESCRIPCIÓN GLOBAL

29. DESCRIPCIÓN GLOBAL

30. DESCRIPCIÓN GLOBAL

31. PARTES DE UN SRS • 3. Los requisitos específicos • Apéndices • Índice

32. REQUISITOS ESPECÍFICOS • Deben declararse los requisitos específicos de conformidad con todas las características descritas en la sección de “características del usuario”. • Los requisitos específicos deben tener referencias cruzadas a documentos más actuales que los relacionen. • Todos los requisitos deben ser singularmente identificables. • Debe prestarse la atención necesaria para organizar los requisitos, de manera que se aumente al máximo la legibilidad.

33. REQUISITOS ESPECÍFICOS

34. LOS REQUISITOS ESPECÍFICOS-FUNCIONES

35. LOS REQUISITOS ESPECÍFICOS-REQUISITOS DEL DESARROLLO

36. LOS REQUISITOS ESPECÍFICOS-REQUISITOS DEL BANCO DE DATOS LÓGICO

37. LOS REQUISITOS ESPECÍFICOS-RESTRICCIONES DEL DISEÑO Aceptación de las normas • El formato de reporte • Los nombres de los datos • Los procedimientos de contabilidad • Los lineamientos de la Auditoría

38. LOS REQUISITOS ESPECÍFICOS-ATRIBUTOS DEL SOFTWARE DEL SISTEMA • Fiabilidad • Disponibilidad • Seguridad • Mantenimiento • Portabilidad

39. LOS REQUISITOS ESPECÍFICOS-ORGANIZAR LOS REQUISITOS ESPECÍFICOS • Modo del sistema • Clases de usuario • Objetos • Característica • Estímulo • Respuesta • Jerarquía Funcional

40. Modo del sistema: Algunos sistemas se comportan de diferente manera dependiendo del modo de operación. • Clases de usuario: Algunos sistemas proporcionan diferentes conjuntos de funciones a las diferentes clases de usuario.

41. Objetos: Son entidades del mundo real que tienen una contraparte dentro del sistema. • Característica: Una característica es un servicio externo deseado por el sistema. • Estímulo: Algunos sistemas pueden organizarse mejor describiendo sus funciones en términos de estímulos.

42. Respuesta: Algunos sistemas pueden organizarse mejor describiendo todas las funciones en soporte a la generación de una respuesta. • Jerarquía funcional: La funcionalidad global puede organizarse en una jerarquía de funciones organizadas por cualquier entrada común, salida común o el acceso a datos internos comunes.

43. Comentarios adicionales: Hay muchas anotaciones, métodos y herramientas de apoyo disponibles para ayudar en la documentación de requisitos.

44. LOS REQUISITOS ESPECÍFICOS- INFORMACIÓN DE APOYO • Tablas de contenido e índices • Apéndices

45. ANEXOS FORMATO