IEEE830

Introducción:

El análisis de requisitos es una de las tareas más importantes en el ciclo de vida del desarrollo de software, ya que este establece que debe hacer el sistema, basándose en las características y atributos que este debe poseer, omitiendo el cómo será su implementación, fase posterior del diseño del 
sistema.

El análisis de requisitos se puede definir como el estudio de las necesidades de los usuarios para llegar a una definición exacta de los requisitos del sistema, así como el refinamiento y proceso de estudios de estos. Esta definición es proporcionada por el IEEE, normativa útil para redactar la Especificación de Requisitos de Software (ERS), el cual es el documento final con todo el contenido de cómo se comportara a futuro el sistema según la necesidad del cliente.

Objetivos de una ERS:

-          Ayuda al cliente a describir claramente lo que desea obtener mediante un software. Este proceso de retroalimentación es clave, ya que el cliente es quien tiene el mayor conocimiento sobre los procesos que se llevan a cabo y así también se siente participe del propio desarrollo.

-          Ayuda al desarrollador a saber que es realmente lo que quiere un cliente, ante las indecisiones o desconocimientos que estos puedan presentar. Las ERS ayudan al desarrollador dándole una base por donde partir el trabajo.

-          Servir como base para desarrollos estándares de ERS, donde cada entidad puede desarrollar su propio estándar según las necesidades que el sistema tenga.

Las características de un ERS son:

-          Debe ser Correcta, es decir, que cada requisito represente una necesidad real.

-          No debe ser ambigua: solo debe tener una interpretación en cuanto a las características del producto final.

-          Debe tener completitud en requisitos, definición de respuestas a las posibles entradas, etiquetado de figuras e imágenes y definición de términos.

-          Debe ser Verificable: que se pueda chequear el software con respecto a un requisito.

-          Debe ser consistente, es decir, que ningún requisito entre en conflicto con otro.

-          Debe ser clasificada: tomar la importancia correspondiente a cada requisito.

-          Modificable: Que de haber un cambio, sea realizado de manera fácil, rápida y consistente, con requisitos no redundantes.

-          Explorable en sus requisitos, donde el origen de este sea recorrido tanto hacia atrás como adelante, con referencias.

La ERS es una descripción que debe decir ciertas cosas de una determinada manera. Uno de estos estándares es el IEEE380.

A continuación se presenta como es la estructura según el IEEE en su estándar 830.

1.       Introducción

Aquí se proporciona un resumen del documento de ERS.

1.1.    Propósito

Se define el propósito  del documento y a quién va dirigido.

1.2.    Ámbito del Sistema

Aquí se define el nombre del sistema,  se explica lo que hace y no hace, la descripción de beneficios, objetivos y metas.

1.3.    Definiciones, Acrónimos y Abreviaturas

Se definen los términos utilizados en el desarrollo de la ERS

1.4.    Referencias

Se presenta un listado de los documentos referenciados.

1.5.    Visión general del  documento

En esta sección se describe brevemente la organización y contenidos de la ERS.

2.       Descripción General

Aquí se describenlos factores que afectan al producto y sus requisitos. Se define el contexto de cada requisito.

2.1.    Perspectiva del Producto

En esta subsección se debe relacionar el futuro sistema con otros productos. Se pueden considerar los siguientes tópicos.

2.1.1. Indicar si es producto independiente o parte de un sistema mayor

2.1.2. Interfaces del Sistema

2.1.3. Interfaces de Usuarios

2.1.3.1.             Características Lógicas de Interfaz

2.1.3.2.             Cuestiones de Optimización del Interfaz de Usuario

2.1.4. Interfaces de Hardware

2.1.5. Interfaces de Software

2.1.5.1.             Descripción del Software Utilizado

2.1.5.2.             Propósito del Interfaz

2.1.5.3.             Definición de Interfaz: Contenido y Formato

2.1.6. Interfaces de Comunicaciones

2.1.7. Limitaciones de Memoria

2.1.8. Operaciones

2.1.8.1.             Modos de Operación de los grupos de Usuario

2.1.8.2.             Periodos de Operación Interactiva y Automáticas

2.1.8.3.             Funciones de Respaldo del Procesamiento de Datos

2.1.8.4.             Operaciones de Backup y Recuperación

2.1.9. Requerimientos para Adaptación de Ubicación

2.1.9.1.             Indicar cualquier dato de inicialización especifica en cualquier lugar, modo de operación.

2.1.9.2.             Características que deben ser modificadas para una instalación en particular

2.2.    Funciones del Producto

En esta sección se proporciona la información de las funciones principales que el software debe llevar a cabo. Debe ser legible tanto por el cliente como por el desarrollador.

2.3.    Características de los Usuarios

Se describe el usuario al cual se dirige esta aplicación, asi como su experiencia técnica, nivel de conocimientos, etc.

2.4.    Restricciones

Se indica aquí cualquier limitación impuesta por el cliente al desarrollador. Pueden ser por políticas empresariales, límite de software y hardware, protocolos de comunicación, etc.

2.5.    Suposiciones y Dependencias

En esa sección se describen aquellos factores que, de cambiar, pueden afectar los requisitos del sistema.

2.6.    Requisitos Futuros

Aquí se esboza alguna mejora a futuro del sistema.

3.       Requisitos Específicos

Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos.

3.1.    Interfaces Externas

Se describen los requisitos que afectan a la interfaz de usuario, interfaz con otros sistemas e interfaces de comunicación.

3.2.    Funciones

En esta subsección se especifican todas las funciones que debe llevar a cabo el software. Debe ser organizada según los tipos de usuario, los objetos (entidades del mundo real reflejadas en el sistema), por objetivos, estímulos y jerarquía funcional.

3.3.    Requisitos de Rendimiento

Se detallarán los requisitos relacionados con la carga que se espera tenga que soportar el sistema. Por ejemplo, el número de terminales, el número esperado de usuarios simultáneamente conectados, número de transacciones por segundo que deberá soportar el sistema, etc.

También, si es necesario, se especificarán  los requisitos de datos, es decir, aquellos requisitos que afecten a la información que se guardará en la base de datos.

3.4.    Restricciones de Diseño

Es todo aquello que restrinja las decisiones relativas al diseño de la aplicación.

3.5.    Atributos del Sistema

Se detallan los atributos de calidad (las “ilities”) del sistema: Fiabilidad, mantención, portabilidad, y, muy importante, la seguridad. Deberá especificarse qué tipos de usuario están autorizados, o no, a realizar ciertas tareas, y cómo se implementarán los mecanismos de seguridad (por ejemplo, por medio de un login y una password).

3.6.    Otros Requisitos

Cualquier otro requisito que no encaje en otras secciones.

4.       Apéndices

Pueden contener todo tipo de información 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 análisis de costes.

3. Restricciones acerca del lenguaje de programación

5.       Índice

Conclusión:

                
La importancia de contar con una buena definición de las especificaciones de requerimientos es tener la comprensión total de las necesidades del usuario. Puede estar totalmente bien diseñado y codificado el software, pero de no analizarse bien los requerimientos del cliente puede llevar a que este se sienta defraudado y a la frustración del desarrollador.

                
El documento de especificación de requisitos del software indica las necesidades del cliente y lo que deben implementar los desarrolladores. Es la principal razón por la cual la fase de análisis de requerimientos tiene tanta importancia.

La existencia de un estándar como el IEEE830 permite la coherencia en la especificación de requisitos y ayuda a no dejar cabos sueltos.