Ieee 830
- 1. Especi
- 2. cacion de Requisitos segun el estandar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008 Resumen Este documento presenta, en castellano, el formato de Especi
- 3. ca- cion de Requisitos Software (ERS) segun la ultima version del estandar IEEE 830. Segun IEEE, un buen Documento de Requisitos, pese a no ser obligatorio que siga estrictamente la organizacion y el formato da- dos en el estandar 830, s debera incluir, de una forma o de otra, toda la informacion presentada en dicho estandar. El estandar de IEEE 830 no esta libre de defectos ni de prejuicios, y por ello ha sido jus- tamente criticado por multiples autores y desde multiples puntos de vista, llegandose a cuestionar incluso si es realmente un estandar en el sentido habitual que tiene el termino en otras ingenieras. El presente documento no pretende pronunciarse ni a favor ni en contra de unos u otros: tan solo reproduce, con propositos fundamentalmente docentes, como se organizara un Documento de Requisitos segun el estandar IEEE 830.
- 4. INDICE 2 Indice 1. Introduccion 3 1.1. Proposito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Ambito del Sistema . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. De
- 5. niciones, Acronimos y Abreviaturas . . . . . . . . . . . . . 3 1.4. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.5. Vision General del Documento . . . . . . . . . . . . . . . . . . 4 2. Descripcion General 4 2.1. Perspectiva del Producto . . . . . . . . . . . . . . . . . . . . . 4 2.2. Funciones del Producto . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Caractersticas de los Usuarios . . . . . . . . . . . . . . . . . . 5 2.4. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.5. Suposiciones y Dependencias . . . . . . . . . . . . . . . . . . . 5 2.6. Requisitos Futuros . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requisitos Espec
- 6. cos 6 3.1. Interfaces Externas . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Funciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Requisitos de Rendimiento . . . . . . . . . . . . . . . . . . . . 9 3.4. Restricciones de Dise~no . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Atributos del Sistema . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Otros Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Apendices 9
- 7. 1 INTRODUCCI ON 3 1. Introduccion En esta seccion se proporcionara una introduccion a todo el documento de Especi
- 8. cacion de Requisitos Software(ERS). Consta de varias subsecciones: proposito, ambito del sistema, de
- 9. niciones, referencias y vision general del documento. 1.1. Proposito En esta subseccion se de
- 10. nira el proposito del documento ERS y se espe-ci
- 11. cara a quien va dirigido el documento. 1.2. Ambito del Sistema En esta subseccion: Se podra dar un nombre al futuro sistema (p.ej. MiSistema) Se explicara lo que el sistema hara y lo que no hara. Se describiran los bene
- 12. cios, objetivos y metas que se espera alcanzar con el futuro sistema. Se referenciaran todos aquellos documentos de nivel superior (p.e. en In-genier a de Sistemas, que incluyen Hardware y Software, debera man-tenerse la consistencia con el documento de especi
- 13. cacion de requisitos globales del sistema, si existe). 1.3. De
- 14. niciones, Acronimos y Abreviaturas En esta subseccion se de
- 15. niran todos los terminos, acronimos y abrevia-turas utilizadas en la ERS. 1.4. Referencias En esta subseccion se mostrara una lista completa de todos los documen-tos referenciados en la ERS.
- 16. 2 DESCRIPCI ON GENERAL 4 1.5. Vision General del Documento Esta subseccion describe brevemente los contenidos y la organizacion del resto de la ERS. 2. Descripcion General En esta seccion se describen todos aquellos factores que afectan al pro-ducto y a sus requisitos. No se describen los requisitos, sino su contexto. Esto permitira de
- 17. nir con detalle los requisitos en la seccion 3, haciendo que sean mas faciles de entender. Normalmente, esta seccion consta de las siguientes subsecciones: Pers-pectiva del producto, funciones del producto, caractersticas de los usuarios, restricciones, factores que se asumen y futuros requisitos. 2.1. Perspectiva del Producto Esta subseccion debe relacionar el futuro sistema (producto software) con otros productos. Si el producto es totalemente independiente de otros pro-ductos, tambien debe especi
- 18. carse aqu. Si la ERS de
- 19. ne un producto que es parte de un sistema mayor, esta subseccion relacionara los requisitos del sistema mayor con la funcionalidad del producto descrito en la ERS, y se identi
- 20. caran las interfaces entre el producto mayor y el producto aqu des-crito. Se recomienda utilizar diagramas de bloques. 2.2. Funciones del Producto En esta subseccion de la ERS se mostrara un resumen, a grandes rasgos, de las funciones del futuro sistema. Por ejemplo, en una ERS para un pro-grama de contabilidad, esta subseccion mostrara que el sistema soportara el mantenimiento de cuentas, mostrara el estado de las cuentas y facilitara la facturacion, sin mencionar el enorme detalle que cada una de estas funciones requiere. Las funciones deberan mostrarse de forma organizada, y pueden utili-zarse gra
- 21. cos, siempre y cuando dichos gra
- 22. cos re ejen las relaciones entre funciones y no el dise~no del sistema.
- 23. 2 DESCRIPCI ON GENERAL 5 2.3. Caractersticas de los Usuarios Esta subseccion describira las caractersticas generales de los usuarios del producto, incluyendo nivel educacional, experiencia y experiencia tecnica. 2.4. Restricciones Esta subseccion describira aquellas limitaciones que se imponen sobre los desarrolladores del producto Polticas de la empresa Limitaciones del hardware Interfaces con otras aplicaciones Operaciones paralelas Funciones de auditora Funciones de control Lenguaje(s) de programacion Protocolos de comunicacion Requisitos de habilidad Criticalidad de la aplicacion Consideraciones acerca de la seguridad 2.5. Suposiciones y Dependencias Esta subseccion de la ERS describira aquellos factores que, si cambian, pueden afectar a los requisitos. Por ejemplo, los requisitos pueden presu-poner una cierta organizacion de ciertas unidades de la empresa, o pueden presuponer que el sistema correra sobre cierto sistema operativo. Si cambian dichos detalles en la organizacion de la empresa, o si cambian ciertos detalles tecnicos, como el sistema operativo, puede ser necesario revisar y cambiar los requisitos.
- 24. 3 REQUISITOS ESPECIFICOS 6 2.6. Requisitos Futuros Esta subseccion esbozara futuras mejoras al sistema, que podran anali-zarse e implementarse en un futuro. 3. Requisitos Espec
- 25. cos Esta seccion contiene los requisitos a un nivel de detalle su
- 26. ciente como para permitir a los dise~nadores dise~nar un sistema que satisfaga estos requi-sitos, y que permita al equipo de pruebas plani
- 27. car y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aqu es-peci
- 28. cado describira comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la seccion mas larga e importante de la ERS. Deberan aplicarse los siguientes principios: El documento debera ser perfectamente legible por personas de muy distintas formaciones e intereses. Deberan referenciarse aquellos documentos relevantes que poseen algu-na in uencia sobre los requisitos. Todo requisito debera ser unvocamente identi
- 29. cable mediante algun codigo o sistema de numeracion adecuado. Lo ideal, aunque en la practica no siempre realizable, es que los requi-sitos posean las siguientes caractersticas: Correccion: La ERS es correcta si y solo si todo requisito que
- 30. gura aqu (y que sera implementado en el sistema) re eja alguna necesidad real. La correccion de la ERS implica que el sistema implementado sera el sistema deseado. No ambiguos: Cada requisito tiene una sola interpretacion. Para eliminar la ambiguedad inherente a los requisitos expresados en lenguaje natural, se deberan utilizar gra
- 31. cos o notaciones forma-les. En el caso de utilizar terminos que, habitualmente, poseen mas de una interpretacion, se de
- 32. niran con precision en el glosario. Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir todas las posibles respuestas del sistema a los datos de entrada, tanto validos como no validos.
- 33. 3 REQUISITOS ESPECIFICOS 7 Consistentes: Los requisitos no pueden ser contradictorios. Un con-junto de requisitos contradictorio no es implementable. Clasi
- 34. cados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden clasi
- 35. carse por importancia (esenciales, condicionales u opcionales) o por estabilidad (cam-bios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear excesivos recursos en implementar requisitos no esenciales. Veri
- 36. cables: La ERS es veri
- 37. cable si y solo si todos sus requisitos son veri
- 38. cables. Un requisito es veri
- 39. cable (testeable) si existe un proceso
- 40. nito y no costoso para demostrar que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, veri
- 41. - cable. Expresiones como a veces, bien, adecuado, etc. introducen ambiguedad en los requisitos. Requisitos como en caso de acci-dente la nube toxica no se extendera mas alla de 25Km no es veri
- 42. cable por el alto costo que conlleva. Modi
- 43. cables: La ERS es modi
- 44. cable si y solo si se encuentra es-tructurada de forma que los cambios a los requisitos pueden rea-lizarse de forma facil, completa y consistente. La utilizacion de herramientas automaticas de gestion de requisitos (por ejemplo RequisitePro o Doors) facilitan enormemente esta tarea. Trazables: La ERS es trazable si se conoce el origen de cada requi-sito y se facilita la referencia de cada requisito a los componentes del dise~no y de la implementacion. La trazabilidad hacia atras indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R indica que compo-nentes del sistema son los que realizan el requisito R. 3.1. Interfaces Externas Se describiran los requisitos que afecten a la interfaz de usuario, interfaz con otros sistemas (hardware y software) e interfaces de comunicaciones. 3.2. Funciones Esta subseccion (quiza la mas larga del documento) debera especi
- 45. car todas aquellas acciones (funciones) que debera llevar a cabo el software. Nor-
- 46. 3 REQUISITOS ESPECIFICOS 8 malmente (aunque no siempre), son aquellas acciones expresables como el sistema debera . . . . Si se considera necesario, podran utilizarse notaciones gra
- 47. cas y tablas, pero siempre supeditadas al lenguaje natural, y no al reves. Es importante tener en cuenta que, en 1983, el Estandar de IEEE 830 estableca que las funciones deberan expresarse como una jerarqua funcional (en paralelo con los DFDs propuestos por el analisis estructurado). Pero el Estandar de IEEE 830, en sus ultimas versiones, ya permite organizar esta subseccion de multiples formas, y sugiere, entre otras, las siguientes: Por tipos de usuario: Distintos usuarios poseen distintos requisitos. Pa-ra cada clase de usuario que exista en la organizacion, se especi
- 48. caran los requisitos funcionales que le afecten o tengan mayor relacion con sus tareas. Por objetos: Los objetos son entidades del mundo real que seran re e-jadas en el sistema. Para cada objeto, se detallaran sus atributos y sus funciones. Los objetos pueden agruparse en clases. Esta organizacion de la ERS no quiere decir que el dise~no del sistema siga el paradigma de Orientacion a Objetos. Por objetivos: Un objetivo es un servicio que se desea que ofrezca el sistema y que requiere una determinada entrada para obtener su resul-tado. Para cada objetivo o subobjetivo que se persiga con el sistema, se detallaran las funciones que permitan llevarlo a cabo. Por estmulos: Se especi
- 49. caran los posibles estmulos que recibe el sis-tema y las funciones relacionadas con dicho estmulo. Por jerarqua funcional: Si ninguna de las anteriores alternativas resulta de ayuda, la funcionalidad del sistema se especi
- 50. cara como una jerar-qu a de funciones que comparten entradas, salidas o datos internos. Se detallaran las funciones (entrada, proceso, salida) y las subfunciones del sistema. Esto no implica que el dise~no del sistema deba realizarse segun el paradigma de Dise~no Estructurado. Para organizar esta subseccion de la ERS se elegira alguna de las ante-riores alternativas, o incluso alguna otra que se considere mas conveniente. Debera, eso s, justi
- 51. carse el porque de tal eleccion.
- 52. 4 APENDICES 9 3.3. Requisitos de Rendimiento Se detallaran los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el numero de terminales, el numero esperado de usuarios simultaneamente conectados, numero de transacciones por segundo que debera soportar el sistema, etc. Tambien, si es necesario, se especi
- 53. caran lo requisitos de datos, es decir, aquellos requisitos que afecten a la informacion que se guardara en la base de datos. Por ejemplo, la frecuencia de uso, las capacidades de acceso y la cantidad de registros que se espera almacenar (decenas, cientos, miles o millones). 3.4. Restricciones de Dise~no Todo aquello que restrinja las decisiones relativas al dise~no de la aplica-ci on: Restricciones de otros estandares, limitaciones del hardware, etc. 3.5. Atributos del Sistema Se detallaran los atributos de calidad (las ilities) del sistema: Fiabilidad, mantenibilidad, portabilidad, y, muy importante, la seguridad. Debera espe-ci
- 54. carse que tipos de usuario estan autorizados, o no, a realizar ciertas tareas, y como se implementaran los mecanismos de seguridad (por ejemplo, por me-dio de un login y una password). 3.6. Otros Requisitos Cualquier otro requisito que no encaje en otra seccion. 4. Apendices Pueden contener todo tipo de informacion relevante para la ERS pero que, propiamente, no forme parte de la ERS. Por ejemplo: 1. Formatos de entrada/salida de datos, por pantalla o en listados. 2. Resultados de analisis de costes. 3. Restricciones acerca del lenguaje de programacion.