Ingeniería de Requisitos de Software

La ingeniería de requisitos de software es un proceso de descubrimiento, refinamiento, modelado y especificación.

Análisis de Requisitos de Software

El análisis de requisitos de software se centra en 5 áreas de esfuerzo:

1. Reconocimiento del problema
2. Evaluación y síntesis
3. Modelado
4. Especificación
5. Revisión

El analista estudia la especificación del sistema y el plan de proyecto del software. La evaluación del problema y la síntesis de la solución es la siguiente área de esfuerzo principal en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software.

Inicio del Proceso

La técnica de obtención de requisitos más usada es llevar a cabo una reunión o entrevista preliminar. Se sugiere que el analista empiece preguntando cuestiones de contexto libre.

Técnicas para Facilitar las Especificaciones de una Aplicación (TFEA)

Con estos problemas en mente, algunos investigadores independientes han desarrollado un enfoque orientado al equipo para la reunión de requisitos que se aplica durante las primeras fases del análisis y especificación. Denominadas Técnicas para Facilitar las Especificaciones de la Aplicación (TFEA), este enfoque es partidario de la creación de un equipo conjunto de clientes y desarrolladores para identificar el problema, proponer soluciones, negociar enfoques y especificar requisitos de solución.

Directrices Básicas de TFEA

1. La reunión se celebra en un lugar neutral y asisten tanto los clientes como los desarrolladores.
2. Se establecen normas de preparación y de participación.
3. Se sugiere una agenda para cubrir todos los puntos importantes.
4. Un coordinador que controle la reunión.
5. Se usa un mecanismo de definición.
6. El objetivo es identificar el problema, proponer elementos de solución, negociar enfoques y especificar los requisitos de la solución.

Diferencia entre una TFEA y una reunión ordinaria: En las TFEA, los asistentes hacen una lista de objetos que forman parte del entorno del sistema, otros para producir el sistema y otros para desarrollar las funciones. Además, hacen otra lista de servicios para manipular dichos objetos y, por último, una lista de restricciones y criterios de rendimiento.

Despliegue de la Función Calidad

El despliegue de la función calidad es una técnica de gestión de calidad que traduce las necesidades del cliente en requisitos técnicos del software, define los requisitos orientados a maximizar la satisfacción del cliente.

Tipos de Requisitos

• Requisitos Normales: Se declaran objetivos y metas para un producto o sistema durante las reuniones con el cliente.
• Requisitos Esperados: Estos requisitos son implícitos al producto o sistema y pueden ser tan fundamentales que el cliente no los declara explícitamente.
• Requisitos Innovadores: Estas características van más allá de las expectativas del cliente y suelen ser muy satisfactorias.

En las reuniones con el cliente, el despliegue de función se emplea para determinar el valor de cada función requerida para el sistema. El despliegue de información identifica tanto los objetos de datos como los acontecimientos que el sistema debe producir y consumir. El despliegue de tareas examina el comportamiento del sistema dentro del contexto de su entorno. El análisis de valor es llevado a cabo para determinar la prioridad relativa de requisitos durante cada uno de los 3 despliegues.

Casos de Uso

Un caso de uso es un escenario que describe cómo el software va a ser usado en una determinada situación.

Un actor es algo que se comunica con el sistema y que es externo al sistema en sí mismo.

Un usuario puede tener varios papeles diferentes cuando se utiliza un sistema, es una clase de entidades externas que lleva a cabo un papel.

Los casos de uso están definidos desde el punto de vista de un actor. Un actor es un papel que las personas juegan cuando interaccionan con el software.

Principios Operativos de los Métodos de Análisis

1. Debe representarse y entenderse el dominio de información del problema.
2. Deben definirse las funciones que debe realizar el software.
3. Debe representarse el comportamiento del software.
4. Deben dividirse los modelos que representan información, función y comportamiento.
5. El proceso de análisis debe ir desde la información hasta el detalle de implementación.

Davis: Conjunto de principios directrices para la ingeniería de requisitos: Entender el problema antes de empezar a crear el modelo de análisis; desarrollar prototipos que permitan al usuario entender cómo será la interacción hombre-máquina; registrar el origen y la razón de cada requisito; usar múltiples planteamientos de requisitos; dar prioridad a los requisitos; trabajar para eliminar la ambigüedad.

Todas las aplicaciones de software pueden denominarse colectivamente procesamiento de datos.

Dominio de Información

El dominio de información de un problema agrupa elementos de datos u objetos que contienen números, texto, imágenes, audio o cualquier combinación de ellos.

Un suceso representa algún aspecto de control del sistema y no es más que un dato binario.

• Contenido de la información: Representa los objetos individuales de datos y de control que componen la información para hacer el software.
• Flujo de información: Representa cómo cambian los datos y el control a medida que se mueven dentro de un sistema.
• Estructura de información: Representa la organización interna de los elementos de datos o de control.

Modelado

Los modelos se crean para entender mejor la entidad que se va a construir.

• Modelos Funcionales: El software transforma la información y para hacerlo usa 3 funciones genéricas: entrada, procesamiento y salida.
• Modelos de Comportamiento: El software responde a los acontecimientos del mundo exterior, esto es la base de este modelo.

Papele de estos modelos: Ayudan al analista a entender la información, función y comportamiento del sistema; se convierte en el punto de mira para la revisión y se convierten en el fundamento para el diseño.

Partición y Descomposición

Partición: Se parten los dominios de la información, funcional y de comportamiento. La partición descompone un problema en sus partes constitutivas.

La descomposición es un proceso que resulta de la elaboración de datos, funciones o comportamientos, puede ser realizada horizontal o verticalmente.

• Una visión esencial: Presenta las funciones a conseguir y la información a procesar sin tener en cuenta los detalles de la implementación.
• Una visión de implementación: Introduce la manifestación en el mundo real de las funciones de procesamiento y las estructuras de la información.

Prototipos

El paradigma de creación de prototipos puede ser cerrado o abierto.

• El enfoque cerrado se denomina prototipo desechable: Sirve únicamente como una basta demostración de los requisitos.
• Un enfoque abierto se denomina prototipo evolutivo: Emplea el prototipo como primera parte de una actividad de análisis a la que seguirá el diseño y la construcción.

Métodos y Herramientas para el Desarrollo de Prototipos

• Técnicas de Cuarta Generación: Amplia gama de lenguaje de consulta e informes de bases de datos, generadores de programas y aplicaciones y otros lenguajes de alto nivel.
• Componentes de Software Reutilizables: Prototipos rápidos es ensamblar más que construir, o sea, hacer el prototipo mediante componentes ya existentes.
• Especificaciones Formales y Entornos para Prototipos: Permiten al analista crear interactivamente una especificación basada en lenguaje de un sistema con herramientas automáticas.

Principios de la Especificación

1. Separar la funcionalidad.
2. Desarrollar un modelo de comportamiento deseado.
3. Establecer el contexto en que opera el software especificado.
4. Definir el entorno en que va a operar el sistema.
5. Crear un modelo intuitivo.
6. Reconocer que la especificación debe ser tolerante a un posible crecimiento si no es completa.
7. Establecer el contenido y la estructura de una especificación de manera que acepte cambios.

Directrices Básicas para Representar los Requisitos

El formato de la representación y el contenido deberían estar relacionados con el problema; la información contenida dentro de la especificación debería estar escalonada; los diagramas y otras formas de notación deberían restringirse en número y ser consistentes en su empleo; las representaciones deben permitir revisiones.

La especificación de los requisitos del software se produce en la culminación de la tarea de análisis, una indicación de los requisitos de rendimiento y restricciones del diseño, criterios de validación apropiados y otros datos.

La revisión de la especificación de requisitos de software es llevada a cabo tanto por el desarrollador del software como por el cliente, forma el fundamento para el diseño y las subsiguientes actividades de la ingeniería de software, se lleva a cabo a nivel macroscópico.