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.