Negociación de Requisitos, Validación de Requisitos y Resumen

Negociación de Requisitos 

En un contexto de la ingeniería de requisitos, las tareas de inicio, obtención y elaboración determinan los requisitos con el suficiente detalle como para emprender los pasos subsecuentes de la ingeniería del software. Desgraciadamente, esto sucede muy rara vez. En realidad, el cliente y el desarrollador entran en un proceso de negociación, en el cual se le debe de pedir al cliente un balance de la funcionalidad el rendimiento y otras características del sistema o producto frente al costo y el tiempo de colocación en el mercado. El objetivo de esta negociación es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones del mundo real (por ejemplo, tiempo, gente, presupuesto) a las que está sometido el equipo de software.

Las mejores negociaciones son aquellas que buscan un resultado del tipo “ganar-ganar” Esto es, el cliente ganar obtener el sistema o producto que satisface la mayoría de sus necesidades, y el equipo de software gana al trabajo con presupuestos y límites de tiempo realistas y alcanzables.

Bohen define un conjunto de actividades de negociación en el inicio de cada iteración del proceso del software. En el lugar de la actividad sencilla de comunicación con el cliente, se definen las siguientes actividades:

1.- identificación de los interesados clave en el sistema de subsistema.
2.- Determinación de las “Condiciones ganadoras” de los interesados.
3.- Negociación de las condiciones ganadoras de los interesados para reconciliarlas en conjunto de condiciones del tipo ganar-ganar para todos los involucrados (incluido el equipo de software).

La conclusión exitosa de estos pasos iniciales asegura un resultado del tipo ganar-ganar, el cual se convierte en el criterio clave para continuar con las actividades subsecuentes de la ingeniería de software.

Validación de Requisitos

Al crear cada elemento del modelo de análisis, a este se examina para conocer su consistencia, sus omisiones y ambigüedades, A los requisitos que representa el modelo del cliente les da jerarquía y se aseguran en paquetes de requisitos que se implementan como incrementos de software y se le entregan. Una revisión del modelo de análisis se enfoca en las siguientes preguntas:

¿Cada requisito es consistente con el objetivo general del sistema/Producto?
¿Todos los requisitos han sido específicos con el grado apropiado de abstracción? Esto es, ¿Algunos requisitos proporcionan un grado de detalle técnico que sea inapropiado en esta etapa?
¿Cada requisito tiene una atribución? Esto es, ¿Existe una fuente (por lo general, especifica, individual) determinada para cada requisito?
¿Algunos requisitos entran en conflicto con otros?
¿Cada requisito se puede probar una vez que este haya sido implementado?
¿El modelo de requisitos refleja de manera apropiada la información, la función y el comportamiento del sistema que será construido?
¿El modelo de requisitos se ha sometido a “Participación” para que exponga en forma progresiva información más detallada acerca del sistema?

Estas y otras preguntas deben realizarse y contestarse para asegurar que el modelo de requisitos es un reflejo exacto de las necesidades del cliente y que proporciona una base sólida para el diseño.

Resumen

Antes de que el diseño y la construcción de un sistema basado en computadora puedan comenzar, es necesario entender los requisitos, Esto se logra realizando una seria de tareas de ingeniería de requisitos, la cual se lleva a cabo durante las actividades de comunicación con el cliente y modelado que han sido definidas para el proceso genérico del software. Los miembros del equipo de software realizan siete funciones distintas dentro de la ingeniería de requisitos: inicio, obtención, elaboración, negociación, especificación, validación y gestión.

Al inicio del proyecto el desarrollador y el cliente (Así como otros interesados) establecen los requisitos básicos del problema, definen las restricciones predominantes del proyecto y especifican las características y funciones más importantes que deben estar presentes en el sistema para que este alcance sus objetivos. Esta información es expandida y refinada durante la obtención, una actividad para la recopilación de requisitos que emplea reuniones que encabeza un moderador facilitadas, que QFG y el desarrollo de escenarios de uso.

La elaboración posteríos expande los requisitos hacia un modelo de análisis; es decir, una colección de elementos del modelo basados en escenarios, en actividades y en clases, de comportamiento y orientados al flujo. En la creación de estos elementos se puede utilizar una variedad de notificaciones de modelado. El modelo puede referirse a patrones de análisis, características del dominio del problema que son recurrentes a traces de diferentes aplicaciones.

Cuando se identifican los requisitos y se crea el modelo de análisis, el equipo de software el cliente y otros interesados en el proyecto negocia la prioridad, disponibilidad y costo relativo de cada requisito. El objetivo de esta negociación es desarrollar un plan de proyecto realista. Además, casa de requisito y el modelo de análisis como un todo se validan contrastándolos con las necesidades del cliente para asegurar que se construirá el sistema correcto.

Construcción del modelo de análisis

El objetivo del modelo de análisis es describir los dominios requeridos de información, funcionamiento y comportamiento para un sistema basado en computadoras.

El modelo cambia en forma dinámica conforme los ingenieros de software aprenden más acerca del sistema que se va a construir y los interesados entienden mejor lo necesitan. Por esta razón el modelo de análisis es una representación de los requisitos en un momento determinado , por lo que se espera que este cambie.

Conforme el modelo de análisis evoluciona, ciertos elementos se volverán relativamente estables, por lo que lo que proporcionaran una base sólida para las tareas de diseño que siguen, sin embargo, otros elementos del modelo pueden ser más volátiles, lo que indicara que el cliente aun no entiende por completo los requisitos para el sistema.

El modelo de análisis y los métodos utilizados para construirlo se describen con detalle en el capítulo 8. En las secciones siguientes se presenta una breve visión general.

Elementos del modelo de análisis

Existen muchas maneras de buscar los requisitos para un sistema basado en computadora. Algunas personas involucradas con el software dicen que lo mejor es seleccionar un modo de representación (por ejemplo, el caso de uso) y aplicarlo sin tomar en cuenta todos los modos restantes. Otros profesionales creen que resulta valioso utilizar varios modos de representación para mostrar el modelo de análisis. Las diferentes formas de representación obligan al equipo de software a considerar los requisitos desde distintos puntos de vista, un enfoque que tiene mayores probabilidades de descubrir omisiones, inconsistencias y ambigüedades.

Los elementos específicos del modelo de análisis los determina el método de modelado que se utilice. Sin embargo, existe un conjunto de elementos genéricos común a la mayoría de los modelos de análisis:

Elementos basados en escenarios. El sistema se describe, desde el punto de vista del usuario, por medio de un enfoque basado en escenarios. Por ejemplo, los casos de usos básicos y sus correspondientes diagramas de caso de uso evolucionan para convertirse en casos de uso más elaborados basados en plantillas.

Los elementos del modelo de análisis basados en escenarios con frecuencia Son los primeros que se desarrollan durante la elaboración del modelo. Por tal motivo sirven como una entrada para la creación de otros elementos de modelado.

Un enfoque algo diferente dentro del modelado basado en escenarios muestra las actividades o funciones que han sido definidas como parte de la tarea de obtención de requisitos. Estas funciones existen dentro de un contexto de procesamiento. Esto es, la secuencia de actividades (también se pueden utilizar los términos funciones u operaciones) que describe el procesamiento dentro de un contexto limitado se define como parte del modelo de análisis. Como la mayoría de los elementos del modelo de análisis (y otros modelos de la ingeniería de software), las actividades (funciones) se pueden representar en muchos grados diferentes de abstracciones. Los modelos en esta categoría pueden definirse de manera iterativa. Cada iteración proporciona detales adicionales del procesamiento.  Como un ejemplo. Se presenta un diagrama de actividad UML para la obtención de requisitos. Se muestran tres niveles de elaboración.

El diagrama de actividad es bastante parecido al diagrama de flujo: un diagrama grafico para representar las secuencias y lógica del flujo de control.

Elementos basados en clases. Cada escenario de uso implica un conjunto de “objetos” que se manipulan mientras un actor interactúa con el sistema. Estos objetos se clasifican en clases: una colección de clases con atributos similares y comportamientos en común. Por ejemplo, se puede usar un diagrama de clase para mostrar una clase de Sensor para la función de seguridad de Hogar Seguro. Obsérvese que el diagrama lista los atributos de los sensores (por ejemplo, nombre/id, tipo) y las operaciones [ por ejemplo, identificar (), habilitar ()] que pueden aplicarse para modificar dichos atributos. Además de los diagramas de clase, otros elementos del modelado de análisis muestran la forma en que las clases colaboran con un uno y otro y las relaciones e interacciones entre las clases. Lo anterior se examina con mayor detalle en el capítulo 8.

Elementos de comportamiento. El comportamiento de un sistema basado en computadora puede tener un profundo efecto sobre el diseño que se elija, así como en el enfoque de implementación que se aplique. Por lo tanto, el modelo de análisis debe proporcionar elementos de modelado que muestren el comportamiento.

El diagrama de estado es un método para representar el comportamiento de un sistema al mostrar sus estados y los eventos que ocasionan que dicho sistema cambie de estado. Un estado es cualquier forma de comportamiento observable. Además, el diagrama de estado indica las acciones (por ejemplo, la activación del proceso) que se toman como consecuencia de un evento particular. Para ilustrar un diagrama de estado, considérese el estado de la lectura de comandos de una fotocopiadora de oficina. En la figura se representa el diagrama de estado correspondiente en UML. Un rectángulo redondeado representa un estado. El rectángulo se divide en tres áreas: 1) el nombre del estado (por ejemplo, Lectura de comandos) 2) las variables de estado que indican la manera en que el estado se manifiesta a sí mismo en el mundo exterior. y 3) las actividades de estado que indican la forma en que se ingresa al estado (entrada/) y las acciones (do:) invocadas mientras se permanece en el mismo.

Elementos orientados al flujo. Cuando la información fluye a través de un sistema basado en computadora, esta se transforma. El sistema acepta la entrada en una variedad de formas, aplica funciones para transformarla y produce una salida también en formas diferentes. La entrada puede ser una señal de centro que transmite un transductor, una serie de números de teclea un operador humano, un paquete de información transmitido a través de liga de red, o un voluminoso archivo de datos obtenido de un almacenamiento secundario. La transformación puede incluir una sola comparación lógica, un algoritmo numérico complejo o un enfoque de interferencia de reglas pertenecientes a un sistema experto. La salida puede encender una sola luz de Led o producir un reporte de 200 páginas. En efecto, es posible crear un modelo de flujo para cualquier sistema basado en computadora, sin importar su tamaño o complejidad. En el capítulo 8 se presenta una exposición más detallada del modelado flujo.

Patrones de análisis

Cualquiera que lleve a cabo ingeniería de requisitos en más de unos cuantos proyectos de software comienza a darse cuenta que ciertas cosas suceden de manera recurrente en todos los proyectos dentro de un dominio de aplicación especifico. Esto puede denominarse patrones de análisis y representan algo (por ejemplo, una clase una función o un comportamiento) dentro del dominio de aplicación que puede reutilizarse al modelar muchas aplicaciones.

Geyer-Shultz y Hahsler sugieren dos beneficios que pueden asociarse con el uso de patrones de análisis: 

Primero, los patrones de análisis aceleran el desarrollo de modelos de análisis abstractos que capturan los requisitos principales del problema concreto al proporcionar modelos reutilizables del análisis, los cuales incluyen ejemplos. Así como una descripción de las ventajas limitaciones. Segundo, los patrones de análisis facilitan la transformación del modelo de análisis en un modelo de diseño al sugerir patrones de diseño y soluciones confiables para problemas comunes.

Los patrones de análisis se integran al modelo respectivo mediante una referencia al nombre del patrón. Estos también se encuentran almacenados en un depósito para que lo ingenieros de requisitos puedan utilizar los servicios de búsqueda y así encontrarlos y reutilizarlos.

La información acerca de un patrón de análisis se presenta en una plantilla estándar que tiene la siguiente forma

• Nombre del patrón: un descriptor que captura la esencia del patrón. El descriptor se utiliza dentro del modelo de análisis cuando se hace alguna referencia al patrón.
• Intención: describe aquello que el patrón pretende lograr o representar o el problema que ataca dentro del contacto de un dominio de aplicación.
• Motivación: un escenario que ilustra la forma en que el patrón se puede utilizar para atacar el problema.
• Fuerzas y contexto: una descripción de los aspectos externos (fuerzas externas) capaces de afectar la manera en que se utiliza el patrón, así como de los asuntos externos que serán resueltos cuando se aplique el patrón. Los aspectos externos pueden incluir cuestiones relacionadas con los negocios, restricciones técnicas externas y asuntos relacionados con las personas.
• Solución: una descripción de la forma en que se aplica el patrón para resolver el problema, poniendo especial atención en los aspectos estructurales y de comportamiento.
• Consecuencias: se enfoca en lo que sucede cuando se aplica el patrón y en los cambios que se producen durante su aplicación.
• Diseño: Examina la manera en que el patrón de análisis se puede lograr por medio de patrones de diseño conocidos.
• Usos conocidos: ejemplos de usos en sistemas reales.
• Patrones relacionados: uno o más patrones de análisis que se están relacionados con el patrón en cuestión. Porque el patrón el análisis 1) por lo general se utiliza junto con el patrón en estudio, 2) es similar en el sentido estructural a dicho patrón, 3) es una variación del mismo.

Desarrollo de Casos de Uso

En un libro que analiza la manera de escribir casos de uso eficaces, Alistair Cockburn [COC01] menciona que “un caso de uso captura un contrato…[que] describe el comportamiento del sistema en diferentes condiciones mientras éste responde a la petición de uno de sus usuarios”. En esencia, un caso de uso cuenta una historia estilizada de la manera en que un usuario final (el cual desempeña uno de varios papeles posibles) interactúa con el sistema en un conjunto especifico de circunstancias. La historia puede ser un texto narrativo, un esquema de tareas o interacciones, una descripción basada en una plantilla o una representación por medio de diagramas. Sin importar su forma, un caso de uso muestra el software o sistema desde el punto de vista del usuario final.

El primer paso al escribir un caso de uso consiste en definir el conjunto de “actores” que estarán involucrados en la historia. Los actores son las diferentes personas (o dispositivos) que utiliza el sistema o producto dentro del contexto de la función y el comportamiento que se describirá. Los actores representan los papeles que juegan las personas (o dispositivos) conforme el sistema opera. Definido de una manera más formal, un actor es algún elemento que se comunica con el sistema o producto y que es externo al sistema en sí mismo. Cada actor tiene una o más metas cuando utiliza el sistema.

Es importante señalar que un actor y un usuario final no son necesariamente lo mismo. Un usuario típico puede desempeñar varios papeles al usar un sistema, mientras que un actor representa una clase de entidad externa (con frecuencia, pero no siempre, una persona) que desempeña sólo un papel en el contexto del caso de uso. Como un ejemplo, considérese al operador de una máquina (un usuario) que interactúa con la computadora de control para una célula de manufactura que contiene varios robots y máquinas de control numérico. Después de la revisión cuidadosa de los requisitos, el software para la computadora de control requiere cuatro diferentes modos (actores) para su interacción: modo de programación, modo de prueba, modo de monitoreo y modo de resolución de problemas. Por lo tanto, se pueden definir cuatro actores: el programador, el que realiza las pruebas, el que monitorea y el que resuelve el problema. En algunos casos el operador de la máquina puede desempeñar todos estos papeles. En otras situaciones, son personas diferentes las que pueden desempeñar el papel de cada actor.

Como la obtención de requisitos es una actividad evolutiva, no todos los actores se identifican durante la primera iteración. Durante ésta es posible identificar los actores primarios [JAC92], mientras que los actores secundarios se identifican conforme se aprende más acerca del sistema. Los actores primarios interactúan para lograr la función requerida del sistema y obtienen el beneficio que se espera de éste. Ellos trabajan de manera directa y frecuente con el software. Los actores secundarios dan soporte al sistema de manera que los actores primarios puedan hacer su trabajo.

Ya identificados los actores pueden desarrollarse los casos de uso, Jacobson [JAC92] sugiere varias preguntas que se deberían contestar mediante un caso de uso.

• ·         ¿Quién(es) es(son) el(los) actor(es) primario(s)?
• ·         ¿Cuáles son las metas del actor?
• ·         ¿Cuáles son las condiciones previas que deben existir antes de comenzar la historia?
• ·         ¿Cuáles son las tareas o funciones principales que realiza el actor?
• ·         ¿Cuáles excepciones podrían considerarse mientras se describe la historia?
• ·         ¿Cuáles son las variaciones posibles en la interacción del actor?
• ·         ¿Cuál es la información del sistema que el actor adquirirá, producirá o cambiará?
• ·         ¿el actor tendrá que informar al sistema acerca de cambios en el medio ambiente externo?
• ·         ¿Cuál es la información que el actor desea del sistema?
• ·         ¿el actor quiere ser informado acerca de cambios inesperados?

Obtención de Requisitos

Recopilación conjunta de requisitos

Cuando se desea estimular un esfuerzo conjunto y orientado al equipo de recopilación de requisitos, un equipo de participantes y desarrolladores trabajan juntos para identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos para la solución (ZAH90)⁸.

Se han propuestos muchos y diferentes enfoques para la recopilación conjunta de requisitos. Cada uno utiliza un escenario muy diferente, pero todos aplican alguna variación de las siguientes directrices básicas:

 

• Las reuniones las dirige alguno de los asistentes, ya sea un ingeniero de software o un cliente (junto con otros participantes interesados).

• Se establecen reglas para la preparación y participación.

• Se sugiere una agenda que sea tan formal como para cubrir todos los puntos importantes, pero tan informal como para estimular el flujo de ideas.

• Un moderador (puede ser un cliente, un desarrollador o un agente externo) controla la reunión.

• Se utiliza un “mecanismo de definición” (pueden ser hojas de trabajo, gráficos, hojas adheribles, un tablero electrónico, un mensajero electrónico o un foro virtual).

• ·    La meta es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto de requisitos de solución preliminares en una atmósfera que conduzca al cumplimiento de la meta.

Para entender mejor el flujo de los eventos (conforme éstos ocurren), se presenta un escenario breve que describe la secuencia de eventos que conducen a la reunión para la recopilación de requisitos y que ocurren durante la reunión y después de ésta.

Durante la fase de inicio, las preguntas y respuestas básicas establecen el ámbito del problema y la percepción global de una solución. Fuera de estas reuniones iniciales, los participantes escriben una “solicitud de producto” de una o dos páginas. Se fijan un lugar, una hora y una fecha para la reunión y se selecciona un moderador. Los miembros del equipo de software y otras organizaciones interesadas son invitados a asistir. La solicitud de productos se distribuye a todos los asistentes antes de la fecha de reunión.

Mientras revisa la solicitud de producto en los días previos a la reunión, se pide a cada asistente hacer una lista de objetos que son parte del ambiente que rodea al sistema, otros objetos que éste producirá, y objetos que utiliza para realizar sus funciones. Además, se le pide a cada asistente que elabore una lista de los servicios (procesos o funciones) que manipulan o interactúan con los objetos. Por último, también se preparan listas de las restricciones (por ejemplo, costo, tamaño, reglas del negocio) y de los criterios de rendimiento (por ejemplo, velocidad, exactitud). Se informa a los asistentes que no se espera que las listas sean exhaustivas, si no que reflejen la percepción que cada persona tiene del sistema.

Como un ejemplo, considérese el fragmento de un documento previo a la reunión, escrito por una persona de mercadotecnia involucrada en el proyecto de HogarSeguro. Esta persona escribe la siguiente narración acerca de la función de seguridad en el hogar que será parte de Hogar Seguro.

     Nuestra investigación indica que el mercado para los sistemas de administración del hogar está creciendo a una tasa de 40 por ciento anual. La primera función de HogarSeguro que saquemos al mercado debería ser la función de seguridad en el hogar. La mayoría de la gente está familiarizada con los “sistemas de alarmas”, por lo que dicha función sería fácil de vender.

     La función de seguridad en el hogar protegería contra o reconocería una variedad de “situaciones” indeseables como una entrada ilegal, fuego, inundaciones, niveles de monóxido de carbono y otras. Utilizará nuestros sensores inalámbricos para detectar cada situación, el usuario podrá programarla y llamará por teléfono automáticamente a una oficina de monitoreo cuando detecte alguna situación.

En realidad, otros podrían contribuir a este relato durante la reunión para la recopilación de requisitos, y mucha más información estaría disponible. Pero aun con información adicional, la ambigüedad podría estar presente, es posible que existieran omisiones y podrían ocurrir errores. Por ahora, la “descripción funcional” anterior será suficiente.

El equipo de recopilación de requisitos lo componen representantes de los departamentos de mercadotecnia, de ingeniería de hardware y software y de manufactura. Se utilizará un moderador externo.

Cada persona desarrolla las listas previamente descritas. Los objetos descritos para HogarSeguro podrían incluir el panel de control, los detectores de humo, los sensores en puertas y ventanas, los detectores de movimiento, una alarma, un evento (cuando algún sensor se active), una pantalla, una PC, números telefónicos, una llamada telefónica y otros. La lista de servicios podría incluir la configuración del sistema, la colocación de la alarma, el monitoreo de sensores, la marcación telefónica, la programación del panel de control y la lectura de pantalla (obsérvese que los servicios actúan sobre los objetos). De una manera similar, cada asistente elaborará listas de restricciones (por ejemplo, el sistema debe reconocer cuando los sensores no estén en funcionamiento, debe ser amigable para el usuario, debe tener una interfaz directa con la línea telefónica) y criterios de rendimiento (por ejemplo, el evento de un sensor debe ser reconocido en un segundo o menos, se debe implementar un esquema para la prioridad de los eventos).

Cuando se inicia la reunión para la recopilación de documentos, el primer tópico que se trata es la necesidad y la justificación para el nuevo producto, todos deben estar de acuerdo en que la necesidad del producto se justifica. Una vez establecido el acuerdo, cada participante presenta sus listas para examinarlas. Las listas pueden fijarse en las paredes del salón usando hojas grandes de papel, pegarse en los muros mediante hojas adhesivas o escribirse en un pizarrón. De manera alternativa, las listas pueden haber sido colocadas en un boletín electrónico, en un sitio web interno, o situadas dentro de un ambiente de foro de discusión (chat room) para revisarlas antes de la reunión. En forma ideal, cada asunto en la lista debe permitir manipularse por separado para que las listas se puedan combinar, los asuntos puedan borrarse y se les puedan realizar adiciones. En esta etapa crítica y el debate están estrictamente prohibidos.

Después de que las listas individuales sobre el área de un tópico se hayan presentado, el grupo crea una lista combinada. Dicha lista elimina los asuntos redundantes, incorpora ideas nuevas surgidas durante el debate, pero no borra nada. Después de haberse creado las listas combinadas para todas las áreas de los distintos tópicos, el moderador coordina el debate. La lista combinada se reduce, se incrementa o replantea para reflejar de manera apropiada el producto/sistema que se desarrollará. El objetivo es desarrollar una lista consensada en el área de cada tópico (objetos, servicios, restricciones y rendimiento). Después dichas listas se integran para la acción posterior.

Cuando se completan las listas consensadas, el equipo se divide en subequipos menores; cada uno trabaja para desarrollar miniespecificaciones para uno o más asuntos de cada una de las listas. Cada miniespecificación es una explicación concisa de la palabra o frase contenida en la lista. Por ejemplo, la miniespecificación para el objeto Panel Control de HogarSeguro podría ser:

El panel de control es una unidad empotrada en la pared con un tamaño aproximado de 9 x 5 pulgadas. El panel de control tiene conexión inalámbrica con los sensores y una PC. La interacción con el usuario ocurre por medio de un tablero de 12 teclas. Una pantalla LCD de 2 x 2 pulgadas proporciona la retroalimentación del usuario. El software provee sugerencias e imágenes interactivas y funciones similares.

Después, cada subequipo presenta sus miniespecificaciones a todos los asistentes para comentarlas. Se realizan las adiciones, anulaciones y elaboraciones posteriores. En algunos casos, el desarrollo de las miniespecificaciones descubrirá nuevos requisitos de objetos, servicios, restricciones y rendimiento que se agregarán a las listas originales. Durante los debates el equipo encontrará algún asunto que no pueda resolverse durante la reunión. Se mantendrá una lista de asuntos pendientes para que después se pueda actuar sobre estas ideas.

Después de completar las miniespecificaciones, cada asistente hace una lista de criterios de validación para el producto/sistema y la presenta al equipo. Entonces se crea una lista consensada de criterios de validación. Por último, uno o más participantes (o agentes externos) reciben el encargo de escribir las especificaciones completas mediante el uso de todos los asuntos tratados en la reunión.

El despliegue de la función de calidad

El despliegue de la función de calidad (QFD, por sus siglas en inglés) es una técnica que traduce las necesidades del cliente en requisitos técnicos para el software. El QFD “se concentra en aumentar la satisfacción del cliente desde el proceso de la ingeniería del software [ZUL92].” Para lograr lo anterior, el QFD resalta una comprensión de lo que es valioso para el cliente y después despliega estos valores durante el proceso de ingeniería. El QFD identifica tres tipos de requisitos [ZUL92]:

• Requisitos normales. Reflejan los objetivos y metas establecidos para un producto o sistema durante las reuniones con el cliente. Si estos requisitos están presentes, el cliente estará satisfecho. Algunos ejemplos de requisitos normales podrían ser los tipos de gráficos en pantalla, las funciones específicas del sistema, y los niveles de rendimientos solicitados.

• Requisitos esperados. Están implícitos en el producto o sistema y pueden parecer tan obvios, aunque son fundamentales, que el cliente no los establece de manera explícita. Su ausencia causaría una insatisfacción significativa. Algunos ejemplos de requisitos esperados son la facilidad de la interacción humano/máquina, corrección y confiabilidad operacional general y facilidad en la instalación del software.

• Requisitos estimulantes. Reflejan las características que van más allá de las expectativas del cliente y que prueban ser muy satisfactorias cuando estás presentes. Por ejemplo, un software procesador de palabras se solicita con características estándar. El producto entregado contiene varias capacidades de configuración de página que son bastantes satisfactorias e inesperadas.

En la actualidad, el QFD abarca la totalidad del proceso de ingeniería [PAR96]. Sin embargo, muchos conceptos del QFD son aplicables a la actividad de obtención de requisitos.

En las reuniones con el cliente, la función de despliegue se aplica para determinar el valor de cada función que se requiere para el sistema. El despliegue de la información identifica los datos de los objetos y eventos que debe consumir y producir el sistema. Los datos están ligados a las funciones. Por último, el despliegue de tareas examina el comportamiento del sistema o producto dentro del contexto de su entorno

.

El análisis de valor se realiza para determinar la prioridad relativa de los requisitos determinados durante cada uno de los tres despliegues.

El QFD utiliza entrevistas y observación del cliente, sondeos y exploración de los datos históricos (por ejemplo, los reportes de problemas) como datos crudos para la actividad de recopilación de requisitos. Después, estos datos se traducen en una tabla de requisitos –llamada la tabla de la voz del cliente –que se revisa con el cliente. Una variedad de diagramas, matrices y métodos de evaluación se utilizan para obtener los requisitos esperados y tratar de conseguir los requisitos estimulantes [BOS91].

Escenarios de usuario

Conforme se recopilan los requisitos se comienza a materializar una visión general de las funciones y características del sistema. Sin embargo, resulta difícil continuar con actividades de ingeniería del software más técnicas mientras el equipo de software no entienda la manera en que las distintas clases de usuarios finales aplicarán estas funciones y características. Para lograrlo, los desarrolladores y usuarios pueden crear un conjunto de escenarios que identifican una cadena de uso para el sistema que se va a construir. Los escenarios, llamados con frecuencia casos de uso [JAC92], proporcionan una descripción de cómo se usará el sistema.

Productos de trabajo de la obtención

Los productos de trabajo producidos como consecuencia de la obtención de requisitos variarán de acuerdo con el tamaño del sistema o producto que se vaya a construir.

La mayoría de los sistemas incluye los siguientes productos de trabajo:

•  Un enunciado de necesidad y factibilidad.
• Un enunciado limitado del ámbito del sistema o producto.
• Una lista de clientes, usuarios y otros interesados que participaron en la obtención de requisitos.
• Una descripción del ambiente técnico del sistema.
• Una lista de requisitos (de manera preferente organizados por función) y las restricciones de dominio aplicables a cada uno.
• Un conjunto de escenarios de uso que proporcionen un discernimiento de la utilización del sistema o producto en diferentes condiciones de operación.
• Cualesquiera prototipos desarrollados para definir de mejor forma los requisitos.
• Cada uno de estos productos de trabajo los revisa toda la gente que ha participado en la obtención de requisitos.

Inicio del proceso de la ingeniera de requisitos

Si los clientes y los ingenieros trabajan juntos en un mismo equipo, la ingeniera de requisitos se trata solo de guiar conversaciones significativas con colegas que son miembros bien conocidos del equipo, aunque la realidad es diferente.

A menudo los clientes y los ingenieros no disponen de tiempo y espacio para trabajar en equipo por diversos motivos como estar en ciudades diferentes.

Para estos casos en las secciones siguientes se examinan los pasos para iniciar la ingeniera de requisitos, es decir comenzar el proyecto de forma que se mantenga en movimiento hacia una solución exitosa.

Identificación de los interesados

Sommerville y Sawyer[SOM97] definen a los interesados como “todos aquellos que se benefician en una forma directa o indirecta del sistema que está en desarrollo”.

Ya sea identificando a los involucrados: gerentes (de operaciones, negocios, productos, mercadotecnia, etc.), los ingenieros (de software, soporte, mantenimiento, otros). Cada interesado tiene una visión diferente del sistema, obtiene beneficios diferentes cuando este se desarrolla de manera exitosa, y está abierto a diferentes riesgos si el esfuerzo de desarrollo llega a fallar.

En el inicio el ingeniero de requisitos puede crear una lista de personas que contribuirán durante la obtención de requisitos. Esta lista crecerá conforme se establezca contacto con los interesados.

Reconocimiento de múltiples puntos de vista

Los requisitos de sistema serán diversos debido a los múltiples involucrados o clientes diferentes. Los gerentes de negocios están interesados en un grupo de características que se pueden construir sin rebasar un presupuesto y que estén listas para llegar a nichos de mercado definidos. Los usuarios pueden desear características con las que estén familiarizados y sean fáciles de aprender y utilizar. Mientras que los ingenieros de software están más interesados en dar soporte a la infraestructura y características más accesibles al mercado. Y los ingenieros de soporte se pueden enfocar en la facilidad de mantenimiento del software.

Conforme se recopile información desde múltiples puntos de vista, los requisitos que surjan pueden ser inconsistentes o entrar en conflicto con algún otro.

El trabajo del ingeniero de requisitos es categorizar toda la información de los interesados (incluyendo requisitos inconsistentes y conflictivos) en una forma para el sistema que sean consistentes de manera interna.

Trabajo con respecto a la colaboración

El ingeniero de requisitos identifica áreas en común (los requisitos en los que todos los interesados están de acuerdo) y áreas en conflicto o inconsistencia. La colaboración no significa, necesariamente, que los requisitos se definan por consenso. En munchos casos, los interesados colaboran al proporcionar su visión de requisitos.

Formulación de las primeras preguntas

El primer conjunto de preguntas libres de contexto se enfoca en el cliente y otros interesados, metas generales y en los beneficios. Por ejemplo, el ingeniero de requisitos podría preguntar:

¿Quién está detrás de la solicitud de este trabajo?

¿Quién usará la solución?

¿Cuál será el beneficio económico de una solución exitosa?

¿Existe otra fuente para la solución requerida?

Estas preguntas ayudan a identificar a todos los participantes que tendrían interés en el software que será construido. Además, estas preguntas identifican el beneficio medible de una implementación exitosa y las alternativas posibles para personalizar el desarrollo del software.

La siguiente serie de preguntas permite que el equipo de software comprenda mejor el problema y deja que el cliente exprese sus percepciones acerca de una solución.

¿Cómo podría caracterizarse un buen resultado generado por una solución exitosa?

¿Cuáles problemas debería atacar esta solución?

¿Podría usted describir o mostrar el ambiente de negocios en el que se utilizará la solución?

La serie final de preguntas se enfoca en la efectividad de la actividad de comunicación en sí misma, a continuación, las “metapreguntas”:

¿Es usted la persona adecuada para contestar esta pregunta? ¿Sus respuestas son “oficiales”?

¿Mis preguntas son relevantes para su problema?

¿Estoy haciendo demasiadas preguntas?

¿Alguien más puede proporcionar información adicional?

¿Debería preguntarle alguna otra cosa?

Estas preguntas ayudarán a “romper el hielo” y a iniciar la conversación esencial para la obtención exitosa. Pero un formato de reunión de pregunta y respuesta no es un enfoque que haya sido exitoso de manera contundente. De hecho, la sesión de preguntas y respuestas se debe usar sólo para el primer encuentro, y después se debe reemplazar por un formato de obtención de requisitos que combinen elementos de resolución de problemas, negociación y especificación.

Tarea de la Ingeniería de Requisitos

La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación, y administrar los requisitos conforme estos se transforman en un sistema operacional(THA97). El proceso de la ingeniería de requisitos se lleva a cabo a través de siete distintas funciones: inicio, obtención, elaboración, negociación, especificación, validación y gestión.

Resulta importante destacar que algunas de estas funciones de la ingeniería de requisitos ocurren en paralelo y que todas deben adaptarse a las necesidades del proyecto. Todas están dirigidas a definir lo que el cliente quiere, y todas sirven para establecer una base sólida respecto del diseño y la construcción de lo que obtendrá el cliente.

1.- Inicio

¿Cómo se inicia un proyecto de software? ¿Es un evento aislado que se convierte en el catalizador para un evento sistema o proceso basado en computadora? ¿O la necesidad evoluciona con el tiempo? NO existe respuesta definitiva para estas preguntas.

Por lo general las semillas de los desarrolladores en software se siembran en los primeras tres meses desde el contenido del proyecto. Capers Jones

En algunos casos, una conversación informal es todo lo que se necesita para precipitar un esfuerzo importante de la ingeniería de software. Pero por lo general, la mayoría de los proyectos comienza cuando un nuevo mercado o servicio potencial. Los participantes de la comunidad de negocios (es decir, los gerentes, gerentes de mercadotecnia, gerentes de producto) definen un caso de negocios para la idea, tratan de identificar la amplitud y profundidad del mercado, hacen un análisis preliminar de factibilidad, e identifican una descripción funcional del ámbito del proyecto. Toda esta información está sujeta a cambios (una situación probable), pero es suficiente para suscitar conversacional con la organización de ingeniería de software.

Al inicio del proyecto los ingenieros de software hacen una serie de preguntas libres de contexto, las cuales se exponen en la sección 7.3.4. el objetivo es establecer una comprensión básica del problema, las preguntas que quieren una solución, la naturaleza de la situación que se desea, y la efectividad de la comunicación preliminar entre el cliente y el desarrollador.

2.- Obtención

En verdad parece muy simple preguntar al cliente, a los usuarios y otros interesados cuales son los objetivos para el sistema o producto, que es lo que se debe lograr, en que forma el producto satisface las necesidades del negocio y por ultimo como se utilizara el sistema o producto día a día. Pero no es simple, es muy difícil.

·         Problemas de ámbito: el límite del sistema está mal definido o los clientes/usuarios especifican detalles técnicos innecesarios que pueden confundir, en lugar de clarificar, los objetivos generales del sistema.

·         Problemas de comprensión: los clientes/usuarios no están seguros por completo de que es lo que se necesita, comprenden poco de las capacidades y limitaciones de su ambiente de computo, no comprenden del todo el dominio del problema, tienen dificultades al comunicar necesidades al ingeniero de sistemas, omiten información que consideran “obvia”, especialmente requisitos que chocan con las necesidades de otros clientes/usuarios, o especifican requisitos ambiguos o inestables.

·         Problemas de volatilidad: los problemas cambian conforme transcurre e tiempo.

Para ayudar a superar estos problemas, los ingenieros de requisitos deben realizar en forma organizada la actividad de recopilación de requisitos.

3.- Elaboración

La información conseguida con el cliente durante el inicio y la obtención se expande y se refina durante la elaboración. Esta actividad de la ingeniería de requisitos se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software.

La elaboración es una acción del modelo del análisis (capitulo 8) y se compone de una serie de tareas de modelado y refinad. La elaboración se conduce mediante la creación y el refinado 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 las colaboraciones entre las clases y se producen una variedad de diagramas de UML.

El resultado final de la elaboración es un modelo de análisis que define e dominio de la información, las funciones y el comportamiento del problema.

4.- Negociación

Dado los recursos limitados del negocio, no resulta inusual que los clientes y usuarios pidan más de lo que se puede lograr. También es relativamente común que diferentes clientes o usuarios propongan requisitos que entran en conflicto entre si al argumentar que su visión es “esencial para nuestras necesidades especiales”.

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. Se hacen estimaciones preliminares del esfuerzo requerido para el desarrollo y después se utiliza el impacto de cada requisito en el costo del proyecto y sobre el tiempo de entrega. Mediante un enfoque iterativo, los requisitos se eliminan, combinan o modifican de forma que cada parte alcance cierto grado de satisfacción.

 5.- Especificación

En el contexto de sistemas basados en computadoras (software), el termino especificación tiene significado diferente, puede ser un documento escrito, un conjunto de modelos, un modelo matemático, etc.

Por sugerencia, argumentan que los requisitos sean presentados de una manera más consistente y por ende más entendible, siendo flexible mientras se desarrolla una especificación.

La especificación es el producto de trabajo final que genera la ingeniería de requisitos. Sirve como base para las actividades de software subsecuentes. Describe la función y el desempeño de un sistema basado en computadoras y las restricciones que registran su desarrollo.

6.- Validación

La calidad de los productos de trabajos procedentes de la ingeniería de requisitos se evalúa durante un paso de Validación. Aquí se examina la especificación para asegurar que todos los requisitos se 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.

Para facilitar el examinar cada requisito se plantean algunas preguntas como las de a continuación.

·         ¿los requisitos se establecen de manera clara sin mal interpretación?

·         ¿la fuente de requisito (una persona, regulación, reglamento) está identificado?

·         ¿el requisito está definido en términos cuantitativos y que otros requisitos esta relacionados con este?

·         ¿el mecanismo viola alguna restricción del dominio del sistema?

·         ¿el requisito se puede probar, rastrear para cualquier modelo de sistema que se haya creado?

·         ¿la especificación está estructurada de una forma que conduzca a su comprensión, referencia y traducción fácil en productos de trabajo más técnicos?

·         Entre otras…

7.- Gestión de requisitos

La gestión de requisitos es un conjunto de actividades que ayudan al equipo de proyecto a identificar, encontrar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.

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.

Entre las muchas tablas de rastreabilidad posibles están las siguientes:

Tabla de rastreabilidad de las características: muestra la manera en que los requisitos se relacionan con las características del sistema/producto observable para el cliente.

Tabla de rastreabilidad de la fuente: identifica la fuente de cada requisito

Tabla de rastreabilidad de dependencia: indica la forma en que los requisitos están relacionados entre sí.

Tabla de rastreabilidad del subsistema: establece categorías entre los requisitos de acuerdo con el (los) subsistema(s) que gobierna(n).

Tabla de rastreabilidad de la interfaz: muestra la información en que los requisitos se relacionan con las interfaces internas y externas del sistema.

En muchos casos, estas tablas de rastreabilidad se mantienen como parte de la base de datos de los requisitos de forma que pueda buscárseles con rapidez para entender como el cambio en un requisito afecta diferentes aspectos del sistema que se construirá.