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).