7.

1 ■ Estudios de viabilidad

1

Procesos de la ingeniería requerimientos La meta del proceso de ingeniería de requerimientos es crear y mantener un documento de requerimientos del sistema. El proceso general corresponde cuatro subprocesos de alto nivel de la ingeniería de requerimientos. Éstos tratan de la evaluación de si el sistema es útil para el negocio (estudio de viabilidad); el descubrimiento de requerimientos (obtención y análisis); la transformación de estos requerimientos en formularios estándar (especificación), y la verificación de que los requerimientos realmente definen el sistema que quiere el cliente (validación).

Documento de requerimient Algunas personas consideran a la ingeniería de requerimientos como el proceso de aplicar un método de análisis estructurado, como el análisis orientado a objetos (Larman, 2002). Éste comprende analizar el sistema y desarrollar un conjunto de modelos gráficos del mismo, como los modelos de casos de uso. Que sirven como una especificación del sistema. El conjunto de modelos describe el comportamiento del sistema al cual se le agregan notas con información adicional que detallan, por ejemplo, el rendimiento o fiabilidad requeridos.

7.1 ■ Estudios de viabilidad

2

7.1 Estudios de viabilidad Para todos los sistemas nuevos, el proceso de ingeniería de requerimientos debería empezar con un estudio de viabilidad. La entrada de éste es un conjunto de requerimientos de negocio preliminares, una descripción resumida del sistema y de cómo éste pretende contribuir a los procesos del negocio. Los resultados del estudio de viabilidad deberían ser un informe que recomiende si merece o no la pena seguir con la ingeniería de requerimientos y el proceso de desarrollo del sistema. Un estudio de viabilidad es un estudio corto y orientado a resolver varias cuestiones: 1. ¿Contribuye el sistema a los objetivos generales de la organización? 2. ¿Se puede implementar el sistema utilizando la tecnología actual y dentro de las restricciones de coste y tiempo? 3. ¿Puede integrarse el sistema con otros sistemas existentes en la organización? En un estudio de viabilidad, se pueden consultar las fuentes de información, como los jefes de los departamentos donde se utilizará el sistema, los ingenieros de software que están familiarizados con el tipo de sistema propuesto, los expertos en tecnología y los usuarios finales del sistema. Normalmente, se debería intentar completar un estudio de viabilidad en dos o tres semanas. Una vez que se tiene la información, se redacta el informe del estudio de viabilidad. Debería hacerse una recomendación sobre si debe continuar o no el desarrollo del sistema. En el informe, se pueden proponer cambios en el alcance, el presupuesto y la confección de agendas del sistema y sugerir requerimientos adicionales de alto nivel para éste. 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. 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.

7.1 ■ Estudios de viabilidad

3

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 influencia 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. Se puede pensar en estas actividades dentro de una espiral de forma que las actividades se entrelazan a medida que el proceso avanza desde el anillo interior a los exteriores de la espiral. Las actividades del proceso son: 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.

7.1 ■ Estudios de viabilidad

4

7.2.1 Descubrimiento de requerimientos El descubrimiento de requerimientos es el proceso de recoger información sobre el sistema propuesto y los existentes y extraer los requerimientos del usuario y del sistema de esta información. Las fuentes de información durante la fase del descubrimiento de requerimientos incluyen la documentación, los stakeholders del sistema y la especificación de sistemas similares. Usted se relaciona con los stakeholders a través de entrevistas y de la observación, y puede utilizar escenarios y prototipos para ayudar al descubrimiento de requerimientos. En esta sección, se analiza un enfoque que ayuda a asegurar a que consiga una amplia cobertura de stakeholders al descubrir requerimientos, y se describen técnicas de descubrimiento de requerimientos entre las que se incluyen entrevistas, escenarios y etnografía. Estas fuentes de requerimientos (stakeholders, dominio, sistemas) se pueden representar como puntos de vista del sistema, donde cada uno presenta un subconjunto de requerimientos para el sistema. Cada punto de vista proporciona una perspectiva nueva en el sistema, pero éstas no son completamente independientes. Por lo general coinciden parcialmente, por lo que tienen requerimientos comunes. Puntos de vista Los puntos de vista se pueden utilizar como una forma de clasificar los stakeholders y otras fuentes de requerimientos. Existen tres tipos genéricos de puntos de vista: 1. Puntos de vista de los interactuadotes: representan a las personas u otros sistemas que interactúan directamente con el sistema. En el sistema del ATM del banco, son ejemplos de estos puntos de vista los clientes del banco y la base de datos de las cuentas bancarias. 2. Puntos de vista indirectos: representan a los stakeholders que no utilizan el sistema ellos mismos pero que influyen en los requerimientos de algún modo. En el sistema del ATM del banco, son ejemplos de puntos de vista indirectos la gerencia del banco y el personal de seguridad. 3. Puntos de vista del dominio: representan las características y restricciones del dominio que influyen en los requerimientos del sistema. En el sistema del ATM del banco, un ejemplo de un punto de vista del dominio serían los estándares que se han desarrollado para las comunicaciones interbancarias.

7.2 ■ Obtención y análisis de requerimientos

5

Entrevistas Las entrevistas formales o informales con los stakeholders del sistema son parte de la mayoría de los procesos de la ingeniería de requerimientos. En estas entrevistas, el equipo de la ingeniería de requerimientos hace preguntas a los stakeholders sobre el sistema que utilizan y sobre el sistema a desarrollar. Los requerimientos provienen de las respuestas a estas preguntas. Las entrevistas pueden ser de dos tipos: 1. Entrevistas cerradas donde los stakeholders responden a un conjunto predefinido de preguntas 2. Entrevistas abiertas donde no hay un programa predefinido. El equipo de la ingeniería de requerimientos examina una seria de cuestiones con los stakeholders del sistema y, por lo tanto, desarrolla una mejor comprensión de sus necesidades. Es difícil obtener conocimiento del dominio durante las entrevistas debido a dos razones: 1. Todos los especialistas de la aplicación utilizan terminología y jerga específica de un dominio. Es imposible para ellos discutir requerimientos del dominio sin utilizar esta terminología. Normalmente la utilizan de un modo preciso y sutil, por lo que es fácil que la malinterpreten los ingenieros de requerimientos. 2. Cierto conocimiento del dominio es tan familiar para los stakeholders que o lo encuentran difícil de explicar o piensan que es tan básico que no merece la pena mencionarlo. Por ejemplo, para un bibliotecario, es evidente que todas las adquisiciones se catalogan antes de agregarlas a la biblioteca. Sin embargo, esto puede no ser obvio para el entrevistador por lo que no se tiene en cuenta en los requerimientos. Escenarios Normalmente, las personas encuentran más fácil dar ejemplos de la vida real que descripciones abstractas. Pueden comprender y criticar un escenario de cómo podrían interactuar con un sistema software. Los ingenieros de requerimientos pueden utilizar la información obtenida de esta discusión para formular los requerimientos reales del sistema. El escenario comienza con un esbozo de la interacción y, durante la obtención, se agregan detalles para crear una descripción completa de esta interacción. De forma general, un escenario puede incluir: 1.Una descripción de lo que esperan el sistema y los usuarios cuando el escenario comienza. 2.Una descripción del flujo normal de eventos en el escenario. 3.Una descripción de lo que puede ir mal y cómo manejarlo. 4.Información de otras actividades que se podrían llevar a cabo al mismo tiempo. 5.Una descripción del estado del sistema cuando el escenario termina.

7.2 ■ Obtención y análisis de requerimientos

6

Casos de uso Los casos de uso son una técnica que se basa en escenarios para la obtención de requerimientos que se introdujeron por primera vez en el método Objetory. Actualmente se han convertido en una característica fundamental de la notación de UML, que se utiliza para describir modelos de sistemas orientados a objetos. En su forma más simple, un caso de uso identifica el tipo de interacción y los actores involucrados. Los casos de uso identifican las interacciones particulares con el sistema. Pueden ser documentadas con texto o vinculadas a modelos UML que desarrollan el escenario en más detalle. Los diagramas de secuencia (introducidos en el Capítulo 6) se utilizan a menudo para añadir información a un caso de uso. Éstos muestran los actores involucrados en la interacción, los objetos con los que interactúan y las operaciones asociadas con estos objetos. 7.2.2 Etnografía

Los sistemas software no existen de forma aislada, se utilizan en un contexto social y organizacional, y los requerimientos de sistemas software se pueden derivar y restringir según ese contexto. A menudo, satisfacer estos requerimientos sociales y organizacionales es crítico para el éxito del sistema. Una razón de por qué muchos sistemas software se entregan pero nunca se utilizan es que no se tiene en cuenta adecuadamente la importancia de este tipo de requerimientos del sistema. 7.3 Validación de requerimientos La validación de requerimientos trata de mostrar que éstos realmente definen el sistema que el cliente desea. Coincide parcialmente con el análisis ya que éste implica encontrar problemas con los requerimientos. La validación de requerimientos es importante debido a que los errores en el documento de requerimientos pueden conducir a importantes costes al repetir el trabajo cuando son descubiertos durante el desarrollo o después de que el sistema esté en uso 1.Verificaciones de validez. Un usuario puede pensar que se necesita un sistema para llevar a cabo ciertas funciones. Sin embargo, el razonamiento y el análisis pueden identificar que se requieren funciones adicionales o diferentes. 2.Verificaciones de consistencia. Los requerimientos en el documento no deben contradecirse. Esto es, no debe haber restricciones o descripciones contradictorias de la misma función del sistema. 3.Verificaciones de completitud. El documento de requerimientos debe incluir requerimientos que definan todas las funciones y restricciones propuestas por el usuario del sistema. 4.Verificaciones de realismo. Utilizando el conocimiento de la tecnología existente, los requerimientos deben verificarse para asegurar que se pueden implementar. Estas verificaciones también deben tener en cuenta el presupuesto y la confección de agendas para el desarrollo del sistema. 5.Verificabilidad. Para reducir la posibilidad de discusiones entre el cliente y el contratista, los requerimientos del sistema siempre deben redactarse de tal forma que sean verificables. Esto significa que debe poder escribir un conjunto de pruebas que demuestren que el sistema a entregar cumple cada uno de los requerimientos especificados.

7.2 ■ Obtención y análisis de requerimientos

7

7.3.1

Revisiones de requerimientos

Una revisión de requerimientos es un proceso manual que involucra a personas tanto de la organización del cliente como de la del contratista. Ellos verifican el documento de requerimientos en cuanto a anomalías y omisiones. El proceso de revisión se puede gestionar de la misma forma que las inspecciones de programas Los revisores también pueden comprobar la: 1.Verificabilidad. ¿Puede probarse el requerimiento de modo realista? 2.Comprensibilidad. ¿Las personas que adquieren el sistema o los usuarios finales comprenden correctamente el requerimiento? 3.Rastreabilidad. ¿Está claramente establecido el origen del requerimiento? Puede tener que volver a la fuente del requerimiento para evaluar el impacto del cambio. La rastreabilidad es importante ya que permite evaluar el impacto del cambio en el resto del sistema. Se trata esto con mayor detalle en la siguiente sección. 4.Adaptabilidad. ¿Es adaptable el requerimiento? Es decir, ¿puede cambiarse el requerimiento sin causar efectos de gran escala en los otros requerimientos del sistema? Los conflictos, contradicciones, errores y omisiones en los requerimientos deben ser señalados por los revisores y registrarse formalmente en el informe de revisión. Queda en los usuarios, la persona que adquiere el sistema y el desarrollador de éste negociar una solución para estos problemas identificados. 7.4 Gestión de requerimientos Los requerimientos para sistemas software grandes son siempre cambiantes. Una razón es que estos sistemas normalmente se desarrollan para abordar problemas. Debido a que el problema no puede definirse completamente, es muy probable que los requerimientos del software sean incompletos. Durante el proceso del software, la comprensión del problema por parte de los stakeholders está cambiando constantemente. Estos requerimientos deben entonces evolucionar para reflejar esta perspectiva cambiante del problema. 7.4.1 Requerimientos duraderos y volátiles

La evolución de los requerimientos durante el proceso de ingeniería de requerimientos y después de que un sistema esté en uso es inevitable. El desarrollo de requerimientos software centra su atención en las capacidades de éste, los objetivos del negocio y otros sistemas de la organización. Conforme se va desarrollando la definición de los requerimientos, normalmente tiene una mejor comprensión de las necesidades de los usuarios. 1. Requerimientos duraderos. Son requerimientos relativamente estables que se derivan de la actividad principal de la organización y que están relacionados directamente con el dominio del sistema. Por ejemplo, en un hospital siempre habrá requerimientos que se

7.2 ■ Obtención y análisis de requerimientos

8

refieren a los pacientes, médicos, enfermeras y tratamientos. Estos requerimientos se pueden derivar de los modelos del dominio que muestran las entidades y relaciones que caracterizan un dominio de aplicación 2. Requerimientos volátiles. Son requerimientos que probablemente cambian durante el proceso de desarrollo del sistema o después de que éste se haya puesto en funcionamiento. Un ejemplo serían los requerimientos resultantes de las políticas gubernamentales sobre sanidad. 7.4.2 Planificación de la gestión de requerimientos

La planificación es una primera etapa esencial del proceso de gestión de requerimientos. La gestión de requerimientos tiene un coste elevado. Para cada proyecto, la etapa de planificación establece el nivel de detalle necesario en la gestión de requerimientos. Durante la etapa de gestión de requerimientos, habrá que decidir sobre: 1. La identificación de requerimientos. Cada requerimiento se debe identificar de forma única de tal forma que puedan ser remitidos por otros requerimientos de manera que pueda utilizarse en las evaluaciones de rastreo. 2. Un proceso de gestión del cambio. Éste es el conjunto de actividades que evalúan el impacto y coste de los cambios. 3. Políticas de rastreo. Estas políticas definen las relaciones entre los requerimientos, y entre éstos y el diseño del sistema que se debe registrar y la manera en que estos registros se deben mantener. 4. Ayuda de herramientas CASE. La gestión de requerimientos comprende el procesamiento de grandes cantidades de información sobre los requerimientos. Las herramientas que se pueden utilizar van desde sistemas de gestión de requerimientos especializados hasta hojas de cálculo y sistemas sencillos de bases de datos.

7.4.3 Gestión del cambio de los requerimientos La gestión del cambio de los requerimientos se debe aplicar a todos los cambios propuestos en los requerimientos. La ventaja de utilizar un proceso formal para gestionar el cambio es que todos los cambios propuestos son tratados de forma consistente y que los cambios en el documento de requerimientos se hacen de forma controlada. Existen tres etapas principales en un proceso de gestión de cambio:

7.2 ■ Obtención y análisis de requerimientos

9

1. Análisis del problema y especificación del cambio. El proceso empieza con la identificación de un problema en los requerimientos o, algunas veces, con una propuesta de cambio específica. Durante esta etapa, el problema o la propuesta de cambio se analiza para verificar que ésta es válida. Los resultados del análisis se pasan al solicitante del cambio, y algunas veces se hace una propuesta de cambio de requerimientos más específica. 2. Análisis del cambio y cálculo de costes. El efecto de un cambio propuesto se valora utilizando la información de rastreo y el conocimiento general de los requerimientos del sistema. El coste de hacer un cambio se estima en términos de modificaciones al documento de requerimientos y, si es apropiado, al diseño e implementación del sistema. Una vez que este análisis se completa, se toma una decisión sobre si se continúa con el cambio de requerimientos. 3. Implementación del cambio. Se modifica el documento de requerimientos y, en su caso, el diseño e implementación del sistema. Debe organizar el documento de requerimientos de modo que pueda hacer cambios en él sin tener que hacer grandes reorganizaciones o redactar nuevamente gran cantidad del mismo. Como sucede con los programas, los cambios en los documentos se llevan a cabo minimizando las referencias externas y haciendo las secciones del documento tan modulares como sea posible. De esta manera, se pueden cambiar y reemplazar secciones individuales sin afectar a otras partes del documento.

EJERCICIOS 7.1Mencione quiénes podrían ser los stakeholders en un sistema de registro de estudiantes universitarios. Explique por qué es casi inevitable que los requerimientos de diferentes stakeholders entren en conflicto de alguna forma. 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. Inevitablemente, cuando existen muchos stakeholders involucrados, los requerimientos entrarán en conflicto

7.2Un sistema software se desarrolla para gestionar los registros de los pacientes que ingresan en una clínica para tratamiento. Los registros incluyen anotaciones de todos los controles habituales a los pacientes (temperatura, tensión arterial, etc.), los tratamientos dados, las reacciones de los pacientes, etcétera. Después del tratamiento, los registros de su estancia se envían al doctor del paciente, quien mantiene su historial clínico completo. Identifique los puntos de vista principales que se pueden tener en cuenta en la especificación del sistema y organicelos utilizando un diagrama de jerarquía de puntos de vista.

7.2 ■ Obtención y análisis de requerimientos

10

7.3Para tres de los puntos de vista identificados en el sistema de biblioteca, LIBSYS (Figura 7.4), mencione tres requerimientos que podrían ser sugeridos por los stakeholders relacionados con ese punto de vista. • Habrá un sistema de catálogos donde se puedan encontrar diferentes tipos de libros • Habrá una base de datos donde se pueda encontrar a cualquier paciente en su respectiva habitación • Se incorporara un sistema para hacer el llamado cuando sea necesario al proveedor de artículos 7.4El sistema LIBSYS tiene que incluir soporte para la catalogación de nuevos documentos donde el catálogo del sistema puede ser distribuido a través de varias máquinas. ¿Cuáles son probablemente los tipos más importantes de requerimientos no funcionales relacionados con los servicios de catalogación? Requerimientos de usabilidad Requerimientos de implementación Requerimientos de estándares Requerimientos de interoperabilidad Requerimientos de seguridad 7.5Utilizando su conocimiento de cómo funciona un cajero automático de un banco, desarrolle un conjunto de casos de uso que podrían servir como una base para entender los requerimientos de un sistema de un cajero automático.

7.2 ■ Obtención y análisis de requerimientos

11

7.6Dé un ejemplo de un tipo de sistema en el que los factores sociales y políticos pueden influir fuertemente en los requerimientos del sistema. Explique por qué estos factores son importantes en el ejemplo. 7.7¿Quiénes deberían estar implicados en la revisión de requerimientos? Establezca un modelo deí proceso que muestre cómo se puede organizar una revisión de requerimientos. 7.8¿Por qué las matrices de rastreo son difíciles de manejar cuando existen muchos requerimientos en el sistema? Diseñe un mecanismo de estructuración de requerimientos, basado en puntos de vista, que pueda ayudar a reducir el tamaño del problema. 7.9Cuando se hacen cambios de emergencia en los sistemas, el sistema software puede tener que modificarse antes de que los cambios en los requerimientos se aprueben. Sugiera un modelo de proceso para hacer estas modificaciones que asegure que el documento de requerimientos y la Implementación del sistema no sean incompatibles. 7.10 Su compañía utiliza un método de análisis estándar que normalmente se aplica en todos los análisis de requerimientos. En su trabajo, comprueba que este método no puede representar factores sociales que son significativos en el sistema que usted analiza. Le señala esto a su jefe, quien le indica claramente que el estándar debe seguirse. Mencione qué debe hacer en tal situación