INGENIERIA 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 requerimiento debe ser traducida como
requisito, mientras que requerimiento se traduce al inglés como request.
Implicaciones
La
Ingeniería de Requisitos implica todas las actividades del ciclo de vida
dedicadas a:
La
educción (a veces llamada "e licitació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 TECNICAS DE LA
INGENIERÍA DE REQUISITOS
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. Los requisitos
que surgen de las entrevistas a menudo se contradicen unos a otros o se
formulan desde la ignorancia de los detalles del funcionamiento del sistema,
sus potencialidades, interdependencias o limitaciones; por lo que se debe
trabajar con los mismos para corregir sus fallos.
Las entrevistas pueden ser personales
o grupales.
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 terminado.
Casos de uso
Un caso de uso es una
técnica para documentar posibles requisitos, graficando la relación del sistema
con los usuarios u otros sistemas. Dado que el propio sistema aparece como
una caja negra, y sólo se representa su interacción con entidades externas, permite
omitir dichos aspectos y determinar los que realmente corresponden a las
entidades externas. El objetivo de esta práctica es mejorar la comunicación
entre los usuarios y los desarrolladores, mediante la prueba temprana de
prototipos para minimizar cambios hacia el final del proyecto y reducir los
costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.
2.3
MODELADO DE REQUISITOS
Modelado de requisitos
En esta sección se estudiaran los
requisitos, tanto funcionales como no funcionales, que hay que cumplir para que
el software funcione correctamente. Para ello se hará uso de los diagramas de
caso de uso, que especifica los modos de uso (o requisitos funcionales) que va
a tener el sistema, del diagrama de paquetes, que indica como se agrupan los
casos de uso en diferentes subsistemas, y de los diagramas de secuencia, que
indican el flujo a seguir en cada una de las transacciones.
Modelo
funcional
En este apartado se muestran,
mediante los diferentes casos de uso, los requisitos funcionales que tiene la
aplicación, mostrándose también los diferentes subsistemas de la aplicación
mediante el diagrama de paquetes.
Identificar subsistemas
En los siguientes diagramas de
paquetes se pueden ver los subsistemas identificados en la
aplicación. El primer diagrama de
paquetes incluye los casos de uso que componen cada subsistema, mientras que el
segundo diagrama de paquetes únicamente muestra los distintos subsistemas de la
aplicación y su relación con los actores.
Requisitos no funcionales
Los requisitos no funcionales
detectados son los siguientes:
• El entorno de desarrollo inicial
del proyecto es un entorno LAMP (Linux+Apache+MySQL+PHP), aunque este entorno
debe de ser adaptable lo máximo posible. Específicamente, se deben de poder
integrar en el futuro otras SGBD (Sistema de Gestión de Base de Datos)
distintas a MySQL, y debe de ser independiente del sistema operativo y del
servidor web a utilizar.
• Siempre que haya alguno disponible,
se debe de hacer uso de los estándares abiertos disponibles en el mercado,
teniendo que validar el sistema resultante en el caso de que haya herramientas para
hacerlo. Éste es el caso del código (X) HTML generado, que debe de estar
validado mediante las herramientas que dispone el W3C.
• Al manejar datos sensibles de
personas físicas y jurídicas, la herramienta debe de tener en especial
consideración el cumplimiento de la Ley de Retención de Datos durante su
desarrollo.
• La aplicación debe de ser
multilingüe, debiendo de incorporar un sistema de traducción a varios idiomas
basado en gettext.
• El sistema utilizará una
codificación de caracteres UTF-8.
• Se utilizará un sistema de registro
de todas las transacciones que se hagan en el sistema que garantice el uso
legal de ésta información. Para ello, las transacciones deben de estar almacenadas
en la base de datos y se debe de generar regularmente un fichero de logs, el
cual debe de estar firmado con MD5.
Operaciones del sistema
A continuación se muestran la
secuencia de acciones que debe de seguir cada operación del sistema.
El desarrollo de software ha ocupado
un lugar importante en la Ingeniería, pero al igual que otras disciplinas, aún
presenta fallas. Debido a esto se han planteado técnicas y métodos para
minimizar los problemas identificados en la crisis del software.
Es así como surge la Ingeniería de
Software, presentando distintos modelos de procesos que se ajustan a las necesidades
y proyectos requeridos. La mayoría de ellos involucran en sus fases iníciales
tareas como planeación, levantamiento de información, determinación de las
características que debe cumplir el software, agrupadas en lo que hoy se conoce
como Ingeniería de Requisitos (IR). Esta fase ocupa un lugar importante en el
proceso de desarrollo de software ya que si el personal comprometido no conoce
con claridad los requisitos, corre el riesgo de que los resultados obtenidos no
sean los esperados, presentando así los mismos problemas de hace cincuenta
años: altos costos, baja calidad de software, clientes inconformes e
incumplimiento de plazos, entre otros. Con el ánimo de facilitar las tareas del
desarrollo de software, surgen herramientas informáticas que agilizan la labor
en la IR. Dichas herramientas son denominadas CASE (Ingeniería de software
asistida por computador), y sirven de apoyo para los desarrolladores, desde el
principio hasta el final del proceso.
Para el caso particular de esta
investigación, son de especial interés aquellos instrumentos que se encargan de
actividades como: extraer, analizar, documentar, revisar, negociar y validar
los requisitos del sistema objeto de estudio.
Impacto de la Ingeniería de
Requisitos en el Desarrollo de Proyectos Informáticos
En el ambiente informático es crucial
la época en la cual el hardware era de mayor tamaño, más costoso y más
importante que el software; aunque con el transcurrir del tiempo, éste último
ocupa una mejor posición, dando cabida a la comercialización de los
primeros ordenadores y al aumento en
la demanda de un software un poco más complejo. Se creería que estas son buenas
noticias, pero en realidad, tal avance trae consigo la crisis del software;
expresión que se utilizó por primera vez en la conferencia organizada por la
Comisión de Ciencia de la OTAN en Garmisch, Alemania, en octubre de 1968, y
tiene como objeto agrupar la gran cantidad de problemas que elevan el índice de
fracasos en los proyectos de desarrollo.
