PSICOLOGIA

La Ingeniería de requisitos o Ingeniería de requerimientos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:

• La educción (a veces llamada "elicitación", debido a una mala traducción de "elicitation") de los requisitos de usuario.

• El análisis y negociación de requisitos para derivar requisitos adicionales.

• La documentación de los requisitos como especificación.

• La validación de los requisitos documentados contra las necesidades de usuario.

• Así como los procesos que apoyan estas actividades.

La Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.

INGENIERIA DE REQUERIMIENTOS / INGENIERIA DE REQUISITOS (PAG. 155)

La comprensión de los requisitos de un problema esta entre las tareas más difíciles que enfrenta un ingeniero de software. Cuando se piensa por primera vez acerca de ello, la ingeniería de requisitos no parece tan difícil. Después de todo, ¿El cliente no sabe lo que se requiere? ¿Los usuarios finales no deberían entender bien las características y funciones que les proporcionaran un beneficio? Es sorprendente, pero en muchas ocasiones la respuesta a estas preguntas es: “no”. Y aun asi los clientes y usuarios finales son explícitos en sus necesidades, estos requisitos pueden cambiar durante el proyecto. La ingeniería de requisitos es difícil.

Imaginemos el siguiente escenario que describió Ralph Young:

Un cliente entra en tu oficina, se sienta, te mira directo a los ojos, y dice: “Yo sé que usted piensa que entiende lo que digo, pero lo que usted no entiende es que lo que digo no es realmente lo que quiero decir”. Esto sucede de manera invariable cuando el proyecto está avanzado, después de que se han realizado los compromisos relativos al tiempo de entrega, las reputaciones están en juego y el dinero está en serio peligro.

Resumen

¿Qué es?

La ingeniería de requerimientos representa una ayuda para los ingenieros de software, ya que les ayuda a entender mejor el problema en cuya solución trabajaran. Incluye un conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, que es lo que el cliente quiere y como interactuaran los usuarios finales con el software.

La ingeniería de requisitos, como todas las demás actividades de la ingeniería del software, debe adaptarse a las necesidades del proceso, el proyecto, el producto y las personas que realizan el trabajo. Desde la perspectiva del proceso del software que comienza durante la actividad de comunicación y continúa en la actividad de modelado.

En algunos casos se elige un enfoque abreviado. En otros, cada una de las tareas definidas para comprender los requisitos se debe llevar a cabo de manera rigurosa. Sobre todo, el equipo de software haga un esfuerzo real por entender los requisitos de un problema antes de intentar resolverlo.

Podríamos decir que la ingeniería de requisitos tiende un puente hacia el diseño y la construcción. Pero ¿Dónde se origina el puente? Se puede argumentar que comienza al pie de los participantes del proyecto (es decir, gerentes, clientes, usuarios finales), donde se definen las necesidades del negocio, se describen los escenarios de los usuarios, se delinean las características y funciones, y se identifican las restricciones del proyecto.

¿Quiénes realizan la ingeniería de Requerimientos?

Los ingenieros de software (llamados también ingenieros de sistemas o analistas de sistemas) y otros interesados (gerentes, clientes y usuarios finales) participan en la ingeniería de requisitos.

¿Por qué es importante?

La ingeniería de requerimientos resulta importante porque imagina que diseñamos y construimos un elegante software que resuelva el problema incorrecto no satisface las necesidades de nadie. Por lo tanto, es muy importante entender lo que el cliente quiere antes de comenzar a diseñar y construir un sistema basado en computadora.

¿Cuáles son los pasos?

La ingeniería de requisitos empieza con la fase de inicio, la cual es una tarea que define el ámbito y la naturaleza del problema que debe resolverse. Después continua con la obtención, que es una tarea que ayuda al cliente a definir sus necesidades; posteriormente sigue con la elaboración, que es la fase donde se refinan y modifican los requisitos básicos. Cuando el cliente ha definido el problema se lleva a cabo la negociación, donde se define cuáles son las prioridades, cuales aspectos son esenciales y en qué momento se requieren. Por último, el problema se especifica de alguna manera, y después es validado y revisado para asegurar que la concepción del problema que tiene el ingeniero de software coincide con la percepción del cliente.

¿Cuál es el producto obtenido? El objetivo del proceso de la ingeniería de requisitos es darle a todas las partes una explicación escrita del problema. Esto puede lograrse por medio de varios productos de trabajo: escenarios de uso, listas de funciones y características, modelos de análisis o alguna especificación.

¿Cómo puedo estar seguro de que lo he hecho correctamente? El ingeniero de software revisa los productos de trabajo de la ingeniería de requisitos junto con el cliente y los usuarios finales para asegurarse que haya entendido lo que en realidad pretendían decirle. Es necesario hacer una advertencia: aun después de que todas las partes están de acuerdo, las cosas camnbian, y continuaran haciendo a través de la vida del proyecto.

Obtención y análisis de requerimientos. Es el proceso de obtener los requerimientos del sistema por medio de la observación de los sistemas existentes, discusiones con los usuarios potenciales y proveedores, el análisis de tareas, etcétera. Esto puede implicar el desarrollo de uno o más modelos y prototipos del sistema que ayudan al analista a comprender el sistema a especificar.

7.2 Obtención y análisis de requerimientos

La siguiente etapa del proceso de ingeniería de requerimientos es la obtención y análisis de requerimientos. En esta actividad, los ingenieros de software trabajan con los clientes y los usuarios finales del sistema para determinar el dominio de la aplicación, qué servicios debe proporcionar el sistema, el rendimiento requerido del sistema, las restricciones hardware, etcétera.

La obtención y análisis de requerimientos pueden afectar a varias personas de la organización. El término stakeholder se utiliza para referirse a cualquier persona o grupo que se verá afectado por el sistema, directa o indirectamente. Entre los stakeholders se encuentran los usuarios finales que interactúan con el sistema y todos aquellos en la organización que se pueden ver afectados por su instalación. Otros stakeholders del sistema pueden ser los ingenieros que desarrollan o dan mantenimiento a otros sistemas relacionados, los gerentes del negocio, los expertos en el dominio del sistema y los representantes de los trabajadores.

Obtener y comprender los requerimientos de los stakeholders es difícil por varias razones:

1. Los stakeholders a menudo no conocen lo que desean obtener del sistema informático excepto en términos muy generales; puede resultarles difícil expresar lo que quieren que haga el sistema o pueden hacer demandas irreales debido a que no conocen el coste de sus peticiones.

2. Los stakeholders expresan los requerimientos con sus propios términos de forma natural y con un conocimiento implícito de su propio trabajo. Los ingenieros de requerimientos, sin experiencia en el dominio del cliente, deben comprender estos requerimientos.

3. Diferentes stakeholders tienen requerimientos distintos, que pueden expresar de varias formas. Los ingenieros de requerimientos tienen que considerar todas las fuentes potenciales de requerimientos y descubrir las concordancias y los conflictos.

4. Los factores políticos pueden influir en los requerimientos del sistema. Por ejemplo, los directivos pueden solicitar requerimientos específicos del sistema que incrementarán su inñuencia en la organización.

5. El entorno económico y de negocios en el que se lleva a cabo el análisis es dinámico. Inevitablemente, cambia durante el proceso de análisis. Por lo tanto, la importancia de ciertos requerimientos puede cambiar. Pueden emerger nuevos requerimientos de nuevos stakeholders que no habían sido consultados previamente.

1. Descubrimiento de requerimientos. Es el proceso de interactuar con los stakeholders del sistema para recopilar sus requerimientos. Los requerimientos del dominio de los stakeholders y la documentación también se descubren durante esta actividad.

2. Clasificación y organización de requerimientos. Esta actividad toma la recopilación no estructurada de requerimientos, grupos relacionados de requerimientos y los organiza en grupos coherentes.

3. Ordenación por prioridades y negociación de requerimientos. Inevitablemente, cuando existen muchos stakeholders involucrados, los requerimientos entrarán en conflicto. Esta actividad se refiere a ordenar según las prioridades los requerimientos, y a encontrar y resolver los requerimientos en conflicto a través de la negociación.

4. Documentación de requerimientos. Se documentan los requerimientos y se entra en la

Siguiente vuelta de la espiral. Se pueden producir documentos de requerimientos formales o informales.

...