Espesificadion De Software

1 Introducción

El análisis de requisitos es una de las tareas más importantes en el ciclo de vida del

desarrollo de software, puesto que en ella se determinan los “planos” de la nueva

aplicación.

En cualquier proyecto software los requisitos son las necesidades del producto

que se debe desarrollar. Por ello, en la fase de análisis de requisitos se deben identificar

claramente estas necesidades y documentarlas. Como resultado de esta fase se debe

producir un documento de especificación de requisitos en el que se describa lo que el

futuro sistema debe hacer. Por tanto, no se trata simplemente de una actividad de

análisis, sino también de síntesis.

El análisis de requisitos se puede definir como el proceso del estudio de las

necesidades de los usuarios para llegar a una definición de los requisitos del sistema,

hardware o software, así como el proceso de estudio y refinamiento de dichos

requisitos, definición proporcionada por el IEEE [Piattini, 1996]. Asimismo, se define

requisito como una condición o capacidad que necesita el usuario para resolver un

problema o conseguir un objetivo determinado [Piattini, 1996]. Esta definición se

extiende y se aplica a las condiciones que debe cumplir o poseer un sistema o uno de

sus componentes para satisfacer un contrato, una norma o una especificación.

En la determinación de los requisitos no sólo deben actuar los analistas, es muy

importante la participación de los propios usuarios, porque son éstos los que mejor

conocen el sistema que se va a automatizar. Analista y cliente se deben poner de

acuerdo en las necesidades del nuevo sistema, ya que el cliente no suele entender el

proceso de diseño y desarrollo del software como para redactar una especificación de

requisitos software (ERS) y los analistas no suelen entender completamente el

problema del cliente, debido a que no dominan su área de trabajo.

Así pues, el documento de especificación de requisitos debe ser legible por el

cliente, con lo que se evita el malentendido de determinadas situaciones, ya que el

cliente participa activamente en la extracción de dichos requisitos.

Basándose en estos requisitos, el ingeniero de software procederá al modelado de

la futura aplicación. Para ello, se pueden utilizar diferentes tipos de metodologías entre

las que destacan la metodología estructurada y la metodología orientada a objetos (por

ejemplo DFDs y UML respectivamente).

La metodología estructurada está basada en la representación de las funciones que

debe realizar el sistema y los datos que fluyen entre ellas.

En la metodología orientada a objetos se utiliza el UML [Pierre-Alain, 1997],

mediante el cual podemos representar diagramas (casos de uso) que permiten definir el

sistema desde el punto de vista del usuario estableciendo las relaciones entre el futuro

sistema y su entorno. Estas relaciones se establecen en forma de acciones del usuario y

reacciones del sistema.

E78. Ingeniería del Software ERS según el estándar IEEE 830 2

2 Objetivos de la ERS.

Los principales objetivos que se identifican en la especificación de requisitos software

son [Chalmeta, 2000]:

1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un

determinado software: El cliente debe participar activamente en la especificación

de requisitos, ya que éste tiene una visión mucho más detallada de los procesos

que se llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo.

2. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En

muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS

permite al cliente definir todos los requisitos que desea y al mismo tiempo los

desarrolladores tienen una base fija en la que trabajar. Si no se realiza una buena

especificación de requisitos, los costes de desarrollo pueden incrementarse

considerablemente, ya que se deben hacer cambios durante la creación de la

aplicación.

3. Servir de base para desarrollos de estándares de ERS particulares para cada

organización: Cada entidad puede desarrollar sus propios estándares para definir

sus necesidades.

Una buena especificación de requisitos software ofrece una serie de ventajas entre

las que destacan el contrato entre cliente y desarrolladores (como ya se ha indicado con

anterioridad), la reducción del esfuerzo en el desarrollo, una buena base para la

estimación de costes y planificación, un punto de referencia para procesos de

verificación y validación, y una base para la identificación de posibles mejoras en los

procesos analizados.

La ERS es una descripción que debe decir ciertas cosas y al mismo tiempo debe

decirlas de una determinada manera. En este documento se presentará una de las formas

que viene especificada por el estándar IEEE 830.

Una ERS forma parte de la documentación asociada al software que se está

desarrollando, por tanto debe definir correctamente todos los requerimientos, pero no

más de los necesarios. Esta documentación no debería describir ningún detalle de

diseño, modo de implementación o gestión del proyecto, ya que los requisitos se deben

describir de forma que el usuario pueda entenderlos. Al mismo tiempo, se da una mayor

flexibilidad a los desarrolladores para la implementación.

Así pues, el grado y el lenguaje utilizado para la documentación de los requisitos

estarán en función del nivel que el usuario tenga para entender dichas especificaciones.

E78. Ingeniería del Software ERS según el estándar IEEE 830 3

3 Características de una buena ERS

Las características deseables para una buena especificación de requisitos software que

se indican en el IEEE son las siguientes [Chalmeta, 2000][Piattini, 1996]:

· Correcta

· No ambigua

· Completa

· Verificable

· Consistente

· Clasificada

· Modificable

· Explorable

· Utilizable durante las tareas de mantenimiento y uso

3.1 Corrección

La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad

real. La corrección de la ERS implica que el sistema implementado será el sistema

deseado.

3.2 Ambigüedad

Un documento es no ambiguo si y solo si cada requisito descrito tiene una única

interpretación. Cada característica del producto final debe ser descrita utilizando un

término único y, en caso de que se utilicen términos similares en distintos contextos, se

deben indicar claramente las diferencias entre ellos. Incluso se puede incluir un glosario

en el que indicar cada significado específicamente.

Los analistas deben poner un cuidado especial a la hora de especificar los

requisitos. El hecho de utilizar el lenguaje natural para hacer la ERS comprensible a los

usuarios supone un riesgo muy elevado, porque el lenguaje natural puede llegar a ser

muy ambiguo.

Ejemplo:

En términos generales, el lenguaje natural es de los más ambiguos. Por el

contrario existen los lenguajes formales que no son ambiguos, pero son más difíciles de

aprender y menos comprensibles para el que no los conoce.

Todos los clientes tienen el mismo campo de control

1.- ¿Todos tienen el mismo valor en el campo de control?

2.- ¿Todos los campos de control tienen el mismo formato?

3.- ¿Un campo de control se usa para todos los clientes?

E78. Ingeniería del Software ERS según el estándar IEEE 830 4

3.3 Completitud

Una ERS es completa si:

· Incluye todos los requisitos significativos del software (relacionados con la

funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).

· Existe una definición de respuestas a todas las posibles entradas, tanto válidas

como inválidas, en todas las posibles situaciones.

· Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se

utiliza, se debe razonar suficientemente el porqué no se ha utilizado dicho

apartado.

· Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como

definidos todos los términos y unidades de medida empleados.

La ERS debe ser siempre completa, aunque en ocasiones esto no será posible. Por

ejemplo si todavía no se han determinado los formatos de los informes finales o por

cualquier razón se esta esperando la publicación de un Real Decreto o un reglamento

sobre impuestos.

3.4 Verificabilidad

Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso

por el cual una persona o una máquina pueda chequear que el software satisface dicho

requerimiento.

Ejemplo

3.5 Consistencia

Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son

contradictorios o entran en conflicto. Se pueden dar tres casos:

· Requisitos que describen el mismo objeto real utilizando distintos términos.

· Las características especificadas de objetos reales. Un requisito

...