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.

Hacia la Priorización de los Requerimientos Basados en el Valor para la Administración del Productos de Software

Resumen.

Reunir los requerimientos y expectaciones de los stakeholders llega a ser uno de los aspectos criticos sobre los cuales cualquier organización de software en los entornos impulsados por el mercado se enfocan y pagan una gran cantidad de esfuerzo y los gastos maximizan la satisfacción de sus stakeholders. Además, identificar los contenidos de liberación del producto de software llega a ser una de las decisiones criticas para el éxito del producto de software. La priorización de requerimientos refiere a aquella actividad a través de la cual los contenidos de liberación del producto que maximizan la satisfacción del stakeholder puedan ser identificados. Este artículo ilustra la propuesta de priorización de requerimientos Orientada al Valor para la administración de productos de software. La técnica propuesta en este artículo está basada en las técnicas de Votación Acumulativa Jerárquica (HCV) y la Priorización Orientada al Valor (VOP). La técnica propuesta, Valoración Acumulativa Jerárquica Orientada al Valor (VOHCV) refiere a la debilidad de HCV a través de seleccionar los mejores requerimientos candidatos para cada liberación no solamente basados en el valor percibido por el stakeholder como HCV sino también en los términos del costo anticipado asociado, riesgo técnico, aspectos de impacto relativo y relacionados al mercado. La VOHCV también refiere a la debilidad de VOP a través del apoyo no solamente en la estructura llana de los requerimientos como VOP sino también a través del apoyo de estructura jerárquica. Por este medio VOHCV hereda las fortalezas de VOP y HCV y refiere sus debilidades mientras selecciona los mejores requerimientos de liberación candidatos, para maximizar el valor y satisfacción de los stakeholders.

1. Introducción.

Debido al continuo incremento en el número de requerimientos de software para los productos impulsados ​​por el mercado, hay una creciente necesidad de métodos capaces de dar prioridad a los requerimientos candidatos, ya que no todos los requerimientos por lo general pueden ser atendidos con tiempo disponible y las limitaciones de recursos en la versión de software. Así, muchas organizaciones creen que no es solamente importante permitir a sus clientes asignar prioridades a los requerimientos y hacer decisiones acerca de ellos sino también proporcionarles con soluciones alternativas diferentes a la medida para sus propias necesidades. De esta manera ellos proporcionarán más valor para sus clientes a través de la selección de los requerimientos con mayor valor para ser implementados en cada una de las liberaciones del producto.

Administrar los requerimientos para cualquier producto de software llega a ser un factor clave que identifica no solamente el éxito o falla del proyecto sino también el destino de la organización. La porción critica de este proceso es identificar esos requerimientos que balancean las necesidades de los stakeholders, expectaciones del cliente, valores de negocio, costo total y calendarización. Además la priorización de los requerimientos y procesos de selección que maximizan el valor del stakeholder tienen un gran impacto en el éxito del producto.

La Priorización Orientada al Valor (VOP) se refiere a aquel proceso por el cual evalua los requerimientos por diferentes stakeholders basados en el impacto sobre los valores principales de negocio específicos para la organización y los mismos stakeholders desde el enfoque sobre el valor porporcionando la oportunidad para crear una estrategia para lograr un crecimiento rentable ventaja sostenible sustentable a largo plazo. VOP también apoya a los estakeholders con un mecanismo visible durante la toma de decisiones para ser capaz de proporcionar sus valores de VOP, llegando a ser mucho más fácil para los stakeholders emfatizar los valores de negocio.

La organización de este artículo es como sigue. En la siguiente sección, referiremos al trabajo relacionado por nuestra investigación. En la sección tres elaboraremos la justificación del algoritmo VOHCV, y la metodología de investigación que hemos aplicado para desarrollarlo. En la sección cuatro, discutiremos las especificaciones del algoritmo VOHCV. La sección cinco ilustra las ventajas prácticas del algoritmo VOHCV a través de una comparación entre los algoritmos HCV y VOHCV. La sección final resume nuestras conclusiones e introduce nuestra investigación futura.

2. Trabajo relacionado.

2-1 Escala de medición.

Los sistemas de medición son calificados dentro de cuatro diferentes ordenados tipos de escala basados en la riqueza: Nominal, Ordinal, Intervalo y Racional. El tipo de escala Racional dice que es más rica que el tipo de escala Ordinal como todas las relaciones entre la escala Racional están contenidas en la escala Ordinal. Así el tipo de escala es utilizado para determinar qué operaciones aritméticas son permitidas y qué tipos de análisis pueden ser ejecutados basados en estas operaciones. Para la priorización de requerimientos, los tipos de escala Ordinal y Racional son las técnicas más comunes. La escala Ordinal conserva el orden de los requerimientos de acuerdo al valor asignado a cada requerimiento, el cual indica que operaciones aritméticas no están permitidas. Así, la escala Racional proporciona no solamente el orden de los requerimientos sino también la relativa distancia entre los diferentes requerimientos. La escala Racional también puede identificar en qué cantidad un requerimiento es más importante que otro. Cuando utiliza una técnica de priorización que proporciona prioridades relativas en una escala de Racional, es posible calcular la importancia total de un conjunto de requerimientos agregando junto con sus prioridades. Una de las ventajas más interesantes de la escala Racional es que permite cálculos sofisticados para preparar diferentes soluciones candidatas para basar decisiones en ellas.

2-2 Jerarquía de requerimientos.

Los requerimientos existen naturalmente en niveles diferentes de abstracciones. Esto hará el proceso de priorización de requerimientos más difícil especialmente cuando los requerimientos existen en diferentes niveles de abstracciones. Esta dificultad surge porque los requerimientos en niveles diferentes de abstracciones tienen importancias diferentes desde los requerimientos de nivel bajo (hojas) eran considerados menos importantes hasta los requerimientos de nivel alto (objetivos). Así, solamente estos requerimientos que existen en el mismo nivel de jerarquía deben ser comparados mientras se ejecuta la priorización. Para la priorización de varios niveles, los requerimientos de nivel bajo pueden heredar las prioridades de los requerimientos de nivel alto, o ser asignadas estas prioridades directamente. El primer caso es utilizado cuando los requerimientos de nivel bajo tienen relación AND entre ellos mismos, mientras que este último es utilizado cuando los requerimientos de nivel bajo tienen relación OR entre ellos mismos.

2-3 Priorización de Voto Acumulado por Jerarquía.

La priorización de Voto Acumulado por Jerarquía (HCV) es una técnica de priorizacion de escala Racional. HCV fue diseñado para superar los inconvenientes ppor las técnicas de Protocolo Jerárquico Analítico (AHP) y Voto Acumulativo (CV), y heredar las ventajas y buenas características de ambas técnicas. Por otra parte, HCV es tomado para ser una extensión de la técnica CV para apoyar la jerarquía. Esta característica permite a HCV para resolver varios aspectos de problemas de decisión como AHP. Tener HCV proporciona relativas prioridades basadas en una escala Racional, le da la oportunidad de calcular la importancia total de un conjunto de requerimientos agregando junto con sus prioridades. También ayuda a combinar los diferentes aspectos y raciones de cálculos entre estos aspectos. Por ejemplo, usted puede calcular la ración valor de costo para el requerimiento que representa cuánto valor cada requerimiento agrega relativo al costo anticipado de implementación. La fortaleza de HCV incrementará cuando el número de requerimientos crezca porque la necesidad para una propuesta estrucutral/jerárquica se hace más grande. HCV proporciona esta estructura a través de utilizar relaciones naturales entre los requerimientos para ejecutar la priorización en una serie de pasos y por lo tanto minimizar los requerimientos priorizados a la vez.

El principal concepto detrás de HCV es cuantificar la importancia del requerimiento distribuyendo puntos entre los requerimientos para reflejar esta importancia. Sin embargo, cuando priorizar con HCV, no todos los requerimientos son priorizados al mismo tiempo. En su lugar, las priorizaciones son ejecutadas en niveles diferentes de jerarquía, y dentro de diferentes bloques de los requerimientos en la jerarquía (mostrado en la figura 1). Como se ilustra en la figura 1, los requerimientos están distribuidos sobre dos niveles de la jerarquía: requerimientos de nivel alto (HLR) y los requerimientos de nivel bajo (LLR). La relación entre los requerimientos de nivel bajo son relaciones OR entre ellos mismos. Solamente estos requerimientos dentro del mismo bloque (área gris en la figura) son priorizados al mismo tiempo. Esto hará el proceso de priorización más suave y el riesgo de descuidar algún requerimiento disminuirá.

Figura 1. Jerarquía de requerimientos HCV.

2.4 Priorización Orientado al Valor.

La priorización Orientada al Valor (VOP) demostró ser el proceso por el cual alinea las demandas del producto con los objetivos de la compañía y las expectaciones de los stakeholders a través de proporcionar un proceso visible y definido para priorizar y administrar los requerimientos sobre el ciclo de vida del producto. Esto ayuda al stakeholder para ver el panorama completo en aras de los destinos y visión de la organización, en lugar de discutir sobre qué requerimientos del producto implementar.

La idea completa detrás de VOP es enfocarse en los valores de negocios principales que conduzcan a la satisfacción de los stakeholders mientras da prioridad a los requerimientos del producto lo indicó Karl Wiegers. Los ejemplos de estos valores de negocios principales son valor para el cliente ganado por la implementación del requerimiento, el costo de implementación, el riesgo asociado con la implementación de este requerimiento, impacto que ocurrirá si este requerimiento no es implementado y otros aspectos relacionados del mercado que serán afectados si este requerimiento no es implementado. La atractividad del requerimiento es proporcional al valor que proporciona e inversamente proporcional a su costo, riesgo asociado, impacto y aspectos de mercado. A cada valor de negocio es dado un peso basado en los objetivos y visión de la organización. Cada stakeholder pone su estimación contra cada valor de negocio para cada requerimiento. Todas estas entradas de valores son consolidados en conjunto mientras genera la clasificación del requerimiento.

3. Técnica Razón Fundamental y de Investigación.

3-1 Razón fundamental.

La razón fundamental detrás de el VOHCV es combinar las técnicas HCV y VOP para ganar las ventajas de ambas. VOHCV no solamente tomará el valor como en HCV o el costo y riesgo como en VOP dentro de la cuenta mientras prioriza los requerimientos, sino también tomará dentro de la cuenta los otros valores de negocio tales como el impacto de la implementacón relativo y los aspectos relacionados al mercado. Esto cederá a resultados de calidad más alta porque toma las diferentes características que afectan el requerimiento a lo largo del ciclo de vida del producto dentro de la cuenta mientras produce toda la clasificación de liberación.

3-2 Técnica de investigación.

La metodología de investigación que seguimos para la concepción de esta técnica está basada en la propuesta de entrega de software incremental y se describe como sigue:

• Revisar literatura de los desafíos actuales y prácticos de la industria de la administración de productos de software para los negocios y perspectivas estratégicas. Los resultados revisión muestra la importancia del proceso de priorización en el manejo de estos desafíos.
• Revisar literatura de las técnicas de priorización que ayudan al logro de los desafíos de la administración del producto de software. El resultado de esta revisión mostró que las técnicas HCV y VOP son las mejores candidatas las cuales enfocan el valor ganado mientras se prioritizan los requerimientos del producto.
• Identificar los pros y contras de estas técnicas de priorización.
• Una implementación del prototipo de la técnica VOHCV basada en el conocimiento ganado desde los puntos anteriores.
• Diseñar un framework con el motor núcleo basado en la técnica de priorización propuesta para facilitar el testeo y evaluar la eficacia de VOHCV.
• Utilizar el framework diseñado para referir un grupo de los casos abiertos con HCV para ayudar a mantener la robustez de VOHCV.

4. Detalles del Algoritmo VOHCV.

Para manejar la priorización de requerimientos utilizando VOHCV, existe una serie de pasos necesarios para ser seguidos como se indican:

• Paso 1: Asignar los pesos globales de los valores de negocios principales. Los valores de negocios apoyados para cada requerimiento en VOHCV son, el costo de implementación anticipado, riesgo de implementación asociado, valor del cliente percibido, impacto relativo y aspectos relacionados al mercado. Estos pesos son asignados basados en los objetivos estratégicos y visión futura de la organización. Estos pesos oscilarán de 1 a 10 (1 refleja la importancia más baja y 10 refleja la importancia más alta).
• Paso 2: Asignar los pesos para cada característica del valor de negocio. Este peso reflejará cuán importante es cada característica para el stakeholder y controlado por los objetivos de la organización. Estos pesos serán comunes para todo stakeholder compartido en el proceso de priorización de requerimientos. Estos pesos oscilarán de 1 a 10 (1 refleja la importancia más baja y 10 refleja la importancia más alta).
• Paso 3: Cada stakeholder entroducirá su punto de vista para cada característica de valor de negocio en términos del valor de la característica. Este valor reflejará cómo esta característica afectará el requerimiento desde su propio punto de vista. Todos los valores de negocio mencionados anteriormente tienen diferentes características excepto el valor de negocio el cual tiene solamente una característica. Estos valores oscilarán de 1 a 10 (1 refleja la importancia más baja y 10 refleja la importancia más alta).
• Paso 4: Calcular los puntos de distribución del requerimiento asignado a cada requerimiento basado en los pesos y valroes de la característica de anterior. Esto debe ser bueno para cada stakeholder compartido en el proceso de priorización de requerimientos. Para mostrar como estos puntos de distribución son calculados, asumimos los siguientes parámetros:
  • 1) Wc: Peso del valor de negocio (Costo) global.
  • 2) Wv: Peso del valor de negocio (Valor) global.
  • 3) Wr: Peso del valor de negocio (Riesgo) global.
  • 4) Wi: Peso del valor de negocio de Impacto global.
  • 5) Wa: Peso del valor de negocio de Aspecto global.
  • 6) Wi,j: Peso asignado al requerimiento (Ri) con respecto a la característica del valor de negocio (Fj).
  • 7) Vi,j: Valor asignado al requerimiento (Ri) con respecto a la característica del valor de negocio (Fj).
  • 8) Nc: Contador de características por valor de negocio (Costo).
  • 9) Nr: Contador de características por valor de negocio (Riesgo).
  • 10) Ni: Contador de características por valor de negocio (Impacto).
  • 11) Na: Contador de características por valor de negocio (Aspecto).
  • 12) Nb: Contador de valores de negocio que afectan el requerimiento.
  • 13) CBVavr: Valor promedio para el valor de negocio (Costo) que afecta el requerimiento.
  • 14) RBVavr: Valor promedio para el valor de negocio (Riesgo) que afecta el requerimiento.
  • 15) IBVavr: Valor promedio para el valor de negocio (Impacto) que afecta el requerimiento.
  • 16) ABVavr: Valor promedio para el valor de negocio (Aspecto) que afecta el requerimiento.
  • 17) TNdist: Número de distribución total para el requerimiento.
  • 18) ANdist: Número de distribución promedio para el requerimiento.
  • 19) Cf: Factor de compensación para controlar el rango del número de distribución. Será establecido a 10 para tener el rango de número de distribución entre 1 y 100 similar al ordinario HCV.
  • 20) R_Pt: Número de puntos asignados a cada requerimiento.

  El proceso de calcular el número de distribución promedio para cada requerimiento puede ser mostrado como sigue:

  1) Calcular el valor de negocio promedio para cada requerimiento.

  Valor promedio del valor de negocio (Costo)
  
  
  Valor promedio del valor de negocio (Riesgo)
  
  
  Valor promedio del valor de negocio (Impacto)
  
  
  Valor promedio del valor de negocio (Aspecto)
  
  

  2) Calcular el número de distribución total para cada requerimiento.

  

  3) Calcular el número de distribución promedio asignado para cada requerimiento. Referiremos a este número como la prioridad asignada.

  

  4) Calibrar el número de distribución entre la diferencia LLRs del mismo HLRs para tener la suma de todos los puntos LLRs igual a 100 como lo indicado por la técnica CV. Esto puede ser calculado utilizando la relación entre los números de distribución LLRs y la ecuación de abajo.

  
• Paso 5: Calcular la prioridad intermedia para los requerimientos ya sea a través del cálculo lineal o compensado. Para mostrar cómo la prioridad intermedia es calculada, asumimos los siguientes parámetros:
1. Pi, LLR_u: Valor de prioridad intermedia para el Requerimiento de Nivel Más Bajo (LLR)(u).
2. PA, LLR_u: Valor de prioridad asignado para el Requerimiento de Nivel Más Bajo (LLR)(u) calculado desde el paso previo.
3. PA, HLR_v: Valor de prioridad asignado para el Requerimiento de Nivel Más Alto (HLR)(v), o el pariente de LLR_u.
4. CHLR_v: Bloque específico del factor de compensación, esto podría ser el número de requerimietnos dentro del bloque de priorización.

• Paso 6: Calcular la prioridad final para los requerimientos en el nivel de interés. El cálculo es ejecutado a través de los bloques dentro del mismo nivel. Esto indica que todos los requerimientos ubicados en este nivel específico serán priorizados relativo uno de otro. Para mostrar cómo la prioridad final ha sido calculada, asumimos los siguientes parámetros:
1. Pf, LLR_u: El valor de prioridad final para el Requerimiento Más Bajo (LLR)(u).
2. Pi, LLR_k: El valor de prioridad intermedio para todos los Requerimientos de Nivel Más Bajo (LLR)(k) del (HLR_v).

• Paso 7: Calcular la prioridad final basada en la consolidación de prioridades pesadas por los stakeholders calculadas desde los pasos anteriores. Para mostrar cómo la prioridad final es calculada, asumimos los siguientes parámetros:
1. Pmf, LLR_u: El valor de prioridad final para todos los stakeholders del Requerimiento de Nivel Más Bajo (LLR)(u).
2. Pf, LLR_u, S_k: El valor de prioridad final para los stakeholders (S_k) del Requerimiento de Nivel Más Bajo (LLR)(u).
3. Wk: Peso normalizado del stakeholder.

• Peso 8: Calcular el rango final basado en el valor de prioridad final asignado a cada requerimiento.

Estudio de Caso

Con el fin de mostrar las ventajas prácticas de VOHCV, ilustraremos esto a través de un ejemplo basado en la estructura jerárquica de requerimientos (mostrado en la figura 1). En este ejemplo, existen dos niveles de abstracciones y un stakeholder. Además existen dos requerimientos de nivel alto (HLRs) y cinco requerimientos de nivel bajo (LLRs). Dado los pesos de valores de negocio, las pesos característicos y valores característicos para cada requerimiento de la tabla 1, seremos capaces de calcular los requerimientos por los siguientes pasos del algoritmo VOHCV mencionados en la sección previa.

El primer paso en el algoritmo VOHCV es calcular el número de puntos asignados a cada requerimiento del mismo bloque, o por otros medios distribuya 100 puntos sobre los requerimientos del mismo bloque.

Tabla 1. Entradas de valores y pesos.

Valor de negocio (B.V.)	Costo		Riesgo		Impacto	Aspecto		Valor
Peso B.V.	9		10		6	4		5
Tipo de característica	C1	C2	R1	R2	I1	A1	A2	V1
Peso de la característica	5	8	10	6	3	7	8	10
HLR1 (valor)	3	4	5	3	1	1	5	2
HLR2 (valor)	9	6	6	8	9	10	3	7
LLR1 (valor)	1	10	10	7	2	5	9	4
LLR2 (valor)	8	10	9	10	10	8	9	10
LLR3 (valor)	4	5	6	5	4	3	2	10
LLR4 (valor)	1	2	2	4	3	2	4	3
LLR5 (valor)	9	8	10	7	9	10	9	10

Esto puede ser bueno para aplicar ecuaciones 1 a través de 7, dados los valores y pesos de la tabla 1. Estos puntos son ilustrados en las primeras dos columnas en la tabla 2. Después de que todos los requerimientos en los bloques de priorización hayan sido asignadas prioridades, el siguiente paso es calcular la prioridad intermedia de LLR utilizando la ecuación 8, dado que el factor de compensación es equivalente al tamaño del bloque como se ilustró en la tercera columna de la tabla 2. La prioridad intermedia LLR está ilustrada en la cuarta columna de a tabla 2. El siguiente paso es calcular la prioridad normalizada final de LLR utilizando la ecuación 9. La prioridad final se ilustró en la quinta columna de la tabla 2. El último paso es rankear los LLRs basados en la prioridad final de LLR. La prioridad de rankeo de LLR está ilustrado en la sexta columna de la tabla 2.

Tabla 2. Rankeo de los requerimientos VOHCV.

HLR/LLR	Puntos HLR	Punto LLR	Factor compensación	Prioridad intermedia	Prioridad final	Rankeo
HLR1/LLR1	30	40	2	2400	9	5
HLR1/LLR2	30	60	2	3600	13	3
HLR2/LLR3	70	33	3	6930	26	2
HLR2/LLR4	70	15	3	3150	12	4
HLR2/LLR5	70	52	3	10920	40	1

Como se muestra desde las primeras dos columnas de la tabla 2, HLR2 (70%) es más importante que HLR1 (30%) y LLR5 es considerado a ser el más importante LLR y cuenta por (40%) de la importancia de todos los LLRs mientras que LLR (9%) es considerado a el más poco importante LLR sobre todos los otros LLRs.

6. Evaluación de VOHCV en Comparación a HCV.

Con el fin de mostrar la fortaleza de la nueva técnica propuesta (VOHCV) comparada a la ordinaria (HCV), una evaluación empírica debe ser conducida. El principal inconveniente de HCV es que toma solamente la perspectiva de "Valor" en cuenta mientras los requerimientos son priorizados y descuida las otras perspectivas de negocio. Por otro lado VOHCV arregla esto tomando las otras perspectivas de negocio en cuenta a través del proceso de priorización.

Para mostrar esto, utilizaremos el ejemplo introducido en la sección previa y excluiremos todas las perspectivas excepto la perspectiva de "Valor" para ganar el rankeo de HCV. Después de una comparación detallada entre las dos técnicas serán conducidas basadas en los resultados. Con el fin de calcular los puntos de distribución en la novena columna de la tabla 1, utilizaremos la relación entre esos valores que pertenecen al mismo bloque de priorización. Por ejemplo, LLR1 y LLR2 pertenecen al mismo bloque y tienen igual valor a 4 y 10 respectivamente. Para distribuir 100 puntos sobre estos dos LLRs manteniendo la relación entre los valores asignados, podemos concluir por un sencillo cálculo matemático que LLR1 pueden ser asignados 71 puntos y LLR2 pueden ser asignados 29 puntos. Lo mismo puede ser bueno para LLR3, LLR4 y LLR5 de modo que están en el mismo bloque. El cálculo para el último caso cederá a LLR3 le serán asignados 43 puntos, LLR4 le serán asignados 14 puntos y LLR le serán asignados 43 puntos. El cálculo de priorización será como sigue (mostrado en la tabla 3):

Tabla 3. Rankeo de los requerimientos HCV.

HLR/LLR	Puntos HLR	Punto LLR	Factor de compensación	Prioridad intermedia	Prioridad final	Rankeo
HLR1/LLR1	22	71	2	3124	11	4
HLR1/LLR2	22	29	2	1276	4	5
HLR2/LLR3	78	43	3	10062	36	1
HLR2/LLR4	78	14	3	3276	13	3
HLR2/LLR5	78	43	3	10062	36	2

Comparando los resultados entre HCV y VOHCV como se ilustró desde la tabla 1 y 2, concluimos lo siguiente:

• LLR5 es considerado el más importante de los LLRs y contando (40%) de la importancia de todos los LLRs como resultado de aplicar la técnica VOHCV.
• LLR3 es considerado como el más importante de los LLRs y contando (36%) de la importancia de todos los LLRs como resultado de aplicar la técnica HCV
• LLR1 es considerado como el menos importante de los LLRs y contando (9%) de la importanciade todos los LLRs como resultado de aplicar la técnica VOHCV.
• LLR2 es considerado como el menos importante de los LLRs y contando (4%) de la importancia de todos los LLRs como resultado de aplicar la técnica HCV.
• Descuidando el efecto de las otras perspectivas de negocio antes que ceda el "Valor" para LLR5 (el más importante de los LLRs para VOHCV) y LLR3 (el más importante de los LLRs para HCV) de la tabla 1. Los valores de LLR3 indican que el stakeholder asignó a ellos valores pequeños para indicar baja prioridad de este LLR comparado a los otros. Mientras que los valores para LLR5 indican que el stakeholder asigna a este un valor grande para indicar cuan importante es este LLR comparado a los otros los cuales son detectados por VOHCV.
• La calidad de resutlados de VOHCV es mucho más alta que HCV y refleja los casos de negocio reales. Los casos de negocio reales no solamente toman el efecto de "Valor" y descuidan las otras perspectivas, sino que toman todas las diferentes perspectivas que afectan el requerimiento a lo largo del ciclo de vida del producto en cuenta.
• Adoptando VOHCV como una metodología para priorizar los requerimientos cede a la credibilidad más alta con los contenidos de liberación que resulta en satisfacción al cliente.

7. Conclusiones y Trabajo Futuro.

En este artículo, hemos presentado las fortalezas y debilidades de las técnicas de Priorización Orientadas al Valor (VOP) y la de Voto Acumulativo Jerárquico. De estas fortalezas y debilidades, se nos ocurrió la nueva técnica de priorización la cual es Voto Acumulativo Jerárquico Orientado al Valor (VOHCV). VOHCV combina las fortalezas de VOP y HCV para mejorar la calidad del proceso de priorización de requerimientos. La principal diferencia entre el HCV y VOHCV es que VOHCV utiliza la propuesta orientada al valor no solamente para conseguir el efecto de valor sino que también para conseguir el efecto de diferenciar de otros valores de negocio principales como costo, riesgo, aspecto e impacto. De esta manera VOHCV permite al administrador del producto tomar todos los aspectos que afectan el requerimiento a tomar en cuenta mientras selecciona al mejor candidato para liberar el producto.

Ya diseñamos un framework de administración de liberación con VOHCV embebido para conseguir beneficio de los resultados producidos por VOHCV en la planeación de liberación y administración del producto de software. VOHCV actua como el motor primario principal del framework diseñado. El resultado de el VOHCV toma como entrada de las demás actividades de planeación de liberación para apoyar y permitir administrar el producto para controlar y administrar fácilmente el producto de software.

Dado a que unos pocos estudios han sido ejecutados para evaluar la eficiencia y conveniencia de VOHCV, existe una necesidad de hacer los demás estudios para algunos casos que puedan afectar la eficiencia del algoritmo. Los ejemplos de estos casos abiertos como cuantos puntos debemos distribuir sobre los requerimientos del mismo bloque, cuantos niveles de jerarquías deben ser priorizados, cuán grandes bloques de prioridad son posibles para priorizar y también el efecto de ordenar los requerimientos sobre el rankeo de requerimentos, serán nuestro objetivo para la siguiente fase de nuestra investigación.

Fuente original: Int. J. of Software Engineering, IJSE Vol.1 No.2 July 2008; "Towards Value-Based requirements priorization for software product management".

Propiedades Deseables de los Requerimientos

La propiedad más importante de una especificación de requerimientos es que sirva como canal de comunicación entre los participantes en el proceso de ingeniería de requerimientos. Para ello, es necesario pensar en la audiencia a la que van dirigidos los requerimientos, de forma que para comunicarse con los clientes y usuarios los mejor es utilizar requerimientos-C

y para hacerlo con los desarrolladores lo mejor es usar requerimientos-D.

Las propiedades deseables de los requisitos son:

• Correcta: Una especificación de requerimientos es correcta sí y sólo sí todo requerimiento contenido en ella representa alguna propiedad requerida por el sistema a desarrollar.
• No ambigua: Una especificación de requerimientos es no ambigua sí y sólo sí todo requerimiento contenido en ella tiene una sola interpretación: glosario de términos.
• Completa: Una especificación de requerimientos es completa si cumple las siguientes propiedades:
• Todo lo que se suponga que deba hacer el sistema a desarrollar está incluido en la especificación.
• Todas las respuestas del sistema a entradas tanto válidas como inválidas están especificadas.
• Todas las páginas, figuras y tablas están numeradas, todas las unidades de medida están definidas, todas las referencias externas son comprobables y no hay elementos por determinar.
• En el caso de que haya elementos por determinar, es necesario conocer la causa de su no determinación y quién es responsable de su solución.
• Es conveniente que los requerimientos estén priorizados por el cliente para considerar una especificación como completa.
• No debe omitirse ningún requerimiento.
• El cliente ha validado el conjunto de requerimientos.
• Si no se especifican todos los requerimientos se incrementa el riesgo de acabar desarrollando sistemas que no satisfagan las necesidades reales de clientes y usuarios.
• Consistente: Una especificación de requerimientos es consistente sí y sólo sí todo requerimiento contenido en ella no está en conflicto con otros documentos de nivel superior. Es consistente internamente sí y sólo sí no existen conflictos entre los requerimientos que contiene. Los conflictos entre requerimientos pueden ser de los siguientes tipos:
• Conflictos de conducta: Dos o más requerimientos especifican conductas distintas del sistema para las mismas condiciones y el mismo estimulo externo.
• Conflictos de términos: Se utilizan términos distintos para referirse al mismo concepto.
• Conflictos de característica: Dos o más requerimientos especifican aspectos contradictorios para la misma característica del sistema.
• Conflictos temporales: Dos o más requerimientos exigen características temporales contradictorias al sistema.
• Especificación internamente consistente: Necesidad de un mismo nivel de detalle y de un mismo estilo de redacción y de presentación de los requerimientos. Otra propiedad relacionada con la consistencia interna es la necesidad de que la especificación esté limitada, es decir, que el ámbito y el contexto en el que se definen los requerimientos esté claramente identificado.
• Verificable: Una especificación de requerimientos es verificable sí y sólo sí existe un proceso finito y de costo razonable por el que una persona o una máquina pueda comprobar que el sistema cumple la especificación de requerimientos. Los procedimientos de observación para comprobar que el sistema cumple los requerimientos son la base para las pruebas de aceptación del sistema por parte del cliente.
• Modificable: Una especificación de requerimientos es modificable sí y sólo sí su estructura y estilo de redacción permite que los cambios se pueda realizar fácil, completa y consistentemente. Para conseguir esta propiedad, la especificación debe estar organizada coherentemente y debe contar con los índices y las tablas de referencias cruzadas oportunas, no debe ser redundante y los requerimientos deben expresarse individualmente y no de forma conjunta. También se considera la necesidad de mantener las distintas versiones de la especificación que se vayan produciendo debido a los cambios, es decir, que la especificación sea configurable.
• Rastreable: Una especificación de requerimientos es rastreable sí y sólo sí para cada requerimiento contenido en ella se conoce y puede referenciarse como origen en posteriores documentos durante el desarrollo, es decir, cada requerimiento puede rastrearse hacia atrás y hacia adelante. Una condición necesaria para que un requerimiento pueda rastrearse hacia adelante es que pueda referenciarse de manera única, normalmente mediante algún tipo de código.
• Anotada con importancia y estabilidad: Para ello, cada requerimiento está anotado con la importancia que tiene su cumplimiento para clientes y usuarios y la estabilidad que se espera del requerimiento, es decir, la probabilidad de que cambie durante el desarrollo. Esto permite en que orden implementarlos en el caso de que se haya acordado entregar versiones sucesivas del producto. Por otro lado, la estabilidad permite a los diseñadores conocer qué grado de flexibilidad deben introducir en el sistema para soportar futuros cambios.
• Independiente del diseño y la implementación: Una especificación de requerimientos es independiente del diseño y de la implementación sí y sólo sí no especifica una determinada descomposición del sistema (arquitectura) ni ningún aspecto de su posible implementación. Sólo deben admitirse requerimientos que limiten la libertad de los diseñadores y programadores en el caso de que el cliente lo solicite explícitamente.

Dimensiones de los Requerimientos

Los calificativos que se aplican al término requerimiento muestran distintos aspectos ortogonales. Además, realiza un esfuerzo por agrupar dichos calificativos en tres dimensiones:

• Ámbito: Esta dimensión indica en qué ámbito se debe entender el requerimiento. En general, un ámbito de sistema indica que el requerimiento debe cumplirse a nivel sistema, entendiendo por sistema un conjunto de herdware y software.
• Característica: Esta dimensión clasifica los requerimientos en función de la naturaleza de la característica del sistema deseado que se especifica. Tal clasificación es:
1) Requerimientos funcionales.
2) Requerimientos de información: qué información debe almacenar el sistema por ser relevante para las necesidades y objetivos de clientes y usuarios.
3) Requerimientos no funcionales.
• Audiencia: Esta dimensión indica la audiencia a la que está dirigido el requerimiento, es decir, las personas que deben ser capaces de entenderlo. Se tienen dos tipos de audiencia:
1) Los clientes y usuarios, que no tienen porqué tener formación en ingeniería de software (especificación de requerimientos mediante lenguaje natural): requerimientos-C.
2) Los desarrolladores de software (especificación de requerimientos utilizando técnicas estructuradas, orientadas a objetos o formales): requerimientos-D.

¿Quién dijo que era fácil?

No tengo duda de que la carrera de desarrollo de software no es fácil: El camino tiene muchos obstáculos y más importante que las habilidades del equipo de desarrollo está en centrar la importancia del desarrollo en la comunicación con los stakeholders, pues ellos son la base para el éxito del desarrollo de todo el producto.

De modo que me permitiré citar un párrafo de F. P. Brooks:

La parte más difícil de construir un sistema de software es decidir qué construir. Ninguna otra parte del trabajo afecta más negativamente al sistema final si se realiza de manera incorrecta. Ninguna otra parte es más difícil de rectificar después.

Recuerdo haber escuchado la siguiente frase: "Técnica del carpintero: Medir dos veces, cortar una vez". Y esto viene a mi mente para enfatizar lo siguiente: Definir una línea base de requerimientos y examinarla con toda la gente involucrada en el desarrollo hasta que se comprenda cada requerimiento. Una vez comprendida toda la línea base de requerimientos comenzar a construir el producto. No construya si no se tiene una línea base de requerimientos definida y comprendida.

El presente post está por supuesto sujeto a debate. Gracias por sus visitas y comentarios.

Mejores Prácticas en la Gestión de Requerimientos

• Priorizar los requerimientos: Para determinar aquellos que se deberían cumplir en la primera versión o producto y aquellos que pueden llevarse a cabo en sucesivas versiones.
• Establecer líneas base de los requerimientos: Para asegurar que cualquier modificación en los requerimientos que cambie la línea base se trata como cambios de alcance.
• Comunicación abierta: Para asegurar que la información relacionada con los requerimientos se comunica de forma consistente. Una comunicación abierta también implica comunicar a la gente correcta y al conjunto mínimo de personas.
• Gestión de cambios de los requerimientos: Es esencial gestionar estos cambios de forma efectiva y eficiente.
• Uso de herramientas para la gestión de requerimientos: Para facilitar la gestión de los requerimientos.
• Mantener trazabilidad de los requerimientos: Para llevar un seguimiento de la vida de un requerimiento.
• Establecer un plan de mejora de procesos para la ingeniería de requerimientos: Para cumplir con las necesidades actuales y futuras de forma más eficiente y con mayor calidad.
• Formar a los analistas de requerimientos: Para asegurar que los analistas de requerimientos tienen el conocimiento, entre otros aspectos, de cómo escribir buenos requerimientos, etc.

Mejores Prácticas en el Desarrollo de Requerimientos

A continuación se describen una serie de mejores prácticas orientadas al desarrollo de requerimientos:

• Documentar el alcance y visión del proyecto: Permitirá tener un mejor entendimiento de los requerimientos y asegurará que todas las personas involucradas en el proyecto trabajen hacia la misma meta.
• Mantener un glosario del proyecto: Facilitará una comunicación efectiva asegurando un entendimiento unánime.
• Uso de técnicas de obtención de requerimientos de usuario: Para facilitar esta tarea.
• Involucrar a toda la gente implicada: Asegura una validación temprana del entendimiento de los requerimientos.
• Desarrollo incremental de requerimientos: Puede minimizar la cantidad de re-trabajo del proyecto.
• Captura de requerimientos usando casos de uso: Será más fácil gestionar los requerimientos y hacer un seguimiento en los mismos.
• Validar los requerimientos: Para mejorar el éxito de los proyectos es crítico que se validen los requerimientos de forma adecuada.
• Verificar los requerimientos: Para asegurar que los requerimientos proporcionan una base adecuada para llevar a cabo el diseño, la construcción y las pruebas.

La Trazabilidad en los Requerimientos

Un concepto clave en el proceso de gestión de cambios es la Trazabilidad. Los requerimientos deben ser trazables, es decir, "rastreables". Se podría decir que un requerimiento es trazable si se pueden identificar todas las partes del producto existente relacionadas con ese requerimiento. Todos los requerimientos deberían ser trazables para mantener consistencia entre los distintos documentos de un proyecto.

Es importante conocer aspectos de los requerimientos tales como:

• Su origen (quién lo propueso).
• Necesidad (por qué existe).
• Relación con otros requerimientos (Dependencias).
• Relación con otros elementos (Dependencias).

La siguiente matriz se utiliza para relacionar requerimientos. Es una matriz de dependencias:

		Requerimientos (A)
		Req. 1	Req. 2	Req. 3	Req. 4	Req. 5	Req. 6	Req. 7	Req. 8
Requerimientos (B)	Req. 1		X			X			X
	Req. 2							X
	Req. 3					X	X
	Req. 4								X
	Req. 5	X
	Req. 6		X
	Req. 7					X
	Req. 8		X

En este caso los Requerimientos (A) representan los requerimientos que originan las dependencias y los Requerimientos (B) serían los requerimientos que dependen de otros requerimientos, de los Requerimientos (A).

Por ejemplo, se puede ver como los requerimientos 1, 2 y 7 dependen del requerimiento 5, o que el requerimiento 3, además de depender del requerimiento 5 también depende del requerimiento 6. De esta forma se puede ver de qué manera se relacionan los requerimientos para analizar mejor el impacto de los cambios.

Gestión de los Requerimientos

La gestión de requerimientos es el conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requerimientos y sus cambios en cualquier momento. Es decir, la gestión de requerimientos consiste en gestionar los cambios de los requerimientos, las relaciones entre ellos, las dependencias entre la especificación de requerimientos y otros documentos producidos por el proceso de desarrollo de software. De esta forma se asegura la consistencia entre los requerimientos y el sistema construido.

Por los tanto, los objetivos principales del proceso de gestión de requerimientos serán:

• Gestionar el levantamiento de requerimientos.
• Obtener la aprobación de los participantes involucrados en el proyecto.
• Gestionar los cambios (trazabilidad)

La gestión de requerimientos es un proceso que se desarrolla a lo largo de toda la vida del producto.

Los requerimientos cambian durante todo el ciclo de vida de desarrollo del producto. Los cambios deben controlarse y documentarse, es decir, hay que convivir con ellos y por ello la gestión de cambios es esencial para tratar dichos cambios.

Cuando, durante el proyecto y una vez aceptada la línea de base de requerimientos, se solicita un cambio sobre esta línea base, estos cambios no se pueden aceptar sin más ya que podrían afectar al desarrollo de todo el sistema, o alguna parte esencial del mismo.

El siguiente gráfico muestra el proceso de gestión de cambios con las actividades a llevar a cabo durante el desarrollo del mismo:

En definitiva, podríamos destacar tres importantes actividades dentro del proceso de gestión de cambios:

1. Evaluar el Impacto.

La primera tarea a realizar tras recibir una petición de cambio es valorar el impacto del mismo. Para ello se deberá ir recorriendo todo el árbol de requerimientos viendo como les afecta el cambio, y aquí es donde entra la trazabilidad de los requerimientos.

2. Aceptación del Cambio.

Una vez analizado el impacto del cambio, se debe tomar una decisión. Si se acepta el cambio tras negociarlo con el cliente, se continuará con la actividad de implementar el cambio. En caso contrario, se deberá negociar con el cliente el siguiente paso a realizar.

3. Implementación del Cambio.

Si se ha aceptado el cambio, hay que reflejar ese cambio en todos los productos que resulten afectados por dicho cambio (si el cambio es mínimo algunos productos como el plan del proyecto, puede que no sea necesario modificar). Además se deberá generar un nuevo punto de partida (línea base) de requerimientos.

Revisión de Especificación de Requerimientos

Cuando un requerimiento pasa por una puerta de calidad, se puede tener confianza acerca de la corrección y viabilidad de los requisitos. ¿Pero qué ocurre con la especificación en conjunto? En este punto se sabe que los requerimientos son correctos, pero ¿se puede asegurar que todos estos requerimientos, en conjunto, describen la "historia" completa?

El término especificación de requerimientos hace referencia a la colección de requerimientos especificados y definidos previamente. La especificación no tiene que estar en un determinado formato, puede ser una especificación sobre papel, o un blog, o algo similar.

Una vez que la especificación de los requerimientos está completa se tendrá un conocimiento preciso del alcance y funcionalidad del producto. Este es el momento de llevar a cabo la revisión de la especificación. En esta revisión final se valida que no falta ningún requerimiento.

Otro punto muy importante a tener en cuenta es asegurarse de que los requisitos tengan consistencia, y en caso contrario, que cualquier conflicto entre los requerimientos ha sido resuelto. Dos requerimientos están en conflicto si no pueden implementarse juntos, es decir, si la solución a un requerimiento impide la implementación de otro.

Cuando las expectativas del cliente son altas, la fecha de entrega y los recursos son limitados, es importante asegurarse de que las funciones más importantes del producto sean entregadas y además tan pronto como sea posible. Otro problema que se puede plantear es que haya demasiados requerimientos.

La solución a los problemas anteriores es la priorización de los requerimientos.

Verificación de los Requerimientos

En esta fase, el usuario final añade criterios de aceptación para cada requisito. Además, apoya el hecho de que los requerimientos han de ser correctos antes de que sean entregados a los diseñadores y desarrolladores.

La puerta de calidad es un punto por el que pasan cada uno de los requerimientos antes de formar parte de la especificación.

Una de las tareas de las puertas de calidad es asegurarse de que cada requerimiento cumple con el criterio que tiene asignado. Este criterio es una medida del requisito que le hace entendible y con capacidad para ser probado.

Otra razón por la que el proyecto tiene puertas de calidad es para prevenir posibles fugas de requerimientos. Los requerimientos, algunas veces, aparecen en las especificaciones sin que nadie realmente sepa de dónde vienen y qué valor añaden al producto. Asegurándose de que la única forma de que los requerimientos entren a formar parte de las especificaciones sea a través de las puertas de calidad, el equipo del proyecto tiene un total control de los requerimientos.

Definición de Requerimientos - Buenas Prácticas

• Los requerimientos son escritos de una forma tecnológicamente neutra, es decir, especifican lo que el producto hace y no qué tecnología se usará para crearlo.
• Su especificación NO debe ser ambigua.
• Eliminar todos los pronombres de la especificación de requerimientos, sustituyéndolos por los sujetos.
• Tener cuidado con adjetivos y adverbios ya que pueden llevar a confusiones.
• Se debe evitar usar palabrasque lleven a confusión al escribir los requerimientos, cómo "debería", ya que da a entender que el requisito es opcional.
• Al escribir los requerimientos una buena técnica es leerlos en voz alta. Y si es posible, pedir a alguien que los lea.
• Confirmar que los involucrados en el negocio tienen el mismo entendimiento acerca de los requerimientos que la persona que los escribe.
• Utilizar una convención de nombres y definiciones comunes dentro de la organización. De esta forma se aseguran que en todos los proyectos se está usando el mismo vocabulario.

Definiendo los Requerimientos

Conseguir que los requerimientos estén claramente definidos puede ser difícil. Para ello es importante:

• Definir los requerimientos teniendo en cuenta la perspectiva del cliente/usuario.
• Reutilizar requerimientos, revisando proyectos ya finalizados para ver si contienen material potencialmente reutilizable. La ventaja de esta reusabilidad es que, una vez que un requerimiento ha sido especificado satisfactoriamente para un producto y que el producto ha tenido éxito, el requerimiento no tendrá que volverse a inventar, podrá ser utilizado las veces que se desee.
• Documentas los requerimientos de la forma correcta. Aunque escribir los requerimientos puede parecer una tarea tediosa, es la única manera de asegurar que la esencia de los requerimientos ha sido capturada correctamente y que esto pueda ser aprobado.

Un mal uso del lenguaje puede llevar a un mal entendimiento, horas de trabajo perdido, una mala comunicación entre miembros del equipo, y en definitiva una especificación de requerimientos de poca calidad.

Necesidad de la Ingeniería de Software

• Para construir algo, antes hay que entender qué es ese "algo".
• Si la aplicación funciona, pero no satisface las necesidades del cliente... ¿de que sirve?
• En general, los requerimientos expresan qué debe hacer una aplicación, sin decir cómo debe hacerlo: expresan el punto de vista del cliente, que sabe lo que quiere (en el mejor de los casos), pero no tiene por qué saber cómo conseguirlo:
• A menudo el cliente ni siquiera sabe lo que quiere.
• La tarea del analista es ayudar a que el cliente se exprese.

Qué es la ingeniería de requerimientos

• Es la rama de la ingeniería de software que se ocupa de la primera etapa en el proceso de desarrollo del software: la comprensión y formalización de las necesidades que debe satisfacer un sistema informático.
• "Es el desarrollo sistemático de los requisitos a través de un proceso iterativo y cooperativo en el que se analiza el problema, se documenta el resultado en diversos formatos de representación, y se comprueba la exactitud de la comprensión alcanzada" (Locopaulos & Karakostas. Systems Requirements Engineering. McGraw-Hill, 1995).
• Se pueden distinguir dos fases en el proceso:
  1. Captura: interacción cuidadosa con todos aquellos interesados en la aplicación o sistema informático; adquisición de información, "requisitos en bruto".
  2. Análisis: estudio cuidadoso de la información adquirida para lograr una verdadera comprensión de los requisitos y estructurarlos adecuadamente; expresar los requisitos de forma concreta y detallada; refinamiento, depuración, estructuración, "requisitos depurados".
• Obtener los requisitos correctos es un proceso difícil:
  Adivinar los deseos y necesidades que habitualmente el cliente no es capaz de describir más que en forma confusa, incompleta y desordenada.
  Los requisitos no se descubren, se inventan; los requisitos no están ahí esperando que alguien los descubra, sino que son creados, construidos o inventados en un proceso interactivo entre el cliente y el ingeniero.
  La mayor parte de los defectos en el software entregado tienen su origen en el análisis de requisitos, y son en general los más difíciles de reparar.
  El éxito en el producto requiere colaboración y comunicación fluida entre clientes y desarrolladores: cuanto más completo y menos ambiguo sea el conjunto de requisitos, más probabilidades de éxito.
• El resultado del proceso es el "documento de requisitos", que es uno de los productos (o artefactos del proceso de desarrollo de software: modelos de diseño, código fuente, pruebas, manuales...