5.
Requerimientos del
Software
Rafael Llamas C.
Tópicos
Requerimientos funcionales y no funcionales.
Requerimientos del usuario.
Requerimientos del sistema.
El documento de requerimientos del software.
5.2 Requerimientos del Usuario
Describen los requerimientos funcionales y no funcionales de tal forma
que sean comprensibles por los usuarios del sistema.
Únicamente especifican el comportamiento externo del sistema, y evitan
en cuanto sea posible, las características de diseño del sistema.
Deben redactarse utilizando el lenguaje natural, representaciones y
diagramas intuitivos.
5.2 Requerimientos del Usuario
Problemas al redactar en lenguaje
natural:
1. Falta de claridad
2. Confusión de requerimientos
3. Conjunción de requerimientos
5.2 Requerimientos del Usuario
En el documento de requerimientos es una buena práctica
separar los requerimientos del usuario de los detallados del
sistema.
Cuando los requerimientos del usuario incluyen demasiada
información, restringen la libertad del desarrollador del
sistema para proveer soluciones innovadoras a los
problemas del usuario y hace que los requerimientos sean
difíciles de comprender.
La base asociada a los requerimientos es importante, ayuda
a los desarrolladores y mantenedores del sistema a
entender por qué el requerimiento se incluye y a valorar el
impacto de los cambios en éstos.
5.2 Requerimientos del Usuario
Para minimizar las malas interpretaciones al redactar los
requerimientos del usuario, se recomienda seguir unas
pautas sencillas:
1. Inventar un formato estándar y asegurar que todos los
requerimientos se adhieren al formato.
2. Utilizar el lenguaje de forma consistente. Distinguir entre los req.
Deseables y los obligatorios.
3. Resaltar el texto (con negritas o itálicas) para ver las partes
claves del requerimiento.
4. Evitar, hasta donde sea posible, el lenguaje técnico de
computación.
5.3 Requerimientos del sistema
Estos son descripciones más detalladas de los requerimientos del usuario.
Sirven como base para definir el contrato de la especificación del sistema
y, por lo tanto, debe ser una especificación completa y consistente del
sistema.
Son utilizados por los ingenieros de software como el punto de partida
para el diseño del sistema.
La especificación de requerimientos del sistema incluye diferentes modelos
como el de objetos o el de flujo de datos.
En principio, los requerimientos del sistema deberán establecer lo que éste
hará y no la manera en que se implementará.
5.3 Requerimientos del sistema
En el nivel de detalle requerido para especificar un sistema
completamente, es casi imposible excluir toda la información de diseño.
Existen varias razones para esto:
1. Una arquitectura inicial del sistema se define para ayudar a estructurar la
especificación de requerimientos. Se organizan acorde a los diferentes
subsistemas que componen el sistema.
2. En muchos casos, los sistemas deben interoperar con otros ya existentes. Esto
restringe el diseño y éstas restricciones generan requerimientos para el nuevo
sistema.
3. El uso de un diseño específico es un requerimiento externo del sistema.
5.3 Requerimientos del sistema
Algunos problemas adicionales pueden surgir con el uso del lenguaje
natural ara detallar la especificación:
1. La comprensión del lenguaje natural radica en que los lectores y redactores de
la especificación utilicen la misma palabra para el mismo concepto.
2. Una especificación de requerimientos en lenguaje natural es demasiado
flexible. Se puede decir lo mismo de formas completamente diferentes.
3. No existe una forma fácil de modularizar los requerimientos en lenguaje
natural. Es difícil exhibir todos los requerimientos relacionados.
Debido a estos problemas, la redacción de especificación de requerimientos en L.N.
conlleva a malas interpretaciones. A menudo éstas se descubren hasta fases
posteriores del proceso y resolverlas puede llegar a ser muy caro.
5.3 Requerimientos del sistema
Existen varias alternativas a la utilización del lenguaje natural que agregan
estructura a la especificación y ayudan a reducir la ambigüedad.
Lenguaje natural estructurado
Lenguajes de descripción de diseño
Notaciones gráficas
Especificaciones matemáticas
5.3.1 Especificaciones en lenguaje estructurado
Este lenguaje es una forma restringida del L.N. para redactar los
requerimientos del sistema. La ventaja de este enfoque es que mantiene
mucha de la expresividad y comprensión del L.N. y asegura que cierto
grado de uniformidad se imponga a la especificación.
Las notaciones del lenguaje estructurado delimitan la terminología
utilizada y emplean plantillas para especificar los requerimientos del
sistema.
Incorporan construcciones de control derivadas de los lenguajes de
programación y manifestaciones gráficas para dividir la especificación.
Utilizar un enfoque basado en formas para especificar los requerimientos,
implica definir una o mas formas o plantillas estándar para expresar estos
requerimientos.
Cuando se utiliza una forma estándar para especificar los requerimientos
funcionales, se debe incluir la siguiente información:
ECLIPSE/Workstation/Tools/DE/FS/3.5.1
Function Add node
Description Adds a node to an existing design. The user selects the type of node, and its position.
When added to the design, the node becomes the current selection. The user chooses the node position by
moving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier.
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
Destination The design database. The design is committed to the database on completion of the
operation.
Requires Design graph rooted at input design identifier.
Pre-condition The design is open and displayed on the user's screen.
Post-condition The design is unchanged apart from the addition of a node of the specified type
at the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
El uso de especificaciones formateadas elimina algunos de los problemas de la
espec. del L.N. en el sentido de que existe menos variación de la especificación y de
que los requerimientos se dividen de forma mas efectiva.
5.3.2 Especificación de requerimientos utilizando un PDL
Este es un lenguaje derivado de uno de programación como Java o Ada.
Contiene construcciones abstractas adicionales para incrementar su poder
de expresividad.
La ventaja de utilizar un PDL es que se verifica de manera sintáctica y
semántica con herramientas de software.
El uso de PDLs conduce a especificaciones detalladas y, algunas veces,
son muy cercanas a la implementación como para que sean incluidas en
un docto. de requerimientos.
Sin embargo se recomienda en dos situaciones:
Cuando una operación se especifica como una secuencia de acciones simples y el
orden de ejecución es importante.
Cuando se tienen que especificar las interfases de hardware y software. En
muchos casos, las interfases entre los subsistemas se definen en la
especificación de req. del sistema.
5.3.2 Especificación de requerimientos utilizando un PDL
Existen desventajas en este enfoque para la especificación
de requerimientos:
1. El lenguaje utilizado para redactar puede no ser suficientemente
expresivo como para describir la funcionalidad del sistema.
2. La notación sólo es comprensible para la gente que tiene
conocimiento de algún lenguaje de programación.
3. Los requerimientos se consideran un diseño de la especificación del
diseño más que un modelo para ayudar al usuario a comprender el
sistema.
5.3.3 La especificación de Interfaces
La gran mayoría de los sistemas de SW deben operar con otros sistemas
implementados e instalados de antemano. Si el nuevo sistema y los existentes
deben trabajar juntos, las interfases de éstos últimos deben especificarse de forma
precisa.
Estas especificaciones se definen al inicio del proceso y se incluyen (como un
apéndice) en el documento de requerimientos.
Existen 3 tipos de interfases que pueden definirse:
1. Interfases de procedimientos, en las cuales los subsistemas existentes ofrecen una variedad
de servicios que se obtienen al invocar a los procedimientos de la interfaz.
2. Las estructuras de datos que pasan de un subsistema a otro.
3. Las representaciones de datos establecidas para un subsistema existente.
Ejemplo de una interfaz de procedimiento ofrecida por un servidor de aplicación.
Este modelo no muestra los detalles de la interfaz. La funcionalidad de las
operaciones de ésta se definen utilizando el lenguaje natural estructurado, utilizando
un PDL basado en Java, o utilizando una notación formal.
5.4 El documento de Requerimientos del software
Este es la declaración oficial de qué es lo que requieren los
desarrolladores del sistema.
Incluye tanto los requerimientos del usuario como una
especificación detallada de los requerimientos del sistema.
Si existe un gran número de requerimientos, los detalles de los
req. se pueden presentar como documentos separados.
Este documento tiene un conjunto diverso de usuarios que va
desde los administradores principales de la organización, quienes
pagan por el sistema, hasta los ingenieros responsables del
software.
5.4 El documento de Requerimientos del software
Posibles usuarios del documento y cómo lo utilizan.
Specify the requirements and
read them to check that they
System customers meet their needs. They
specify changes to the
requirements
Use the requirements
Managers document to plan a bid for
the system and to plan the
system development process
Use the requirements to
System engineers understand what system is to
be developed
System test Use the requirements to
engineers develop validation tests for
the system
System Use the requirements to help
maintenance understand the system and
engineers the relationships between its
parts
5.4 El documento de Requerimientos del software
Heninger (1980) sugiere seis requisitos que debe
satisfacer un documento de requerimientos:
1. Especificará unicamente el comportamiento externo del
sistema.
2. Especificará las restricciones de la implementación.
3. Será fácil de cambiar.
4. Servirá como herramienta de referencia para los
mantenedores del sistema.
5. Registrará las previsiones del ciclo de vida del sistema.
6. Caracterizará las respuestas aceptables para los eventos no
deseados.
5.4 El documento de Requerimientos del software
La IEEE sugiere la siguiente estructura para los documentos de requerimientos:
1.- Introducción
1.1 Propósito del documento de requerimientos.
1.2 Alcance del producto.
1.3 Definiciones, acrónimos y abreviaturas.
1.4 Referencias.
1.5 Resumen del resto del documento.
2.- Descripción general
2.1 Perspectiva del producto.
2.2 Funciones del producto.
2.3 Características del usuario.
2.4 Restricciones generales.
2.5 Suposiciones y dependencias.
3.- Requerimientos específicos
4.- Apéndices
5.- Índice
