unidad 2

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.

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.

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.