: Análisis de requisitos.
Análisis estructurado. Modelización conceptual de funciones.
Objetivo de la
Unidad de Trabajo: Introducir los fundamentos del análisis de requisitos y la metodología
de análisis
estructurado.
(Tiempo
estimado: 15 períodos)
Hechos/conceptos
(contenidos soporte)
ü Introducción al análisis de requisitos (A.R.). Características de
una buena especificación de requisitos de software (E.R.S.). Documentación de
la E.R.S.
ü Análisis estructurado como método de A.R. Ampliaciones: Análisis
estructurado (A.E.) moderno.
ü Componentes. Etapas de desarrollo de un sistema con A.E.
ü Modelización conceptual de funciónes. Diagrama de flujo de datos
(D.F.D.). Diccionario de datos. Técnicas para construir especificaciones de
procesos. Diagramas de descomposición funcional (D.D.F.). Tipos de
comprobaciones a realizar sobre una especificación estructurada
ANÁLISIS DE REQUISITOS
3.1.- INTRODUCCIÓN AL ANALISIS DE REQUISITOS
Como se dijo en capítulos anteriores, el término análisis aplicado a sistemas significa
descomponer el sistema en sus componentes para estudiar cada uno
de ellos tanto como un
ente aislado como en interacción con el resto de los componentes.
Para ser útil, al análisis debe seguir un proceso de síntesis que consistirá en unir los
componentes del sistema para determinar cómo funcionan en
conjunto.
Cuando se habla de una fase del ciclo de vida, el análisis
consiste en producir un
documento de especificación de requisitos que describa lo que el
sistema debe hacer, pero
no cómo hacerlo. No se trata pues de una actividad sólo de
análisis, sino también de
síntesis.
Se define el análisis de requisitos como “el proceso del estudio de las necesidades de
los usuarios para llegar a una definición de los requisitos del
sistema, de hardware o de
software, así como el proceso de estudio y refinamiento de dichos
requisitos” (Estándar
IEEE Std. 610 [IEEE 1990]).
El Requisito es pues “una condición o capacidad que necesita el usuario para resolver
un
problema o conseguir un objetivo determinado” (por ejemplo, poder listar rápidamente
todos los clientes que deben dinero). Por extensión, el término Requisito se aplica también
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”.
La definición de los requisitos en un proyecto debe ser fruto del
trabajo conjunto de
las partes involucradas en su desarrollo: Suministradores de
software (analistas), clientes
y usuarios. Ningún colectivo ante citado puede redactar la Especificación de Requisitos
Software (ERS) ya que
• El cliente no suele conocer el proceso de diseño y
desarrollo del software.
• Los analistas no entienden completamente el problema
del cliente dado que no dominan
su área de trabajo.
La fase de análisis de requisitos, según el estándar IEEE 1074
[IEEE, 1991] se desglosa
en tres grandes actividades:
• Definir los requisitos de software. Tarea iterativa para crear una definición o
especificación preliminar de los requisitos que debe cumplir el software
a partir de
la información obtenida mediante técnicas de recogida de
información analizadas en
el capítulo anterior.
• Definir los requisitos de las interfaces del
software con el resto del sistema y
con el exterior. Deben definirse las propiedades que se deben
satisfacer para
obtener una interacción eficaz con otros elementos del sistema (el
usuario, el
hardware, otras aplicaciones software, ...). En particular la
interfaz con el usuario
es crítica para la facilidad de uso (y por tanto el éxito) del
software.
Los requisitos de interfaz con otras aplicaciones deben describir
las características
para que el software se relacione con ellas, las cuales pueden
estar muy influenciadas por
restricciones de trabajo del sistema (S.O. utilizado, SGBD
empleado, Compiladores,
controladores de red, etc.).
Así mismo deben definirse las características de las
interrelaciones con elementos
hardware.
• Integrar los requisitos en un documento de
especificación y asignarles
prioridades. La asignación de prioridades debe hacerse en función de su
importancia o los beneficios que puede aportar su cumplimiento.
Otra manera de describir las actividades que se realizan en la
fase de análisis de
requisitos sería la siguiente (Raghavan, et al., 1995):
• Extracción o determinación de requisitos.
Proceso mediante el cual los clientes o
futuros usuarios del software descubren, revelan, articulan y
comprenden los requisitos
que desean.
• Análisis de requisitos. Proceso de razonamiento sobre los requisitos obtenidos
en la
etapa anterior, detectando y resolviendo posibles inconsistencias
o conflictos, coordinando
los requisitos relacionados entre sí, etc.
• Especificación de requisitos. Proceso de redacción o registro de los requisitos.
Suele
recurrirse a un lenguaje natural, lenguajes formales, modelos,
gráficos, etc.
• Validación de los requisitos. Confirmación, por parte del usuario o el cliente de
que los
requisitos especificados son válidos, consistentes, completos,
etc.
Aunque estas actividades no tienen por qué realizarse en
secuencia, ya que hay muchas
iteraciones y solapamientos entre ellas, sí marcan un proceso
general para la fase de
análisis.
3.2.- ESPECIFICACIÓN DE REQUISITOS DEL SOFTWARE
3.2–1.- Introducción
Según el estándar IEEE, 1990 se define:
Especificación: Documento que define, de forma completa, precisa y
verificable, los
requisitos, el diseño, el comportamiento u otras características
de un sistema o de un
componente de un sistema
Software: Conjunto de programas, procedimientos y documentación asociada a
la
operación de un sistema informático.
Con estas premisas puede definirse la Especificación de Requisitos del Software
(ERS) como la documentación de los requisitos esenciales (funciones,
rendimiento, diseño,
restricciones y atributos) del software y de sus interfaces
externas [IEEE,1990].
Las dos características fundamentales de una ERS eficaz son:
Incluir información veraz, es decir, coherente con las necesidades reales del
usuario
que se desean satisfacer.
Comunicar dicha información de forma veraz, es decir, de tal manera que se pueda
comprender perfectamente Las exigencias para una ERS conducen a no
excederse a la hora de definirla y construirla, sino mas bien a abordar la descripción
de lo que hay que desarrollar, no el cómo, el cuándo, etc. Se desarrolla el
software. Esto implica:
Describir correctamente todos los requisitos de
software sin incluir requisitos
necesarios.
No describir ningún detalle de diseño de
software, de su verificación, de la
dirección
del proyecto, excepto las restricciones impuestas al diseño que
influyen en los requisitos.
3.2–2.- Características de una buena
Especificación de Requisitos del Sistema (ERS)
Las características deseables para una buena ERS son las
siguientes [IEEE 1984B]:
No ambigua. Cada requisito descrito debe tener una única interpretación.
Completa. Lo será si:
Incluye todos los requisitos
significativos del software
Define la respuesta del software
a todas las posibles clases de datos de
entrada y en todas las posibles situaciones, tanto para los datos
válidos
como para los que no lo son
Está conforme con el estándar de
especificación que se deba cumplir
Están etiquetadas y referenciadas
en el texto todas las figuras, tablas
y diagramas
Si algún término está por
determinar, se debe acompañar de una
descripción de las condiciones que lo han causado y una posible
descripción para eliminarlo
Fácil de verificar. Existencia de algún procedimiento finito y efectivo en
coste para
que se compruebe que el software satisface dicho requisito
Consistente. Lo será sí y sólo sí ningún conjunto de requisitos entran en
conflicto entre
ellos. Pueden darse tres tipos de conflictos:
Dos o más requisitos pueden
describir el mismo objeto real pero utilizan
términos distintos para designarlo
Las características especificadas
de objetos reales pueden estar en
Conflicto
Puede haber conflicto lógico o
temporal entre dos acciones
Determinadas
Fácil de modificar. La estructura y el estilo de la ERS deben permitir que
cualquier
cambio necesario en los requisitos pueda realizarse de forma
fácil, completa y consistente.
Esto implica que la ERS debe:
Tener una organización coherente
y manejable (con una tabla de
contenidos, un índice y referencias cruzadas)
No ser redundante, es decir, el
mismo requisito no debe aparecer en
más de un lugar en la ERS
Facilidad para identificar el origen y las
consecuencias de cada requisito (facilidad
de traza). Se dice que una ERS facilita las referencias con otros
productos del ciclo de
vida si establece un origen claro para cada uno de los requisitos
y si posibilita la referencia
de estos requisitos en desarrollos futuros o en incrementos de la
documentación.
Cuando un requisito de la ERS representa un desglose o una
derivación de otro
requisito, se debe facilitar tanto las referencias hacia atrás como las referencias hacia
delante en el ciclo de vida. Estas
últimas son especialmente importantes para el
mantenimiento del software. Cuando el código o la documentación
son modificados, es
esencial poder comprobar el conjunto total de requisitos que
pueden verse afectados por
estas modificaciones.
Facilidad de utilización durante la fase de
explotación y de mantenimiento. La ERS
debe considerar las necesidades de mantenimiento, incluyendo una
eventual sustitución del
software, especialmente debido a:
El personal que se encarga del
mantenimiento no ha estado relacionado
con el desarrollo del producto software.
Gran parte de los conocimientos y
de la información necesaria para el
mantenimiento se dan por supuestos en la organización del
desarrollo,
pero suelen estar ausentes en la organización de mantenimiento.
3.2–3.- Evolución de las ERS
Normalmente, la ERS deberá ser cambiada a medida que progresa el
producto software
ya que es casi imposible especificar algunos detalles en el
momento en el que se inicia el
proyecto y es casi seguro que se realizarán cambios adicionales
como consecuencia de
haber encontrado deficiencias, defectos e inexactitudes que se
descubren a medida que el
producto evoluciona.
En este proceso deben tenerse en cuenta las consideraciones siguientes:
• El requisito debe ser especificado de la forma mas
completa posible, aun en el caso en
que se prevean de forma inevitable revisiones en el proceso de
desarrollo.
• Debe iniciarse un proceso formal de cambio para
identificar, controlar, seguir e
informar de cambios proyectados tan pronto como sean identificados
Los cambios aprobados en los requisitos deben incluirse en la ERS
de forma que
permita:
• Suministrar una revisión precisa y completa del rastro
de las modificaciones
• Permitir un examen de fragmentos actuales y
reemplazados en la ERS.
3.2–4.- Estructura para las ERS
Un modelo propuesto por el estándar IEEE Std. 830 [IEEE, 1984b] es
el que se
presenta a continuación:
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.- Requisitos específicos
Existen otras normas emitidas por otros organismos que también
aportan esquemas
para documentar las ERS (DOD, 1988, DORFMAN y THYER, 1990).
3.2–5.- Especificación de requisitos de
Interfaces
Las interfaces con el exterior coinciden con lo que
tradicionalmente se ha llamado
entradas y salidas (E / S) del sistema. En el caso del análisis estructurado, pueden
identificarse fácilmente observando los flujos que entran y salen
del sistema en el
diagrama de contexto (del que se hablará posteriormente).
En el caso de las salidas puede hablarse de las pantallas de
presentación de la
información, listados o salida en papel, ficheros, etc. Las entradas
serán pantallas de
introducción de datos mediante teclado, introducción de datos
mediante sensores,
ficheros, etc.
TABLA II
3.- Requisitos específicos
3.1 Requisitos funcionales
3.1.1 Requisito funcional 1
3.1.1.1 Introducción
3.1.1.2 Entradas
3.1.1.3 Procesamiento
3.1.1.4 Salidas
3.1.2 Requisito funcional 2
... ... ... ... ... ...
3.1.N Requisito funcional N
3.2 Requisitos de interfaz externa
3.2.1 Interfaces de usuario
3.2.2 Interfaces de hardware
3.2.3 Interfaces de software
3.2.4 Interfaces de comunicaciones
3.3 Requisitos de ejecución
3.4 Restricciones de diseño
3.4.1 Acatamiento de estándares
3.4.2 Limitaciones hardware
... ... ... ... ... ...
3.5 Atributos de calidad
3.5.1 Seguridad
3.5.2 Mantenimiento
... ... ... ... ... ...
3.6 Otros requisitos
3.6.1 Base de datos
3.6.2 Operaciones
3.6.3 Adaptación de situación
... ... ... ... ... ...
La definición de las interfaces de E / S tiene como objetivo la
estabilización del modo
en que el sistema va a interactuar con el exterior del sistema.
3.3.- VISIÓN GENERAL DE LAS TÉCNICAS DE
ESPECIFICACIÓN
Sobre la clasificación de técnicas de especificación no existe una
regla general por lo
que posiblemente, la forma mas lógica de hacerlo sea por orden
alfabético. Sin embargo,
pueden clasificarse las técnicas bajo dos enfoques diferentes:
Por la forma de representación (gráfica, textual, matricial, DFD, DD, etc.)
Por el enfoque de Modelización bajo los que se crean modelos del
sistema relativos a su
función, información y tiempo.
3.3–1.- Clasificación según la forma de
representación
Gráficas. Utilizan iconos que representan un componente particular del
modelo. Se usan
cuando se quiere resaltar la conexión entre los distintos
componentes del modelo.
Textuales. Se utilizan para especificar con mas detalle los componentes
definidos en
los gráficos mediante una gramática definida mas o menos formal.
Marcos o plantillas. (“Templates”) especifican información relativa a un
componente
de un modelo que ha sido declarado en un diagrama o en otro marco.
Se representan
mediante un formulario que incluye todas sus características.
En la figura se define el contenido de una entidad definida en un
diagrama Entidad /
Relación.
Matriciales. Son técnicas de comprobación entre modelos que permiten estudiar
las
referencias cruzadas entre sus componentes.
No hay comentarios:
Publicar un comentario