UNIDAD 2 INGENIERÍA DE REQUISITOS
2.1 TAREA DE LA INGENIERÍA
DE REQUISITOS
La ingeniería de requisitos ayuda a los ingenieros de software a entender
mejor el problema en cuya solución trabajaran. Incluye el conjunto de tareas
que conducen comprender cuál será el impacto del software sobre el negocio, que
es lo que el cliente quiere y como interactuaran los usuarios finales con el
software.
Inicio
Al inicio del
proyecto los ingenieros de software hacen una serie de preguntas libres de contexto. El objetivo es establecer una
comprensión básica del problema, las personas que quieren una solución que se
desea, y la efectividad de la comunicación preliminar entre el cliente y el
desarrollador.
Obtención
En verdad parece muy simple preguntarle al cliente, a los usuarios y otros interesados
cuáles son los objetivos para el sistema o producto, que es lo que se debe
lograr, de que forma el producto satisface las necesidades del negocio y por
Ultimo como utilizara el sistema o producto día a día.
Elaboración
La elaboración se conduce mediante la creación y el refinamiento de
escenarios del usuario que describen la forma en que el usuario final (y otros
actores) interactúan con el sistema. Cada escenario del usuario se analiza para
obtener clases de análisis: entidades del dominio del negocio visibles
para el usuario final. Se definen los atributos de cada clase de análisis y se
identifican los servicios que requiere cada clase. Se identifican las
relaciones y la colaboración entre las clases y se produce una variedad de
diagramas de ULM complementarios.
Negociación
El ingeniero de requisitos debe conciliar estos conflictos por medio de un
proceso de negociación. Se pide a los clientes, usuarios y otros interesados
que ordenen sus requisitos y después discutan los conflictos relacionados con
la prioridad. Se identifican y analizan los riesgos asociados con cada
requisito.
Especificación
En el contexto de los sistemas basados en computadora (y en software), el termino
especificación puede ser un documento escrito, un conjunto de modelos gráficos,
un modelo matemático formal, una colección de escenarios de uso, un prototipo o
cualquier combinación de estos
Validación
La validación de requisitos examina la especificación para asegurar que
todos los requisitos de software se han establecido de manera precisa; que se han
detectado las inconsistencias, omisiones y errores y que estos han sido corregidos,
y que los productos de trabajo cumplen con los estándares establecidos para el
proceso, proyecto y producto.
Gestión de Requisitos
La gestión de requisitos comienza con la identificación. Cada requerimiento
se asigna a un solo identificador. Una vez identificados los requisitos se
desarrollan las tablas de rastreabilidad, la cual relaciona los requisitos con
uno o más aspectos del sistema o de su ambiente.
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 MODELOS DE REQUISITOS
El propósito del Modelo de Requisitos es capturar precisa y fielmente
las principales características del sistema software que se desea construir.
El propósito del Modelo de Requisitos es capturar precisa y fielmente las
principales características del sistema software que se desea construir. Este
modelo permite representar los requisitos del sistema de manera que cualquiera
de sus potenciales usuarios pueda revisarlo y comprenderlo, sin que para esto
necesite un entrenamiento especial. No obstante, la notación utilizada en tal
representación es lo suficientemente precisa para que pueda servir de base a la
fase de modelado conceptual. En este modelo los conceptos de actor
y caso de uso desempeñan roles de mucha importancia. Ambos conceptos
fundamentan el Modelo de Casos de Uso propuesto por Jacobson en su Método OOSE
. Es reconocida la efectividad de este modelo para manejar la complejidad de
los requisitos. Su simplicidad, derivada del uso del lenguaje natural para
describir la funcionalidad observada en el espacio del problema, posibilita la
participación activa de usuarios finales y clientes en el modelado de los requisitos.
Sin embargo, el Modelo de Casos de Uso tiene dos desventajas importantes que
dificultan frecuentemente la puesta en práctica de las técnicas de Ingeniería
de Requisitos: la dificultad de determinar el nivel de abstracción correcto
para especificar los casos de uso y la inexistencia de un proceso para analizar
esta especificación y traducirla a un modelo conceptual .
Modelo de Casos de Uso
El modelado de requisitos utiliza los elementos del Modelo de Casos de Uso
propuesto por Jacobson, bajo el esquema conceptual y notacional definido en
UML]. De esta forma, la especificación de actores y casos de uso así como el
establecimiento de las relaciones entre éstos, constituye el objetivo
fundamental del Modelo de Casos de Uso. El principal insumo requerido para el
desarrollo de este modelo son las funciones elementales identificadas como
nodos hoja en el Árbol de Refinamiento Funcional del sistema. Cada una de estas
funciones elementales es considerada en el modelo como un caso de uso . Luego
de identificar sus actores, la especificación de los casos de uso describe en
lenguaje natural la secuencia completa y ordenada de las acciones que el
sistema debe ejecutar, incluyendo todas sus posibles variantes, al interactuar
con los actores para la satisfacción de los requisitos.
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.
