Tarea 3: Identificar/revisar los objetivos del sistema

Objetivos

1. Identificar los objetivos que se esperan alcanzar mediante el sistema software a desarrollar.
2. Revisar, en el caso de que haya conflictos, los objetivos previamente identificados.

Descripción

A partir de la información obtenida en la tarea anterior, en esta tarea se deben identificar qué objetivos se esperan alcanzar una vez que el sistema software a desarrollar se encuentre en explotación o revisarlos en función de los conflictos identificados. Puede que los objetivos hayan sido proporcionados antes de comenzar el desarrollo.

Productos internos

1. No hay productos internos en esta tarea.

Productos entregables

1. Objetivos del sistema como parte del DRS.

Técnicas recomendadas

1. Análisis de factores críticos de éxito o alguna técnica similar de identificación de objetivos.
2. Plantilla para especificar los objetivos del sistema.

Tarea 2: Preparar y realizar las secciones de elicitación/negociación

Objetivos

1. Identificar a los usuarios participantes.
2. Conocer las necesidades de clientes y usuarios.
3. Resolver posibles conflictos.

Descripción

Teniendo en cuenta la información recopilada en la tarea anterior, en esta tarea se deben preparar y realizar las reuniones con los clientes y usuarios participantes con objeto de obtener sus necesidades y resolver posibles conflictos que se hayan detectado en iteraciones precias del proceso.

Esta tarea es especialmente crítica y ha de realizarse con especial cuidado, ya que generalmente el equipo de desarrollo no conoce los detalles específicos de la organización para la que se va a desarrollar el sistema y, por otra parte, los clientes y posibles usuarios no saben qué necesita saber el equipo de desarrollo para llevar a cabo su labor.

Productos internos

1. Notas tomadas durante las reuniones, transcripciones o actas de reuniones, formularios, grabaciones en cinta o vídeo de las reuniones o cualquier otra documentación que se considere oportuna.

Productos entregables

1. Participantes en el proyecto, en concreto, los usuarios participantes, como parte del DRS.
2. Objetivos, requisitos o conflictos que se hayan identificado claramente durante las sesiones de elicitación, como parte del DRS.

Técnicas recomendadas

1. Técnicas de elicitación de requerimientos, incluyendo las plantillas de objetivos, requisitos y conflictos.
2. Técnicas de negociación como ganar vs ganar.

Tarea 1: Obtener información sobre el dominio del problema y el sistema actual

Objetivos

1. Conocer el dominio del problema.
2. Conocer la situación actual.

Descripción

Antes de mantener las reuniones con los clientes y usuarios e identificar los requerimientos, es fundamental conocer el dominio del problema y los contextos organizacional y operacional, es decir, la situación actual.

Enfrentarse a un desarrollo sin conocer las características principales ni el vocabulario propio de su dominio suele provocar que el producto final no sea el esperado por clientes ni usuarios.

Por otro lado, mantener reuniones con clientes y usuarios sin conocer las características de su actividad hará que probablemente no se entiendan sus necesidades y que su confianza inicial hacia el desarrollo se vea deteriorada enormemente.

Esta tarea es opcional, ya que puede que no sea necesario realizarla si el equipo de desarrollo tiene experiencia en el dominio del problema y el sistema actual es conocido.

Productos internos

1. Información recopilada: libros, artículos, folletos comerciales, desarrollos previos sobre el mismo dominio, etc.
2. Modelos del sistema actual.

Productos entregables

1. Introducción, participantes en el proyecto, principalmente clientes y desarrolladores, y descripción del sistema actual como parte del DRS (Documento de Requerimientos del Sistema).

Técnicas recomendadas

1. Obtener información de fuentes externas al negocio del cliente: folletos, informes sobre el sector, publicaciones, consultas con expertos, etc.

   En el caso de que se trate de un dominio muy específico puede ser necesario recurrir a fuentes internas al propio negocio del cliente, en cuyo caso pueden utilizarse las técnicas auxiliares de elicitación de requerimientos como el estudio de documentación, observación in situ, cuestionarios, inmersión o aprendizaje, etc.

2. Modelado del sistema actual.

Documento de Requerimientos del Sistema

Las tareas recomendadas para obtener el Documento de Requerimientos del Sistema (DRS) son:

• Obtener información sobre el dominio del problema y el sistema actual.
• Preparar y realizar las reuniones de elicitación/negociación.
• Identificar/revisar los objetivos del sistema.
• Identificar/revisar los requerimientos de almacenamiento de información.
• Identificar/revisar los requerimientos funcionales.
• Identificar/revisar los requerimientos no funcionales
• Priorizar objetivos y requerimientos.

Dificultades para Definir los Requerimientos

• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es particular para cada proyecto.

Prácticas Sugeridas para Escribir Requerimientos con Calidad

• Mantener sentencias y párrafos cortos. Utilizar voz activa. Utilizar gramática apropiada, ortografía y signos de puntuación. Utilizar términos consistentemente y definidos en un glosario o diccionario de datos.
• Ver si una sentencia de requerimiento está suficientemente bien definida, leída desde la perspectiva del desarrollador.
• Los autores de requerimientos a menudo batallan en encontrar el nivel correcto de granularidad. Evitar largos párrafos de relatos que contienen varios requerimientos. Una guía de granularidad útil es escribir requerimientos que sean probados individualmente. Si usted puede pensar un número pequeño de pruebas relacionadas para verificar la implementación correcta de un requerimiento, está escribiendo probablemente en el nivel correcto del detalle. Si imagina muchos tipos de pruebas diferentes, quizás varios requerimientos han sido agrupados y deben ser separados.
• Tenga cuidado con varios requerimientos que han sido agregados dentro de una simple sentencia. Conjunciones como "y" y "o" en un requerimiento sugiere que varios requerimientos han sido combinados. Nunca utilizar "y/o" en una sentencia de requerimiento.
• Escribir los requerimientos en un nivel consistente de detalles a lo largo del documento. He visto especificaciones de requerimientos que varían ampliamente en su alcance. Por ejemplo, "Un código de color válido será R por rojo" y "Un código de color válido será G por verde" se puede dividir como requerimientos separados, mientras que "El producto responderá a directivas de edición introducidas por voz" describe un subsistema completo, no un requerimiento funcional simple.
• Evitar declarar requerimientos redundantes. Mientras incluir el mismo requerimiento en varios lugares puede hacer al documento más fácil de leer, también hace el mantenimiento del documento más difícil. Las múltiples instancias del requerimiento todas tienen que ser actualizadas al mismo tiempo, no sea una inconsistencia influenciada.

Tener siempre los usuarios en mente.

No cabe duda de que esta aplicación tiene un éxito porque su desarrollo de centro en el usuario final

De modo que concluyo con lo siguiente: "En todo desarrollo de software, debemos tener al usuario siempre en mente".

Problemas de la Elicitación de Requerimientos

La mayor parte de los problemas del desarrollo de software están relacionados con la ingeniería de requerimientos, y dentro de ésta, con la elicitación de dichos requerimientos.

Aunque se disponga de excelentes lenguajes de especificación de requerimientos e incluso aunque se consiga que los clientes y usuarios validen una determinada especificación, si no se han elicitado los requerimientos correctos, todo el trabajo de desarrollo terminará con un producto técnicamente correcto pero inútil, ya que no satisfará las necesidades que dieron origen a su desarrollo.

Los problemas a los que se enfrenta la elicitación de requerimientos son múltiples. En [Raghavan et al. 1994] se establecen cinco grandes categorías de problemas dentro de la elicitación de requerimientos:

1. de articulación.
2. de comunicación
3. de limitaciones cognitivas.
4. de conducta humana.
5. técnicos.

La Elicitación de Requerimientos

A nivel de investigación, la elicitación es sin duda la actividad a la que menos atención se le ha prestado en la ingeniería de requerimientos. Por ejemplo, en [Christel y Kang 1992] puede leerse la siguiente cita de J.C. Lite:

"[...] creemos que la mayoría de los investigadores evitan tratar con la elicitación de requerimientos porque es una área dónde se tiene que tratar con informalidad, incompleción e inconsistencia. En su lugar, la investigación etiquetada como dedicada a los requerimientos normalmente se ocupa de la especificación [...]"

Y en [Goguen y Linde 1993] puede leerse:

"[...] algunos científicos informáticos podrían pensar que la elicitación de requerimientos es donde la ciencia termina y empieza el caos."

La elicitación de requerimientos debe considerarse como la actividad de la ingeniería de requerimientos en la que los ingenieros de requerimientos interactúan con el resto de los participantes para obtener, registrar, y si es necesario negociar los requerimientos que deberá satisfacer el sistema a desarrollar desde el punto de vista de clientes y usuarios, es decir, los requerimientos-C

Precisamente por la necesidad de esta interacción es por lo que los aspectos sociales son fundamentales durante esta actividad, por encima de los puramente técnicos. En palabras de J. Goguen [Goguen y Linde 1993]:

"Los problemas de elicitación de requerimientos no pueden resolverse de una forma puramente tecnológica porque el contexto social es mucho más crucial que en las fases de programación, especificación o diseño."

Las actividades de elicitación de requerimientos pueden realizarse varias veces. En la primera iteración, la elicitación de requerimientos consistirá básicamente en obtener la mayor cantidad de información, asumiendo que lo más probable es que dicha información sea incompleta, ambigua y contenga contradicciones.

En las siguientes iteraciones, la elicitación de requerimientos consistirá principalmente en la resolución de conflictos encontrados en la información elicitada durante las actividades de análisis y validación de requerimientos. La resolución de estos conflictos se llevará a cabo, normalmente, mediante algún tipo de negociación entre los participantes [Pohl 1997, Boehm et al. 1994, Patets-Llorca y Grünbacher 1999].

Problema: En Mi Organización No Se Aplica La Ingeniería de Requerimientos

Para las organizaciones sin ningún tipo de proceso de ingeniería de requerimientos, se proponen las siguientes diez guías básicas:

1. Definir una estructura normalizada del documento de requerimientos.
2. Hacer el documento fácil de cambiar.
3. Identificar de manera única cada requerimiento.
4. Definir políticas para la gestión de requerimientos.
5. Definir plantillas normalizadas para la descripción de requerimientos.
6. Usar el lenguaje de forma simple, consistente y concisa.
7. Organizar revisiones formales de los requerimientos.
8. Definir listas de comprobación para la validación.
9. Usar listas de comprobación para el análisis de los requerimientos.
10. Planificar los conflictos y su resolución.

Actividades del Modelo de Procesos de Ingeniería de Requerimientos de SWEBOK

El proyecto SWEBOK (Software Engineering Body of Knowledge) es un proyecto conjunto del IEEE y de la ACM para producir un cuerpo de conocimiento sobre ingeniería de software que se siente las bases de dicha ingeniería como una profesión. Dentro de las 10 áreas de conocimiento que han establecido, la novena corresponde a la ingeniería de requerimientos, en la cual se definen los siguientes procesos:

1. Elicitación de requerimientos. Para la realización de esta actividad se puede recurrir a técnicas como las entrevistas, la observación mediante inmersión en el negocio del cliente, el uso de escenarios o casos de uso y la utilización de prototipos, que también suelen utilizarse para las actividades de validación.
• Los objetivos: pueden considerarse como los requerimientos de alto nivel que deberá cumplir el sistema a desarrollar, por lo que es especialmente crítica su identificación en los comienzos del proceso.
• Conocimiento del dominio: es fundamental conocer el dominio del problema para poder inferir el conocimiento tácito que los participantes no suelen hacer explícito, además de para facilitar la comunicación.
• Participantes (stakeholders): es preciso identificar a todos los participantes que tengan algún tipo de interés en el desarrollo y tener en cuenta los puntos de vista de los distintos grupos.
• Entorno operacional: el sistema a desarrollar deberá funcionar en un entorno que es necesario conocer para poder identificar las necesidades de interoperabilidad con otros sistemas ya existentes.
• Entorno organizacional: además del entorno operacional, el sistema afectará el entorno organizacional, que es necesario conocer para evitar que surjan problemas con los procesos de negocio.
2. Análisis y negociación de los requerimientos. En esta actividad se pretende detectar y resolver los conflictos entre los requerimientos, determinar los límites del sistema y cómo interactuará con su entorno y transformar los requerimientos de usuario en requerimientos de software. Para completar esta actividad, se realizan las siguientes tareas:
• Clasificación de requerimientos: Es importante clasificar los requerimientos para ayudar en las labores de negociación. Los criterios de clasificación son: capacidad/restricción, prioridad, coste/impacto, volatilidad/estabilidad y requerimiento de producto/requerimiento de proceso.
• Modelado conceptual: ayuda a la comprensión del problema, aunque normalmente no puede evitarse iniciar el diseño de la solución. Existen múltiples técnicas de modelado conceptual, de modo que deben considerarse factores como la naturaleza del problema, la experiencia del ingeniero de requerimientos en el uso de una determinada técnica, si el cliente impone como requerimiento la utilización de una determinada metodología o la disponibilidad de metodologías y herramientas que soporten una determinada notación. Se recomienda realizar siempre un modelo de los límites del sistema para entender mejor el entorno y las interfaces necesarias.
• Negociación de los requerimientos: también denominada resolución de conflictos, se ocupa de resolver los problemas que puedan surgir en los requerimientos, bien porque haya peticiones por parte de clientes y usuarios que sean incompatibles, bien porque no se disponga de los recursos necesarios para la realización de ciertos aspectos del sistema, etc. Para resolver tales conflictos, es necesario consultar con todos los participantes afectados y registrar las decisiones tomadas y quién las tomó. Los conflictos pueden aparecer no sólo durante el análisis, sino también durante la validación.
3. Documentación de requerimientos. Son el medio habitual para el registro y la comunicación de los requerimientos. Se considera deseable que los requerimientos del usuario (requerimientos-C) y los requerimientos del software (requerimientos-D) vayan en documentos separados. Dentro de las tareas relacionadas con la documentación de requerimientos, se remiten a la gestión de requerimientos para aspectos como el control de versiones debido a los cambios en los requerimientos.
4. Validación de requerimientos. Se comprueban los documentos de requerimientos para detectar omisiones, conflictos y ambigüedades no detectadas en el análisis y también se debe comprobar que los requerimientos siguen las normas de calidad establecidas. En otras palabras, combinar la validación y verificación en esta actividad. De modo que se proponen tareas como revisiones técnicas de los requerimientos basadas en listas de comprobación, el uso de prototipos, verificación formal de especificaciones, etc.
5. Gestión de requerimientos. Se realiza durante todas las actividades de la ingeniería de requerimientos. Su objetivo es gestionar los cambios y el mantenimiento de los requerimientos para que representen el sistema que se va a desarrollar o que se ha desarrollado. Para conseguir estos objetivos, se proponen tareas como:
• Procedimientos para el control de cambios.
• Técnicas de gestión de configuración.
• Atributos de los requerimientos (identificadores, justificación, fuentes del requerimiento, etc.).
• Rastreabilidad (construir un grafo dirigido acíclico entre los requerimientos).

Productos del Modelo de Procesos de la Ingeniería de Requerimientos

Los cuatro productos principales que se incluyen en el modelo de procesos de la ingeniería de requerimientos son:

1. Requerimientos-C: son los requerimientos desde el punto de vista del cliente-usuario, siendo el resultado principal de la elicitación. Estos requerimientos deben expresarse de forma que todos los participantes en el proceso de ingeniería de requerimientos sean capaces de entenderlos, especialmente los clientes y usuarios. Deben ser expresados en lenguaje natural, que a priori es el único lenguaje común entre todos los participantes.
2. Requerimientos-D: son los requerimientos desde el punto de vista del desarrollador, junto con el prototipo y los posibles conflictos, siendo el resultado principal de la actividad de análisis. La forma de expresar estos requerimientos suele consistir en la elaboración de un modelo del sistema a desarrollar basado en los requerimientos-C. Los modelos pueden realizarse mediante técnicas estructuradas, técnicas orientadas a objetos, lenguajes formales o mezclas de varios de ellos.
3. Prototipo: la construcción de un prototipo del sistema a desarrollar puede facilitar enormemente tanto la validación de los requerimientos por parte de los clientes y usuarios como la elicitación de nuevos requerimientos. Los prototipos suelen ser de dos tipos: de usar y tirar o evolutivos. Los prototipos de usar y tirar suelen utilizarse principalmente para elicitar y validar requerimientos relacionados con la interfaz de usuario, mientras que los evolutivos suelen centrarse más en los requerimientos funcionales.
4. Conflictos: es importante registrar los conflictos que vayan surgiendo para poder acometer su resolución de forma organizada, involucrando a los participantes en el proceso de negociación. En el modelo propuesto, se asume que los conflictos aparecerán principalmente durante la actividad de análisis y se resolverán mediante negociación en las actividades de elicitación.

Actividades del Modelo de Procesos de Ingeniería de Requerimientos

Las tres actividades que componen el modelo de procesos de ingeniería de requerimientos son:

1. Elicitación de Requerimientos.
2. Análisis de Requerimientos.
3. Validación de Requerimientos.

La elicitación de requerimientos en la más importante de la ingeniería de requerimientos. Es en esta actividad en la que se mantiene la interacción entre clientes, usuarios y los ingenieros de requerimientos.

• Objetivos de la elicitación de requerimientos.
1. Conocer el dominio del problema: es fundamental que los ingenieros de requerimientos conozcan el dominio del problema, de forma que puedan entenderse con los clientes y usuarios y que sean capaces de transmitir dicho conocimiento al resto del equipo de desarrollo [Kovitz 1998].
2. Descubrir las necesidades reales de clientes y usuarios: además de aquellas necesidades explícitamente manifestadas por los clientes y usuarios, es muy importante llegar a descubrir el conocimiento tácito, es decir, aquellas necesidades que la mayor parte de las veces se asumen y toman por implícitas [Goguen y Linde 1993, Kovitz 1998].
3. Consensuar los requerimientos entre los propios clientes y usuarios: puede que distintos grupos de clientes y usuarios presenten distintas necesidades que sean contradictorias entre sí. Durante la elicitación, normalmente después de la primera iteración, es necesario negociar entre los distintos participantes hasta obtener una visión común de los requerimientos [Boehm et al. 1994, Parets-Llorca y Grünbacher 1999].
• Entradas y salidas de la elicitación de requerimientos.
1. Entradas: en la primera iteración, la entrada principal de esta actividad es la información proveniente de clientes y usuarios. En itereaciones posteriores también se toman como entradas los requerimientos-C, los requerimientos-D, el prototipo y los conflictos aparecidos en la iteración anterior.
2. Salidas: la salida de esta actividad es una nueva versión (o la primera si se trata de la primera iteración) de los requerimientos-C, que serán analizados en la siguiente actividad.
• Objetivos del análisis de requerimientos.
1. Detectar conflictos en los requerimientos-C: los requerimientos-C suelen ser información proveniente de distintas fuentes y normalmente presentan contradicciones o ambigüedades debido a su naturaleza informal. Durante el análisis de los requerimientos-C, normalmente mediante la construcción de un modelo, es habitual que al incrementar la precisión con la que es necesario expresar los requerimientos aparezcan dichas contradicciones o ambigüedades que deberán resolverse en nuevas reuniones de elicitación mediante algún mecanismo de negociación.
2. Profundizar en el conocimiento del dominio del problema: por mucho que el ingeniero de requerimientos aprenda sobre el dominio del problema, siempre quedarán aspectos desconocidos. Construir un modelo suele conllevar un incremento en el grado de conocimiento del problema que puede facilitar el proceso de construir un producto útil para clientes y usuarios con los conocimientos apropiados.
3. Establecer las bases para el diseño: normalmente, los modelos obtenidos durante la realización del análisis de los requerimientos-C suelen construir las bases para las actividades de diseño. En el caso de que se utilicen notaciones similares en análisis y diseño (por ejemplo, orientadas a objetos), se consigue lo que se suele denominar proceso sin costuras (seamless process en inglés), es decir, una evolución graudal de los modelos abstractos de análisis hacia los modelos más cercanos a la implementación.
• Entradas y salidas del análisis de requerimientos.
1. Entradas: son los requerimientos-C elicitados en la actividad anterior, los requerimientos-D y el prototipo de la iteración previa e información proveniente de clientes y usuarios en el caso de que tengan conocimientos de las técnicas de análisis apropiadas.
2. Salidas: es una nueva versión (o la primera si se trata de la primera iteración) de los requerimientos-D y del prototipo, que en el caso de que se utilicen especificaciones formales ejecutables para expresar los requerimientos-D puede generarse automáticamente, así como posibles conflictos encontrados en los requerimientos-C, lo que provocaría que se repitiese el ciclo elicitación-análisis.
• Objetivos de la validación de requerimientos.
1. Asegurarse de que los requerimientos describen el producto deseado: aunque las actividades de elicitación y análisis se hayan realizado correctamente, siempre es necesario confirmar que los requerimientos obtenidos se corresponden realmente con los que los clientes y usuarios desean, de forma que se evite la situación en la que el producto final, que puede ser técnicamente correcto, no es satisfactorio. Las actividades de validación conllevan generalmente a la elicitación de nuevos requerimientos debido a que, a medida que el nuevo sistema se va perfilando, suelen ir apareciendo nuevas necesidades que hasta entonces estaban ocultas, sobre todo mediante la utilización de prototipos [Davis 1995].
• Entradas y salidas de la validación de requerimientos.
1. Entradas: son los requerimientos-C, los requerimientos-D, en el caso de que los clientes y usuarios tengan conocimientos suficientes para comprender las notaciones utilizadas, el prototipo y la información de validación proveniente de clientes y usuarios.
2. Salidas: son las versiones validadas, total o parcialmente, de los requerimientos-C, requerimientos-D, en el caso de que los clientes y usuarios tengan conocimientos suficientes para comprender las notaciones utilizadas, y del prototipo. En el caso de que se detecten conflictos o se eliciten nuevos requerimientos se repite el ciclo completo de actividades.

Técnicas Aplicadas en la Ingeniería de Requerimientos (5 de 5): Casos de Uso

Los casos de uso son una técnica para especificar el comportamiento de un sistema. Según wikipedia:

"Un caso de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas."

Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzando con un evento inicial desde un actor hacia el sistema. La mayoría de los requerimientos funcionales, sino todos, se pueden expresar con casos de uso. Según el autor Sommerville, los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos. Actualmente, se han convertido en una característica fundamental de la notación UML, que se utiliza para describir modelos de sistemas orientados a objetos.

Técnicas Aplicadas en la Ingeniería de Requerimientos (4 de 5): Prototipos

Durante la actividad de extracción de requerimientos, puede ocurrir que algunos requerimientos no estén demasiados claros o que no se esté muy seguro de haber entendido correctamente los requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un desarrollo no eficaz del sistema final.

Entonces, para validar los requerimientos hallados, se construyen prototipos. Los prototipos son simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.

El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y se señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un "diseño rápido". El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo.

Técnicas Aplicadas en la Ingeniería de Requerimientos (3 de 5): Lluvia de Ideas

Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", etc.

Las reglas básicas a seguir son:

• Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas.
• Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generación de ideas.
• Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen en un requerimiento sumamente útil.
• A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva.
• Escribir las ideas sin censura.

Técnicas Aplicadas en la Ingeniería de Requerimientos (2 de 5): Sistemas Existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de información que se maneja y cómo es manejada, por otro lado también es útil analizar las distintas salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas.

Técnicas Aplicadas en la Ingeniería de Requerimientos (1 de 5): Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste de una serie de preguntas relacionadas con varios aspectos de un sistema.

Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él. El éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma.

Ingeniería de Requerimientos

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para un sistema es llamado ingeniería de requerimientos. La meta de la ingeniería de requerimientos (IR) es entregar una especificación de requerimientos de software correcta y completa.

Algunos otros conceptos de ingeniería de requerimientos son:

"La ingeniería de requerimientos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software." (Pressman, 2006: 155).

La ingeniería de requerimientos es el proceso de desarrollar una especificación de software. Las especificaciones pretenden comunicar las necesidades del sistema del cliente a los desarrolladores del sistema." (Sommerville, 2005: 82).

En síntesis, el proceso de ingeniería de requerimientos se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto de software determinado, donde es muy importante tomar en cuenta que el aporte de la IR vendrá a ayudar a determinar la viabilidad de llevar a cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un subproceso de obtención y análisis de requerimientos, su especificación formal, para finalizar con el subproceso de validación donde se verifica que los requerimientos realmente definen el sistema que quiere el cliente.

Según Lizka Johany Herrera (2003: 3), en su documento de la ingeniería de requerimientos, los principales beneficios que se obtienen de la ingeniería de requerimientos son:

• Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la ingeniería de requerimientos consiste de una serie de pasos organizados y bien definidos.
• Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La ingeniería de requerimientos proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios.
• Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la ingeniería de requerimientos, ya que es una de las etapas de mayor importancia en el ciclo de desarrollo de software y de las primeras en llevarse a cabo.
• Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.).
• Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso.
• Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Existen cuatro actividades básicas que se tienen que llevar a cabo para completar el proceso. Estas actividades ayudan a reconocer la importancia que tiene para el desarrollo de un proyecto de software realizar una especificación y administración adecuada de los requerimientos de los clientes o usuarios. Dichas actividades son:

• Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc. Es importante que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuan bien éste satisfaga las necesidades del cliente.
• Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requerimientos del sistema identificados hasta el momento. Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; en esta etapa se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.
• Especificación: En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede decir que la especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML, que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se utiliza cada vez más para la obtención de requerimientos.
• Validación: En esta fase se ratifican los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.

Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un mantenimiento adecuado al documento de especificación de requerimientos, que es el documento final, de carácter formal, que se obtiene de este proceso. Es necesario recalcar que no existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se esté desarrollando, a la cultura organizacional, y a nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores, ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el proceso.

Problemas en la Ingeniería de Requerimientos

En 1997, Zave establece una clasificación de los esfuerzos de investigación de ingeniería de requerimientos. Según dicho trabajo, los problemas de ingeniería de requerimientos pueden encuadrarse dentro de los siguientes grupos:

• 1. Problemas de investigación de los objetivos, funciones y restricciones de un sistema de software: recolección de información, análisis de la información y generación de estrategias alternativas.
• 1.1. Superar barreras de comunicación: los ingenieros de requerimientos deben tratar con un amplio abanico de personas con distintos conocimientos, intereses y objetivos personales. ¿Cómo comunicarse con personas con conocimientos, intereses y objetivos diferentes al nuestro?
• 1.2. Generar estrategias para convertir requerimientos imprecisos en propiedades o conductas específicas: un ejemplo de este tipo de requerimientos imprecisos suelen ser la amigabilidad con el usuario, seguridad, precisión, fiabilidad, etc.
• 1.3. Entender prioridades y rangos de satisfacción: muchos requerimientos no son absolutos, sino que pueden satisfacer parcialmente o si los recursos lo permiten.
• 1.4. Generar estrategias para asignar requerimientos al sistema o a los distintos agentes de su entorno: dado que los requerimientos reales siempre se refieren al mundo real en el que se explotará el sistema software a desarrollar, antes de especificarlo se deben asignar objetivos, funciones y restricciones a los componentes y agentes que contribuirán a satisfacerlos. En otras palabras, decidir el ámbito del sistema: qué aspectos quedan y qué aspectos se asignan al entorno.
• 1.5. Estimar costes, riesgos y duración: es muy importante para decidir sobre los requerimientos opcionales, que se satisfacen según los recursos de desarrollo.
• 1.6. Asegurar la compleción: cómo asegurarse de que no se han dejado de lado personas, puntos de vista, hechos, etc. en la investigación del sistema.
• 2. Problemas de especificar la conducta de un sistema software: sintetizar información y elegir entre alternetivas para crear una especificación software mínima y precisa.
• 2.1. Integrar múltiples vistas y representaciones: los resultados de la investigación suelen ser diversos y tener conflictos, por lo que suele ser necesario algún tipo de negociación.
• 2.2. Evaluar estrategias alternetivas para satisfacer requerimientos: la especificación del sistema supone tomar decisiones sobre la solución del problema. Normalmente, la solución no es única.
• 2.3. Obtener especificaciones completas, consistentes y no ambiguas: es la única forma de asegurarse de que el sistema final cumplirá los requerimientos iniciales.
• 2.4. Comprobar que el sistema especificado satisfará los requerimientos: diseñar estrategias de validación que aseguren que la especificación es acorde a los requerimientos iniciales.
• 2.5. Obtener especificaciones útiles para las actividades de implementación y diseño: es la mejor estrategia para introducir procesos de ingeniería de requerimientos en las organizaciones.
• 3. Problemas de gestionar la evolución de sistemas y familias de sistemas.
• 3.1. Reutilizar ingeniería de requerimientos durante fases evolutivas: es decir, asegurarse de que los productos de la ingeniería de requerimientos son mantenibles. Las técnicas más usadas son la rastreabilidad y la modularidad de la especificación.
• 3.2. Reutilizar ingeniería de requerimientos para desarrollar sistemas similares: es decir, asegurarse de que los productos de la ingeniería de requerimientos se pueden aplicar a familias de sistemas.
• 3.3. Reconstruir requerimientos: ingeniería inversa de requerimientos.