INGENIERÍA DE REQUISITOS
En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería
de requerimientos comprende todas las tareas relacionadas con la
determinación de las necesidades o de las condiciones a satisfacer para un
software nuevo o modificado, tomando en cuenta los diversos requisitos de los
inversores, que pueden entrar en conflicto entre ellos.
Muchas veces se habla de requerimientos en vez de
requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe
ser traducida como requisito, mientras que requerimiento se traduce al inglés
como request.
El propósito de la ingeniería de requisitos es hacer que los
mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el
proyecto. Los buenos requisitos deben ser medibles, comprobables, sin
ambigüedades o contradicciones, etc.
IMPLICACIONES
La Ingeniería de Requisitos implica todas las actividades
del ciclo de vida dedicadas a:
·
La
educción (a veces llamada "elicitación", debido a una mala traducción
de "elicitation") de los requisitos de usuario.
·
El
análisis y negociación de requisitos para derivar requisitos adicionales.
·
La
documentación de los requisitos como especificación.
·
La
validación de los requisitos documentados contra las necesidades de usuario.
·
Así
como los procesos que apoyan estas actividades.
Fases
de implementación
Desde un punto de vista conceptual, las actividades son de
cinco clases.
·
Obtener
requisitos: a través de entrevistas o
comunicación con clientes o usuarios, para saber cuáles son sus expectativas.
·
Analizar
requisitos: detectar y corregir las
falencias comunicativas, transformando los requisitos obtenidos de entrevistas
y requisitos, en condiciones apropiadas para ser tratados en el diseño.
·
Documentar
requisitos: igual que todas las etapas,
los requisitos deben estar debidamente documentados.
·
Verificar
los requisitos: consiste
en comprobar el correcto funcionamiento de un requisito en la aplicación.
·
Validar
los requisitos: comprobar
que los requisitos implementados se corresponden con lo que inicialmente se
pretendía.
2.1.
Tareas de la ingeniería de requisitos
¿QUÉ ES?
Ayuda a los ingenieros de software a entender mejor
el problema en cuya solución trabajarán.
¿Por qué es importante? Se debe entender lo que el
cliente quiere antes de comenzar a diseñar y construir un sistema.
Toma en cuenta errores, coste y tiempo.
La IR trata de los principios, métodos, técnicas y
herramientas que permiten descubrir, documentar y mantener los
requisitos, de forma sistemática y repetible.
PROPÓSITO A OBTENER
El objetivo del proceso de la ingeniería de
requisitos es darle a todas las partes una explicación escrita del problema.
Es esencial que se haga un esfuerzo real por
entender los requisitos de un problema antes de intentar resolverlo.
REQUISITOS
FUNCIONALES Y NO FUNCIONALES
Funcionales
Describen los servicios que se esperan del
sistema.
No funcionales
Restricciones sobre los requisitos funcionales
Existen dos tipos:
·
Orientados al usuario
·
Orientados al desarrollador
INICIO
Se inicia muchas veces por:
·
Identificar nueva necesidad de negocios.
·
Se descubre un nuevo mercado.
·
Se descubre un nuevo servicio.
ELABORACIÓN
Objetivo: Desarrollar modelo técnico refinado de
las funciones, características y restricciones del software.
Se conduce mediante la creación y refinamiento de
escenarios.
El resultado final es un modelo de análisis que
define
El dominio de la información.
Funciones.
Comportamiento del problema.
NEGOCIACIÓN
Clientes, usuarios y otros interesados deben
ordenar sus requisitos y luego discutir los conflictos relacionados con la
prioridad.
Hacer estimaciones preliminares del esfuerzo
requerido para su desarrollo.
Mediante un enfoque iterativo los requisitos se
eliminan, combinan o modifican.
VALIDACIÓN
Examina la especificación para asegurar
que los requisitos de software se han establecido de manera precisa.
2.2. Técnicas de
la Ingeniería de Requisitos
Técnicas
Principales
La ingeniería de requisitos puede
ser un proceso largo y arduo para el que se requiere de habilidades
psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la
gente, así que es importante identificar a todos los actores involucrados,
considerar sus necesidades y asegurar que entienden las implicaciones de los
nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los
requisitos del cliente. Históricamente, esto ha incluido técnicas tales como
las entrevistas, o talleres con grupos para crear listas de requisitos.
Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando
sea necesario, el analista empleará una combinación de estos métodos para
establecer los requisitos exactos de las personas implicadas, para producir un
sistema que resuelva las necesidades del negocio.
Entrevistas
Las entrevistas son un método común. Por lo general
no se entrevista a toda la gente que se relacionará con el sistema, sino a una
selección de personas que represente a todos los sectores críticos de la
organización, con el énfasis puesto en los sectores más afectados o que harán
un uso más frecuente del nuevo sistema.
Talleres
Los requisitos tienen a menudo implicaciones
cruzadas desconocidas para las personas implicadas individuales y que a menudo
no se descubren en las entrevistas o quedan incompletamente definidas durante
la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un
ambiente controlado, talleres facilitados por un analista del negocio, en donde
las personas implicadas participan en discusiones para descubrir requisitos,
analizan sus detalles y las implicaciones cruzadas. A menudo es útil la
selección de un secretario dedicado a la documentación de la discusión,
liberando al analista del negocio para centrarse en el proceso de la definición
de los requisitos y para dirigir la discusión.
Forma de contrato
En lugar de una entrevista, se pueden llenar
formularios o contratos indicando los requisitos. En sistemas muy complejos
éstos pueden tener centenares de páginas.
Objetivos medibles
Los requisitos formulados por los usuarios se toman
como objetivos generales, a largo plazo, y en cambio se los debe analizar una y
otra vez desde el punto de vista del sistema hasta determinar los objetivos
críticos del funcionamiento interno que luego darán forma a los comportamientos
apreciables por el usuario. Luego, se establecen formas de medir el progreso en
la construcción, para evaluar en cualquier momento qué tan avanzado se
encuentra el proyecto.
Prototipos
Un prototipo es una
pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una
vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos
aspectos antes de llegar al producto.
2.3
Modelado de Requisitos
La metodología
presentada por Weitzenfeld en la que, para la fase de requisitos
sugiere especificar los siguientes modelos:
a) Modelo de casos de uso, b)
Modelo de interfaces y c) Modelo de dominio
.
El primero es un
diagrama gráfico que ilustra la relación del usuario con el sistema y se
acompaña de una plantilla descriptiva textual. El segundo busca definir las interfaces
que contendrá el sistema y el tercero pretende
Identificar las
clases (conceptos) propios del campo de aplicación que se desea automatizar. La
importancia de la captura de requisitos ha dado lugar a la definición de un
área de estudio denominada Ingeniería de Requisitos y al establecimiento de
estándares para su documentación. En el Modelo de Casos de Uso (De
Comportamiento) se especifica la funcionalidad que ofrecerá el sistema desde el
punto de vista de usuario. Aquí intervienen dos conceptos clave, los actores,
que representan los distintos papeles que desempeñan los usuarios y los propios
casos de uso, es decir las funcionalidades del sistema. Los casos de uso se
representan gráficamente, como se ilustra enseguida y se acompañan de una plantilla
textual que describe propiamente el diagrama.
2.4. Herramientas CASE para la Ingeniería de requisitos.
USO DE
PROTOTIPOS.
Un proceso interactivo
del desarrollo de sistemas en el cual los requerimientos son convertidos en un
sistema que trabaja, y que es continuamente revisado a través de un trabajo
conjunto entre un analista y los usuarios.
JOINT
APPLICATION DESIGN (JAD).
Un proceso estructurado
en el cual los usuarios, gerentes y analistas, trabajan juntos varios días en
una serie de reuniones intensivas para especificar o revisar requerimientos de
sistemas.
HERRAMIENTAS CASE (COMPUTER-AIDED SOFTWARE
ENGINEERING).
Uso de herramientas para la ingeniería de software asistida por computadora
para aumentar la productividad, comunicarse más efectivamente con los usuarios
e integrar el trabajo que realizan los analistas en el sistema, desde el
principio hasta el fin del ciclo de vida.
GROUPWARE. Software
que está diseñado para ser usado en una red y servir a un grupo de usuarios que
trabajan en un proyecto relacionado.
Estas herramientas ayudan a los especialistas en sistemas a documentar un
sistema existente, ya sea manual o automatizado. También sirve para
determinar los requerimientos de una nueva aplicación.
