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:
◦Identifica
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.
*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.
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.
*Incluye:
Herramientas para recolección de datos Y Herramientas para diagramación.
Herramientas para el diccionario.
