UNIDAD II: INGENIERIA DE REQUISITOS
Definición: Requisito
Una
condición o necesidad de un usuario para resolver un problema o alcanzar un
objetivo.
Una
condición o capacidad que debe estar presente en un sistema o componentes de
sistema para satisfacer un contrato, estándar, especificación u otro documento
formal.
Ingeniería de requerimientos
El proceso de recopilar, analizar y verificar las necesidades del
cliente o usuario para un sistema es llamado ingeniería de requerimientos. La
meta de la ingeniería de requerimientos (IR) es entregar una especificación de
requisitos de software correcta y completa.
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.
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 parte más difícil de construir un sistema es precisamente saber qué
construir. Ninguna otra parte del trabajo conceptual es tan difícil como
establecer los requisitos técnicos detallados, incluyendo todas las interfaces
con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta
tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más
adelante. Entonces, la tarea más importante que el ingeniero de software hace para
el cliente es la extracción iterativa y el refinamiento de los requerimientos
del producto.
Tipos de Requerimientos
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 un Requerimiento
Es importante no perder de vista que un
requerimiento debe ser:
³ Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
³ Posible de probar o
verificar. Si un requerimiento no se puede comprobar, entonces
¿cómo se sabe si se cumplió con él o no?
v 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.
v 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.
v Consistente: Un requerimiento es consistente si no es
contradictorio con otro requerimiento.
v 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.
2.1 TAREAS DE LA
INGENIERÍA DE REQUISITOS
Extracción: Esta fase representa el comienzo de cada ciclo.
Extracción es el nombre comúnmente dado a las actividades involucradas en el
descubrimiento de los requisitos del sistema.
Análisis: Sobre la base de la extracción realizada
previamente, comienza esta fase en la cual se enfoca en descubrir problemas con
los requisitos del sistema identificados hasta el momento.
Especificación: En esta fase se documentan los requisitos
acordados con el cliente, en un nivel apropiado de detalle.
Validación:
La validación es la etapa final de la IR. Su
objetivo es, ratificar los requisitos, es decir, verificar todos los requisitos
que aparecen en el documento especificado para asegurarse que representan una
descripción, por lo menos, aceptable del sistema que se debe implementar. Esto
implica verificar que los requisitos sean consistentes y que estén completos.
2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISTOS
Entrevistas y Cuestionarios
Las entrevistas y cuestionarios se emplean para reunir información
proveniente de personas o de grupos.
Durante la entrevista, el analista conversa con el encuestado; el cuestionario
consiste en una serie de preguntas relacionadas con varios aspectos de un
sistema.
Por lo común, los encuestados son usuarios de los sistemas existentes o
usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o
empleados que proporcionan datos para el sistema propuesto o que serán
afectados por él. El éxito de esta técnica, depende de la habilidad del entrevistador
y de su preparación para la misma.
Sistemas existentes
Esta técnica consiste en analizar distintos sistemas ya desarrollados
que estén relacionados con el sistema a ser construido. Por un lado, podemos
analizar las interfaces de usuario, observando el tipo de
Información que se maneja y cómo es manejada, por otro lado también es
útil analizar las distintas
Salidas que los sistemas producen (listados, consultas, etc.), porque
siempre pueden surgir nuevas ideas sobre la base de estas.
Lluvia de ideas
Este es un modelo que se usa para generar ideas. La intención en su
aplicación es la de generar la máxima cantidad posible de requerimientos para
el sistema. No hay que detenerse en pensar si la idea eso no del todo
utilizable. La intención de este ejercicio es generar, en una primera
instancia, muchas ideas.
Prototipos
Durante la actividad de extracción de requerimientos, puede ocurrir que algunos
requerimientos no estén demasiado claros o que no se esté muy seguro de haber
entendido correctamente los requerimientos
Obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no
eficaz del sistema final.
Entonces,
para validar los requerimientos hallados, se construyen prototipos. Los prototipos son
Simulaciones del posible producto, que luego son utilizados por el
usuario final, permitiéndonos conseguir una importante retroalimentación en
cuanto a si el sistema diseñado con base a los requerimientos recolectados le
permite al usuario realizar su trabajo de manera eficiente y efectiva.
El desarrollo del prototipo comienza con la captura de requerimientos.
Desarrolladores y clientes se
Reúnen y definen los objetivos globales del software, identifican todos
los requerimientos que son conocidos, y señalan áreas en las que será necesaria
la profundización en las definiciones. Luego de esto, tiene lugar un “diseño
rápido”. El diseño rápido se centra en una representación de aquellos aspectos
del software que serán visibles al usuario (por ejemplo, entradas y formatos de
las salidas). El diseño rápido lleva a la construcción de un prototipo.
Casos de Uso
Los casos de uso son una técnica para especificar el comportamiento de
un sistema.
“Un caso de uso es una secuencia de transacciones que son desarrolladas
por un Sistema en respuesta a un evento que inicia un actor sobre el propio
sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad
y el comportamiento de un sistema mediante su interacción con los usuarios y/o
otros sistemas”
Los casos de uso permiten entonces describir la posible secuencia de interacciones
entre el sistema y uno o más actores, en respuesta a un estímulo inicial
proveniente de un actor, es una descripción de un conjunto de escenarios, cada
uno de ellos comenzado con un evento inicial desde un actor hacia el sistema.
2.3 MODELADO DE
REQUISITOS
El modelo de requisitos tiene
como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer
desde la perspectiva del usuario. Este modelo puede funcionar como un contrato
entre el desarrollador y el cliente o usuario del sistema, y por lo tanto
proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto,
es esencial que los clientes puedan comprender este modelo.
El modelo de requisitos es el
primer modelo a desarrollarse, sirviendo de base para la formación de todos los
demás modelos en el desarrollo de software. En general, el cualquier cambio en
la funcionalidad del sistema es más fácil de hacer, y con menores
consecuencias, a este nivel que posteriormente. El modelo de requisitos que
desarrollaremos se
Basa en la metodología Objectory
(Jacobson et al. 1992), basada principalmente en el modelo de casos de
uso.
Actualmente esta metodología es
parte del Proceso Unificado de Rational (RUP). El modelo de casos de uso
y el propio modelo de requisitos son la base para los demás modelos, como se
describió anteriormente en el Capítulo 3 y
se resume aquí:
ü Requisitos: El modelo de casos de uso sirve
para expresar el modelo de requisitos, el cual se desarrolla en
cooperación con otros modelos como se verá más
adelante.
ü Análisis: La funcionalidad especificada
por el modelo de casos de uso se estructura en el modelo de análisis,
que es estable con respecto a cambios, siendo un
modelo lógico independiente del ambiente de implementación.
ü Diseño: La funcionalidad de los casos
de uso ya estructurada por el análisis es realizada por el modelo de
diseño, adaptándose al ambiente de implementación
real y refinándose aún más.
ü Implementación: Los casos de uso son
implementados mediante el código fuente en el modelo de
implementación.
ü Pruebas: Los casos de uso son probados a
través de las pruebas de componentes y pruebas de integración.
ü
Documentación: El modelo de casos de uso debe ser documentado a
lo largo de las diversas actividades, dando lugar a distintos documentos como
los manuales de usuario, manuales de administración, etc.
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.
