Recomendacin para la Especificacin de Requerimientos de Software de la IEEE.

Existe una organizacin muy importante a nivel internacional llamada IEEE (Institute of Electrical and Electronics Engineers, en espaol le llaman comunmente la I triple E). Esta organizacin, produce estndares que se aplican en muchas industrias del mundo. La IEEE, edita revistas de divulgacin cientfica con un prestigio muy alto, y tambin organiza congresos muy importantes en el mbito internacional. Por lo general, los libros de texto que hablan acerca de los requerimientos de software, incluyendo estas notas, se basan en un estndar emitido por la IEEE qu se aprob en 1998, llamado: IEEE Std 830-1998. Std es la forma de abreviar Standard en ingls y el nmero de la especificacin es 830, fue aprobada en 1998 y es una revisin de un estndar previo aceptado en 1993, Por las siglas en ingls, SRS que significan: Software Requirements Specifications, se acostumbra llamar SRS al documento de especificacin. En el IEEE Std 830-1998 se habla sobre las caractersticas que deben tener los requerimientos (correctos, consistentes, completos, realistas, rastreables y verificables), los tipos de requerimientos (funcionales y no funcionales), as como lo que se debe tomar en cuenta al elaborarlos (ambiente fsico, interfaces, usuarios y factores humanos, funcionalidad, documentacin, datos, recursos, seguridad y aseguramiento de la calidad). Lo ms importante del IEEE Std 830-1998 es que define la estructura que debe tener una especificacin de requerimientos, esta estructura se explica en la siguiente seccin. Normalmente, es necesario contar con un permiso para poder tener acceso al estndar IEEE Std 830-1998. Estructura de una Especificacin de requerimientos. La IEEE Std 830-1998 define la siguiente estructura para una especificacin de requerimientos, cada una de las secciones mencionadas a continuacin se detalla y se explica en el documento 830: 1. Introduccin 1.1. Objetivo 1.2. mbito 1.3. Definiciones, Siglas y Abreviaturas 1.4. Referencias 1.5. Visin Global 2. Descripcin general 2.1. Perspectiva del producto 2.2. Funciones del producto 2.3. Caractersticas del usuario 2.4. Limitaciones generales 2.5. Supuestos y dependencias 3. Requerimientos especficos Apndices ndice La IEEE Std 830-1998 es parte de los estndares que es necesario cubrir cuando se pretende cumplir con las normas de calidad, por lo tanto, esta estructura se respeta en la mayora de las especificaciones de requerimientos en cualquier parte del mundo cuando se elaboran sistemas de software a nivel industrial. En cuanto a la seccin 3 requerimientos especficos, la IEEE Std 830-1998 propone ocho plantillas diferentes a elegir, y son las siguientes: A.1.- Plantilla de SRS organizada por el modo (versin 1). A.2.- Plantilla de SRS organizada por el modo (versin 2). A.3.- Plantilla de SRS organizada por la clase del usuario. A.4.- Plantilla de SRS organizada por el objeto. A.5.- Plantilla de SRS organizada por el rasgo o caracterstica. A.6.- Plantilla de SRS organizada por el estmulo.

A.7.- Plantilla de SRS organizada por la jerarqua funcional. A.8.- Plantilla de SRS con organizacin mltiple. A manera de ejemplo, se muestra la estructura de la seccin 3 utilizando la plantilla de SRS organizada por el modo (versin 1). 3. Los requerimientos especficos 3.1 requerimientos de las interfaces externas 3.1.1 interfaz con el usuario 3.1.2 interfaz con el hardware 3.1.3 interfaz con el software 3.1.4 interfaces de comunicaciones 3.2 requerimientos funcionales 3.2.1 modo 1 3.2.1.1 requerimiento 1.1 funcional 3.2.1.n requerimiento 1.n Funcional 3.2.2 modo 2 3.2.m Modo m 3.2.m.1 requerimiento Funcional m.1 3.2.m.n requerimiento Funcional m.n 3.3 Requerimientos del desarrollo 3.4 Restricciones del diseo 3.4.1. Acatamiento de estndares 3.4.2. Limitaciones hardware 3.5 Atributos de sistema de software 3.6. Otros requerimientos

Revisar los siguientes enlaces para observar un ejemplo de Especificacin de requerimientos utilizando el estndar IEEE 830 y la descripcin de cada uno de sus componentes http://www.slideshare.net/Juan_Tapias/formato-ieee830srs-lleno http://www.slideshare.net/amerino2010/ieee-830

Ejemplo Definicin de Requerimientos de Usuario

Requerimiento del cliente: El software debe proveer un medio para representar y acceder a archivos externos creados por otras herramientas Lo anterior podra dar como resultado la siguiente Especificacin de Requerimientos del sistema 1.1 1.2 1.3 1.4 1.5 Al usuario se le proveer con los recursos para definir el tipo de archivos externos. Cada tipo de archivo externo tendr una herramienta asociada que ser aplicada al archivo. Cada tipo de archivo externo se representar como un icono especfico sobre la pantalla del usuario. Se proveern recursos para que el usuario defina el icono que representa un tipo de archivo externo. Cuando un usuario selecciona un icono que representa un archivo externo, el efecto de esa seleccin es aplicar la herramienta asociada con este tipo de archivo al archivo representado por el icono seleccionado.

Requerimientos No Funcionales Son aquellos requerimientos que no se refieren directamente a las funciones especficas que entrega el sistema, sino a las propiedades emergentes de ste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema, como la capacidad de los dispositivos de entrada/salida y la representacin de datos que se utiliza en las interfaces del sistema. Sin embargo, estos requerimientos no siempre se refieren al sistema de software a desarrollar. Definen cualidades o atributos globales del sistema, o Establecen restricciones sobre el producto desarrollado, el proceso de desarrollo o externas. No estn generalmente relacionados con la funcionalidad del sistema No hay una distincin clara entre requisitos funcionales y no funcionales Expresar un requisito como funcional o no funcional depende del nivel de detalle requerido en el documento de requisitos

Tipos - Funcionales vs No Funcionales Posibles Ejemplos: El sistema asegurar que los datos estn protegidos frente a accesos no autorizados Generalmente sera considerado como un requisito no funcional porque el requisito no se refiere a una funcionalidad especfica del sistema El sistema incluir un procedimiento de autorizacin de usuario en el que los usuarios se identifican mediante un nombre de usuario y una contrasea. Slo los usuarios autorizados pueden acceder a los datos del sistema El requisito especifica con ms detalle una funcin que debe ser incorporada en el sistema > Requisito Funcional

MTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO FUNCIONALES PROPIEDAD Rapidez Tamao Facilidad de uso Fiabilidad MEDIDA Transacciones procesadas por segundo Tiempo de respuesta al usuario y a eventos Tiempo de actualizacin de la pantalla KB's Tamao de RAM Tiempo de capacitacin Nmero de ventanas de ayuda Tiempo promedio entre fallas Probabilidad de no disponibilidad Tasa de ocurrencia de las fallas Disponibilidad Tiempo de reinicio despus de fallas Porcentaje de eventos que provocan las fallas Probabilidad de corrupcin de los datos despus de las fallas Porcentaje de declaraciones dependientes del objetivo Nmero de sistemas objetivo

Robustez Portabilidad

Requerimientos No funcionales. Requerimiento de Producto La interfaz del usuario del software se implementara como HTML simple sin marcos o applets Java. Requerimiento organizacional El proceso de desarrollo del sistema de y los documentos a entregar debern ajustarse al proceso y a los productos a entregar definidos en el standard internacional. Requerimiento externo El sistema no deber revelar al personal de la biblioteca que lo utilice ninguna informacin personal de los usuarios del sistema, aparte del nombre y nmero de referencia de la biblioteca.