2.1 Tareas de la 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.
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.
1.
Obtener requisitos: a través de
entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus
expectativas.
2.
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.
3.
Documentar requisitos: igual que
todas las etapas, los requisitos deben estar debidamente documentados.
4.
Verificar los requisitos: consiste en
comprobar el correcto funcionamiento de un requisito en la aplicación.
5.
Validar los requisitos: comprobar
que los requisitos implementados se corresponden con lo que inicialmente se
pretendía.
La ingeniería de requerimientos y sus principales actividades
Los requerimientos puedes dividirse en requerimientos funcionales y
requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones
que el sistema realiza sobre las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que
de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento
(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.
Características de los requerimientos
Las características de un requerimiento son sus propiedades principales.
Un conjunto de requerimientos en estado de madurez, deben presentar una serie de características tanto
individualmente como en grupo. A continuación se presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en
el sistema a construir, y además su capacidad, características físicas o factor
de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso.
Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un
futuro.
Completo: Un requerimiento está completo si no necesita ampliar detalles en su
redacción, es decir, si se proporciona la información suficiente para su comprensión.
Consistente: Un requerimiento es consistente si no es contradictorio con otro
requerimiento.
No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de manera
que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas.
Dificultades para definir los requerimientos
Los requerimientos no son obvios y vienen de muchas fuentes.
Son difíciles de expresar en palabras (el lenguaje es ambiguo).
Existen muchos tipos de requerimientos y diferentes niveles de detalle.
La cantidad de requerimientos en un proyecto puede ser difícil de
manejar.
Nunca son iguales. Algunos son más difíciles, más riesgosos, más
importantes o más estables que otros.
Los requerimientos están relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.
Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales
específicas.
Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
Son
difíciles de cuantificar, ya que cada conjunto de requerimientos es particular
para cada proyecto.
Los principales beneficios que se obtienen de la Ingeniería de
Requerimientos
Permite gestionar las
necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y
bien definidos.
Mejora la capacidad
de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y
actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.
Disminuye los costos
y retrasos del proyecto: Muchos estudios han
demostrado que reparar errores por un mal desarrollo no descubierto a tiempo,
es sumamente caro; especialmente aquellas decisiones tomadas durante la RE.
Mejora la calidad del
software: La calidad en el software tiene que ver con cumplir
un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).
Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso
entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no
será exitoso.
Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus
requerimientos cuidadosamente y revisarlos dentro del marco del problema, por
lo que se le involucra durante todo el desarrollo del proyecto.
Personal involucrado en la Ingeniería de
Requerimientos
Realmente, son muchas
las personas involucradas en el desarrollo de los requerimientos de un sistema.
Es importante saber que cada una de esas personas tienen diversos intereses y
juegan roles específicos dentro de la planificación del proyecto; el conocimiento de cada papel desempeñado, asegura que se involucren a las personas
correctas en las diferentes fases del ciclo de vida, y en las diferentes
actividades de la IR.
No conocer estos intereses puede ocasionar una comunicación poco
efectiva entre clientes y desarrolladores, que a la vez traería impactos
negativos tanto en tiempo como en presupuesto. Los roles más importantes pueden clasificarse como sigue:
Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están
relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema;
están familiarizados con los procesos específicos que debe realizar el
software, dentro de los parámetros de su ambiente laboral. Serán quienes utilicen las interfaces y los manuales de usuario.
Usuario Líder: Son los individuos que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el software desarrollado. Ellos
proporcionan al equipo técnico los detalles y requerimientos de las interfaces
del sistema.
Personal de
Mantenimiento: Para proyectos que requieran un mantenimiento
eventual, estas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo
consiste en revisar y mejorar los procesos del producto ya finalizado.
Analistas y
programadores: Son los responsables del desarrollo del producto
en sí; ellos interactúan directamente con el cliente.
Personal de pruebas: Se encargan de elaborar y ejecutar el plan de pruebas para asegurar que las condiciones presentadas por el sistema
son las adecuadas. Son quienes van a validar si los requerimientos satisfacen
las necesidades del cliente.
2.2 Técnicas de la Ingeniería de Software
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 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.
1. A los
directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho
trabajo por hacer para completar el diseño final.
2. Los
diseñadores tienden a reutilizar el código de los prototipos por temor a
“perder el tiempo” al comenzar otra vez.
3. Los
prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin
embargo, no proporcionan explícitamente cuáles son los requisitos.
4. Los
diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de
la interfaz de usuario y demasiado poco en producir un sistema que sirva el
proceso del negocio.
Los
prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades
sintetizadas. Los diagramas, en los casos donde se espera que el software final
tenga diseño gráfico, se realizan en una variedad de documentos de diseño
gráficos y a menudo elimina todo el color del diseño del software (es decir
utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la
apariencia final de la aplicación.
Especificación
de requisitos del software
Una
especificación de requisitos del software es una descripción completa del
comportamiento del sistema a desarrollar. Incluye un conjunto de casos de uso
que describen todas las interacciones que se prevén que los usuarios tendrán
con el software. También contiene requisitos no funcionales (o suplementarios).
Los requisitos no funcionales son los requisitos que imponen restricciones al
diseño o funcionamiento del sistema (tal como requisitos de funcionamiento,
estándares de calidad, o requisitos del diseño).
Las
estrategias recomendadas para la especificación de los requisitos del software
están descritas por IEEE 830-1998. Este estándar describe las estructuras
posibles, contenido deseable, y calidades de una especificación de requisitos
del software.
Los
requisitos se dividen en tres:
1. Funcionales: son los que el usuario
necesita que efectúe el software. Ej: el sistema debe emitir un comprobante al
asentar la entrega de mercadería.
2. No funcionales: son los
"recursos" para que trabaje el sistema de información (redes,
tecnología). Ej: el soporte de almacenamiento a usar debe ser MySQL.
3. Empresariales u Organizacionales: son el
marco contextual en el cual se implantará el sistema para conseguir un objetivo
macro. Ej: abaratar costos de expedición.
Identificación
de las personas involucradas
Debido a que los cambios que
introduce un sistema nuevo tienden a afectar a más de un tipo de usuario, los
analistas de requisitos han de tomar en consideración a todos los implicados
para que se obtengan y depuren sus requisitos de la forma más fidedigna
posible. Entre las personas implicadas hay que considerar:
1. Organizaciones
que integran la organización del analista que está diseñando el sistema
2. Organizaciones
o sistemas de respaldo
3. Dirección
4. Usuarios
Problemas
relacionados con las personas involucradas
Las
vías que pueden dificultar la determinación de los requisitos son:
1. Los usuarios
no tienen claro lo que desean
2. Los usuarios
no se involucran en la elaboración de requisitos escritos
3. Los usuarios
insisten en nuevos requisitos después de que el coste y la programación se
hayan fijado.
4. La
comunicación con los usuarios es lenta
5. Los usuarios
no participan en revisiones o son incapaces de hacerlo.
6. Los usuarios
no comprenden los problemas técnicos
7. Los usuarios
no entienden el proceso del desarrollo
Esto
puede conducir a la situación donde las exigencias del consumidor cambian,
incluso cuando el desarrollo del producto ya está en marcha.
Relacionados
con los analistas
La
correcta redacción de las Especificaciones de requisitos del Software es
imprescindible para el correcto desarrollo del proyecto. Por ello, en su
redacción hay que evitar:
1. Uso de
terminología ambigua en la redacción de los documentos de requisitos
2. Sobreespecificación
de los requisitos
3. Escritura
poco legible, voz pasiva, abuso de negaciones
4. Uso de
verbos en condicional, expresiones subjetivas
5. Ausencia de
términos y verbos del dominio de la aplicación
Relacionados
con los desarrolladores
Los problemas posibles causados
por los desarrolladores durante análisis de requisitos son:
1.
El
personal técnico y los usuarios finales pueden tener diversos vocabularios y
pueden llegar a creer incorrectamente que están de acuerdo, no dándose cuenta
del desacuerdo hasta que se provee el producto final.
2.
Los
desarrolladores pueden intentar encajar el sistema en un modelo existente, en
vez de desarrollar un sistema adaptado a las necesidades del cliente.
3.
El
análisis de requisitos se puede realizar a menudo por los ingenieros o
programadores, en vez de personal con las habilidades de relación con la gente
y el conocimiento apropiados para entender las necesidades de un cliente
correctamente.
2.3 Modelado de requisitos
Se empleará el uso de los diagramas de casos de uso
que especifica los modos de uso (o requisitos funcionales) que va a tener el
sistema, del diagrama de paquetes, que indica cómo 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 transiciones.
Tiene como objetivo delimitar el sistema y capturar
la funcionalidad que ofrecerá desde la perspectiva del usuario. El modelo de
requisitos es el primer modelo en desarrollarse y es la base para formar todos
los demás modelos en el desarrollo de software.
El modelo de requisitos consiste en tres modelos
principales:
Modelo
de comportamiento: basado
directamente en el modelo de casos de uso, especifica la funcionalidad que
ofrece el sistema desde el punto de vista del usuario. Utiliza dos conceptos
claves: Actores y casos de uso.
Modelo
de presentación o modelo de interfaces: especifican cómo interactúan el sistema con actores externos al ejecutar
los casos de uso, especifican como se verán visualmente las interfaces gráficas
y que funcionalidad ofrecerá cada una de ellas.
Modelo
de información o dominio del problema: especifica los aspectos estructurales del sistema, este modelo
conceptualiza el sistema según los objetos que representan las entidades
básicas de la aplicación.
2.4 Herramientas CASE para la ingeniería de requisitos
A medida que pasa el tiempo se logra entender que
el empleo del software es una buena opción para agilizar y sistematizar las
tareas en el desarrollo de procesos. El desarrollo de software no es la
excepción; en este caso dichas herramientas se han denominado CASE (Ingeniería
De Software Asistida Por Computador). Estas incluyen un conjunto de programas que
facilitan la optimización de un producto ofreciendo apoyo permanente a los
analistas, ingenieros de software y desarrolladores. CASE es la aplicación de
métodos y técnicas que dan utilidades a los programas, por medio de otros,
procedimientos y su respectiva documentación.
En este post se hace referencia a 3 herramientas
que ayudan a la gestión de requisitos; es decir al proceso de identificación,
asignación y seguimiento de los mismos, incluyendo interfaz, verificación,
modificación y control de cada requisito, durante el ciclo de vida del
proyecto. Los cambios/actualizaciones de requisitos deben ser gestionados para
asegurar que se mantenga la calidad del producto.
Hasta hace poco tiempo las herramientas para la
gestión de requisitos de software se limitaban a editores de texto, los cuales
hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con
múltiples opciones, como las que se mencionan a continuación:
IRQA
Herramienta CASE de Ingeniería de Requisitos,
diseñada para soportar las actividades realizadas en el proceso de
especificación de sistemas. Ésta facilita y formaliza la comunicación entre el
cliente, el proveedor y los distintos miembros del equipo de desarrollo.
Facilita la captura, organización y análisis de las condiciones, así como la
especificación de la solución mediante el apoyo metodológico adaptable a cada
cliente.
CONTROLA
Herramienta de apoyo al proceso de ingeniería de
software en pequeñas empresas. Se creó gracias a la expansión que tuvo el
mercado y a la generación de grandes y pequeñas empresas, las cuales requieren
un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes
tales como: Administración de requisitos, administración de casos de uso,
administración de casos de prueba y error, planeamiento de liberaciones,
administración de implementaciones, control de dependencia entre
Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.
OSRMT (Open Source Requirements Management Tool)
Herramienta libre para la gestión de requisitos,
cuyas principales características son: trabaja en arquitectura
cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para
manejar la trazabilidad y lo introduce para el control de cambios; así mismo,
genera la documentación de los requisitos tratados.
No hay comentarios:
Publicar un comentario