Recomendación para la Especificación de Requerimientos de Software de la IEEE. Existe una organización muy importante a nivel internacional llamada IEEE (Institute of Electrical and Electronics Engineers, en español le llaman comunmente la I triple E). Esta organización, produce estándares que se aplican en muchas industrias del mundo. La IEEE, edita revistas de divulgación científica con un prestigio muy alto, y también 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 estándar emitido por la IEEE qué se aprobó en 1998, llamado: IEEE Std 830-1998. Std es la forma de abreviar “Standard” en inglés y el número de la especificación es 830, fue aprobada en 1998 y es una revisión de un estándar previo aceptado en 1993, Por las siglas en inglés, SRS que significan: Software Requirements Specifications, se acostumbra llamar SRS al documento de especificación. En el IEEE Std 830-1998 se habla sobre las características 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 físico, interfaces, usuarios y factores humanos, funcionalidad, documentación, datos, recursos, seguridad y aseguramiento de la calidad). Lo más importante del IEEE Std 830-1998 es que define la estructura que debe tener una especificación de requerimientos, esta estructura se explica en la siguiente sección. Normalmente, es necesario contar con un permiso para poder tener acceso al estándar IEEE Std 830-1998. Estructura de una Especificación de requerimientos. La IEEE Std 830-1998 define la siguiente estructura para una especificación de requerimientos, cada una de las secciones mencionadas a continuación se detalla y se explica en el documento 830: 1. Introducción 1.1. Objetivo 1.2. Ámbito 1.3. Definiciones, Siglas y Abreviaturas 1.4. Referencias 1.5. Visión Global 2. Descripción general 2.1. Perspectiva del producto 2.2. Funciones del producto 2.3. Características del usuario 2.4. Limitaciones generales 2.5. Supuestos y dependencias 3. Requerimientos específicos Apéndices Índice La IEEE Std 830-1998 es parte de los estándares que es necesario cubrir cuando se pretende cumplir con las normas de calidad, por lo tanto, esta estructura se respeta en la mayoría de las especificaciones de requerimientos en cualquier parte del mundo cuando se elaboran sistemas de software a nivel industrial. En cuanto a la sección 3 requerimientos específicos, la IEEE Std 830-1998 propone ocho plantillas diferentes a elegir, y son las siguientes: A.1.- Plantilla de SRS organizada por el modo (versión 1). A.2.- Plantilla de SRS organizada por el modo (versión 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 característica. A.6.- Plantilla de SRS organizada por el estímulo.

A.7.- Plantilla de SRS organizada por la jerarquía funcional. A.8.- Plantilla de SRS con organización múltiple. A manera de ejemplo, se muestra la estructura de la sección 3 utilizando la plantilla de SRS organizada por el modo (versión 1). 3. Los requerimientos específicos 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 diseño 3.4.1. Acatamiento de estándares 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 Especificación de requerimientos utilizando el estándar IEEE 830 y la descripción de cada uno de sus componentes http://www.slideshare.net/Juan_Tapias/formato-ieee830srs-lleno http://www.slideshare.net/amerino2010/ieee-830

Ejemplo Definición 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 podría dar como resultado la siguiente Especificación de Requerimientos del sistema

1.1 Al usuario se le proveerá con los recursos para definir el tipo de archivos externos. 1.2 Cada tipo de archivo externo tendrá una herramienta asociada que será aplicada al archivo. 1.3 Cada tipo de archivo externo se representará como un icono específico sobre la pantalla del usuario. 1.4 Se proveerán recursos para que el usuario defina el icono que representa un tipo de archivo externo. 1.5 Cuando un usuario selecciona un icono que representa un archivo externo, el efecto de esa selección

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 específicas 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 representación 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 están generalmente relacionados con la funcionalidad del sistema

No hay una distinción 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 están protegidos frente a accesos no autorizados

Generalmente sería considerado como un requisito no funcional porque el requisito no se refiere a una funcionalidad específica del sistema

El sistema incluirá un procedimiento de autorización de usuario en el que los usuarios se identifican mediante un nombre de usuario y una contraseña. Sólo los usuarios autorizados pueden acceder a los datos del sistema

El requisito especifica con más detalle una función que debe ser incorporada en el sistema > Requisito Funcional

MÉTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO FUNCIONALES

PROPIEDAD MEDIDA

Rapidez • Transacciones procesadas por segundo • Tiempo de respuesta al usuario y a eventos • Tiempo de actualización de la pantalla

Tamaño • KB's • Tamaño de RAM

Facilidad de uso • Tiempo de capacitación • Número de ventanas de ayuda

Fiabilidad • Tiempo promedio entre fallas • Probabilidad de no disponibilidad • Tasa de ocurrencia de las fallas • Disponibilidad

Robustez • Tiempo de reinicio después de fallas • Porcentaje de eventos que provocan las fallas • Probabilidad de corrupción de los datos después de las fallas

Portabilidad • Porcentaje de declaraciones dependientes del objetivo • Número de sistemas objetivo

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 deberán 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 información personal de los usuarios del sistema, aparte del nombre y número de referencia de la biblioteca.