A continuación se definen los principales conceptos sobre requisitos considerados importantes para la gestión de riesgos.
Ámbito del requisito
Se definen los objetivos a lograr con la gestión de requisitos. Se determinan e instancian los recursos necesarios para poder ejecutar todas las tareas involucradas en esta área de actividad.
Para cada uno de los requisitos debe estar perfectamente definido el ámbito al cual pertenece. Con el concepto de ámbito significamos el entorno en el cual existe, generalmente un módulo o subsistema.
Tipo de requisito
Dentro de las posibles tipificaciones de los requisitos se pueden observar las siguientes
Funcional: Esta tipificación define los requisitos del tipo funcional como aquellos que son directamente asociados a funciones de negocio de la organización y pueden ser asociados a una actividad estratégica.
Técnico: Un requisito técnico es aquel que puede ser descripto en especificaciones detalladas y puede ser asociado a una actividad operativa.
Software: Un requisito de software es aquel que se puede asociar a una unidad de programa del sistema de información.
Hardware: Un requisito de hardware es aquel que se puede asociar a una unidad física del sistema de información.
Comunicaciones: Un requisito de comunicación es el establecimiento de un vínculo entre diversas unidades.
Documentación: requisitos de manuales de usuario y manuales de sistemas. Materiales: Son los requisitos de tipo material, generalmente utilizados como soporte en los demás requisitos.
Humanos: Un requisito del tipo humano hace referencia a los perfiles de los recursos humanos necesarios y suficientes para una determinada actividad.
Datos: Datos que se deben almacenar el sistema dada su importancia para la obtención de información y de conocimiento.
Legales: requisitos relacionados a los cumplimientos legales, ya sea en ámbitos locales, nacionales e internacionales, como en lo referente a la gestión de proveedores, clientes, y recursos humanos.
Operación: objetivos de la operación del sistema analizados desde la óptica del cliente/usuario final.
Definiciones sobre requisitos
Atomicidad: debe comprender un único dominio.
Originador: es la persona o área de la organización, con suficiente nivel de autoridad, que solicita la prestación de un servicio o una actividad dando inicio a la gestión de requisitos.
Destinatario: es la persona o team de sistemas que debe comprender y analizar el requisito e incorporarlo a la gestión de requisitos.
Realizable: cuando es posible la creación de un plan con los tiempos especificados, objetivos definidos y recursos instanciados capaz de responder al mismo.
Responsable de la gestión de requisitos: Se nombra quién será el responsable, ya sea sólo una persona o un grupo de ellas y sus niveles de responsabilidad. Para los niveles de responsabilidad definidos se asignan sus niveles de autoridad dentro del ámbito del proyecto.
Estricta: en el sentido de no permitir ambigüedades en su interpretación, que debe ser definida en el glosario del proyecto.
Completa: si todas las funcionalidades del sistema a desarrollar están incluidas en la especificación, todas las respuestas del sistema a entradas tanto válidas como inválidas están especificadas, todas las especificaciones documentales y unidades de medidas están definidas, todas las referencias externas son comprobables y no hay elementos por definir.
Consistente externamente: si y sólo si todo requisito contenido en ella no está en conflicto con otros documentos de nivel superior.
Consistente internamente: si y sólo si no existen conflictos entre los requisitos que contiene. Los conflictos entre requisitos pueden ser que más de un requisito especifiquen acciones diversas del sistema para las mismas condiciones y eventos producidos, o que un requisito solicite al sistema distintas condiciones y eventos para una determinada acción (especificaciones contradictorias).
Coherente: si el nivel de detalle corresponde al nivel de detalle de la necesidad que dio origen al mismo.
Especificaciones de requisitos
Tipo de especificación: según se exprese en lenguaje natural o en alguna forma técnica.
Especificación verificable: si y sólo si todo el contenido del requisito contenido puede ser definido en unidades mensurables, de manera tal que efectuada las mediciones necesarias se pueda corroborar que el sistema satisface las condiciones de aceptación definidas.
Especificación modificable: si y sólo si los cambios se puedan realizar completa y consistentemente en la forma definida en la gestión de cambios. Cuando un requisito sufre cambios en el tiempo, se deben mantener las distintas versiones del mismo.
Especificación íntegra: detalla todos los ítems que corresponde al requisito cumpliendo con la premisa de que todo aquello que no está específicamente detallado no pertenece al requisito.
Especificación de requisitos independiente del diseño: cuando no se impone una arquitectura lógica determinada. Una especificación vinculada a una arquitectura
lógica restringe las posibilidades de desarrollo y solo debe admitirse si es impuesta por el cliente.
Especificación de requisitos independiente de la implementación: cuando no se impone una arquitectura física determinada. Una especificación vinculada a una arquitectura física restringe las posibilidades de desarrollo y solo debe admitirse si es impuesta por el cliente.
Especificación de requisitos testeable: si es posible definir y ejecutar test de validación y verificación del mismo, definiendo el tipo de test, el responsable de la ejecución y de la verificación, los valores esperados y obtenidos del test y la metodología de mediciones del test.
Especificación cuantificable: cuando es posible definir en manera discreta su contenido, enumerando los requisitos y sus unidades de mediciones asociadas.
Especificación prioritaria: de requisitos define las prioridades de los requisitos que la componen cuando se pueden identificarlos como necesarios, suficientes y opcionales, definiendo también el orden en que deben satisfacerse.
Especificación rastreable: si para cada requisito está claramente definido su ciclo de vida, es decir puede rastrearse hacia atrás o hacia delante en el tiempo su desarrollo evolutivo. Cada requisito debe ser unívocamente identificado. La rastreabilidad del requisito permite conocer la estabilidad del mismo, es decir el grado de cambios que ha tenido.
Stakeholders
Se define, aprueba y acuerda entre todos los stakeholders involucrados la metodología de gestión de requisitos.
Es importante hacer participar de la redacción de los requisitos a los stakeholders comprometidos con la necesidad del requisito, de manera tal que cada uno pueda efectuar su aporte a la definición del mismo.
Debe ser posible especificar para cada stakeholder involucrado si el desarrollo del requisito lo beneficia o lo perjudica, y el nivel de influencia que tiene el stakeholder considerado.
El impacto de la satisfacción del requisito para el sistema es el grado de participación de este requisito en el logro del éxito de una determinada función del aplicativo. Es una valorización objetiva. El impacto de la satisfacción del requisito para los stakeholders es una valorización subjetiva que asignan éstos a un determinado requisito, sin que necesariamente tenga un respaldo objetivo. Reconocer este impacto puede influir en la aceptación del producto por parte de los stakeholders involucrados.
Captura de requisitos
Es muy importante recordar que las tareas que se efectúan, muchas veces se realizan en un entorno de informalidad con datos incompletos, inconsistentes, y a veces, contradictorios entre sí. En base a estos, se define la estrategia, las técnicas y las herramientas para la captura de requisitos.
Principales técnicas de captura de requisitos
- Entrevistas
- Análisis de escenarios
- Prototipos
- Reuniones
- Observación directa
- Análisis de documentación
Principales fuentes de obtención de requisitos
- Objetivos
- Conocimientos del dominio
- Stakeholders
- Entorno operativo
- Entrono organizacional
Componentes
En la definición de la captura de requisitos se identifican tres componentes principales: Los usuarios/clientes, el team de sistemas, y la actividad de definición de requisitos.
Los usuarios
Los usuarios pueden ser conscientes de sus necesidades pero no son capaces de expresarlas apropiadamente. Muchas veces ocurre que los usuarios saben cómo hacer las cosas, o que es lo que necesitan, pero no logran describirlas correctamente.
Los usuarios pueden no ser conscientes de sus necesidades o puede que no comprendan como la tecnología pueda ayudarles en el desempeño de sus actividades. Algunos usuarios pueden no expresar sus necesidades o expectativas por miedo a quedar como incompetentes o ignorantes en el tema bajo análisis. Puede suceder también que el team de sistemas desarrolle su actividad en modo dominante o prepotente, de manera que la falta de
información y/o conocimiento de sistemas provoque que los usuarios se sientan en situaciones desagradables.
Los usuarios pueden no llegar a tomar decisiones porque no pueden prever las consecuencias de su decisión, porque no entienden las alternativas que se les plantean, o porque no tienen una visión global. Es necesario que el team de sistemas comprenda las necesidades y expectativas de los usuarios. Algunos desarrolladores no escuchan apropiadamente a los usuarios.
Comunicación.
Los usuarios y los desarrolladores tienen culturas y vocabularios diferentes, con la posibilidad de que los mismos términos tengan significados distintos o que su significado se vea afectado por el contexto.
El medio de comunicación debe ser entendible por todos los participantes. Se suele utilizar lenguaje natural porque es el único medio de comunicación común a todos los participantes, a pesar de su inherente ambigüedad.
Preocupaciones sobre el sistema.
Las preocupaciones sobre el sistema a desarrollar son distintas. Mientras los usuarios suelen preocuparse por aspectos de alto nivel como facilidad de uso o fiabilidad, los desarrolladores suelen preocuparse por aspectos de bajo nivel como utilización de recursos, algoritmos, etc. Es importante no olvidar que el principal interés de los clientes no es un sistema software en sí mismo, sino los efectos positivos resultantes de la introducción del sistema en su organización.
Conocimientos
Con respecto a los conocimientos, los usuarios no deben hacer suposiciones sobre aspectos tecnológicos y el team de sistemas debe tener un conocimiento adecuado del dominio del problema y no hacer suposiciones sobre ello.
Cuando los problemas son grandes y complejos, algunas personas tienden a hacer simplificaciones no válidas, a ignorar las partes más complejas o a centrarse únicamente en los aspectos que más conocen o que más les afectan.
Puede haber conflictos y ambigüedades en los roles que cada persona debe jugar en el proceso de captura de requisitos. Dentro del grupo de usuarios, algunos pueden pensar que, aun conociendo información útil, no es su responsabilidad o que se deben limitar a responder a los desarrolladores. La suposición o el temor a que el sistema a desarrollar cambie su forma de trabajar o incluso ponga en peligro su puesto de trabajo.
Los desarrolladores piensan que los clientes y usuarios les proporcionarán toda la información necesaria, con lo que pueden quedar aspectos sin tratar.
El software tiene que resolver problemas cada vez más complejos, por lo que sus requisitos son también cada vez más complejos y contemplan detalles cada vez más específicos del dominio del problema. Los requisitos cambian en el tiempo. Otra fuente de cambios es el hecho de que el hardware y el software cambian rápidamente, haciendo asequibles requisitos que antes eran inabordables por su complejidad o por su costo.
En algunos sistemas puede haber muchas fuentes de requisitos, por lo que a veces no basta con consultar con los clientes y usuarios, sino que también es necesario hacerlo con técnicos, personal de mantenimiento, consultar normativas, estándares, etc.
Es necesario tener también en cuenta que los sistemas novedosos requieren un esfuerzo mucho mayor de captura de requisitos y que las fuentes de información pueden ser muy distintas dependiendo de la naturaleza del sistema a desarrollar.
Consideraciones
Se define un conjunto de consideraciones a tener en cuenta en la captura de requisitos:
Diferenciar los conceptos de obtener y de comprender los requerimientos. Distinguir fuentes y canales oficiales de los requerimientos de aquellos informales o casuales.
Adecuados criterios de evaluación para aceptar los requerimientos. Identificar las expectativas de los stakeholders.
Definir, hacer conocer y obtener una aprobación de todos los intervinientes sobre las restricciones del desarrollo. Hacer participar a los stakeholders en todas las actividades de la gestión de requisitos, no sólo en la captura.
Se debe poder convertir las expectativas, solicitudes, restricciones y supuestos de los stakeholders en requerimientos documentados y aprobados.
Se deben consolidar los requerimientos, resolviendo conflictos, ambigüedades y prioridades.
Para comprender los requisitos se debe obtener información sobre el dominio área de negocio donde se implementará el sistema informático, sobre el sistema informático actual y sobre la estructura de la organización.
Debe existir un lenguaje común entre el team que realiza la captura de requisitos y quienes lo solicitan.
Se debe tener un plan para la realización de las actividades de captura de requisitos, describiendo herramientas y técnicas a utilizar, participantes, que información obtener, y como será el documento de requisitos a elaborar.
Análisis de requisitos
Una vez capturados los requisitos, se deben analizar los mismos con el objetivo de determinar cuáles serán parte del sistema y cuáles no.
Identificar las inconsistencias
Se deben analizar los requerimientos para identificar las inconsistencias entre los requerimientos capturados y los documentos del proyecto.
Identificar el impacto de los cambios en los requisitos
Agregar un nuevo requisito o modificar uno existente implica modificar el plan de proyecto, ya sea en tiempos, costos o alcance del mismo.
Evaluar el impacto con los principales stakeholders
En el análisis de requisitos se debe evaluar el impacto de los requisitos, identificando los efectos de una cobertura insuficiente o errónea del mismo.
Identificar solicitudes de cambios no fundamentadas
Dentro de la gran cantidad de solicitudes de requisitos a satisfacer, existe una importante cantidad que no están fundamentadas como objetivos del proyecto. Se debe recordar que por definición de proyecto se incluyen sólo las tareas necesarias para el cumplimiento del objetivo.
Identificar las causas reales de problemas detectados en los requisitos capturados
Analizando los requisitos en pueden encontrar situaciones que se pueden definir como anómalas. Éstas se deben poder identificar junto a los motivos de las mismas.
Limitaciones técnicas
En el momento de analizar los requisitos, se deben identificar todos aquellos que requieren una solución técnicas que está fuera de las incumbencias del proyecto.
Factores introducidos por los desarrolladores, en consideraciones de la actividad de la organización o de tipo legales
El team de desarrollo puede llegar a incluir factores en los requisitos debidos a la naturaleza de la actividad de la organización, debido a aspectos legales o contractuales o aspectos relacionados. Es estos casos se deben analizar éstos a fin de decidir como incluirlos en el plan de trabajo.
Analizar requisitos claves y derivados
En el momento de definir la importancia del cumplimiento de los requisitos para el éxito del proyecto, se debe diferenciar cuales son los requisitos claves, cuyo incumplimiento puede poder en serio riesgo el éxito del proyecto, con aquellos otros derivados, que se limitan a una acción específica y pueden degradar la calidad del producto ofrecido, pero sin llegar a amenazar gravemente al proyecto.
Identificar los requisitos que tienen una gran influencia en costos, tiempos, funcionalidad, riesgos o performance
En el momento de analizar los requisitos, es actividad vital para poder detectar y definir cuáles son los requisitos que más influencias tienen en el consumo de recursos, ya sean económicos o temporales, cuyos desvíos impactarán seriamente en el cumplimiento del proyecto.
Analizar lo requerimientos para balancear las necesidades de los stakeholders con las restricciones del proyecto
En el momento de analizar los requisitos, nos encontramos con la necesidad de balancear las necesidades de distintos stakeholders con las restricciones del proyecto, de manera tal de poder desarrollar aquellos que más aportan al éxito del proyecto.
Analizar los requerimientos para poder determinar los riesgos que el producto no satisfaga las reales necesidades de los usuarios finales
Un análisis detallado de los requerimientos debe poder determinar cuáles son los riesgos que una vez finalizado el producto del proyecto, según como fue planeado, no satisfaga las expectativas de los usuarios finales. Muchas veces es el responsable de un área de definir los requisitos y es un grupo de persona diverso quién efectivamente utiliza el producto, y éste puede no satisfacer sus necesidades reales.
Documento de criterio de Análisis
El análisis de los requisitos no se puede hacer improvisadamente, se debe implementar una metodología, que permita realizar el análisis de una manera tal que pueda garantizar los resultados obtenidos.
Reagrupar requisitos
Muchas veces, existen diversos requisitos con definiciones similares. Es importante poder agruparlos en un solo requisito, acordado por los solicitantes, a fin de simplificar las tareas a desarrollar, reduciendo tiempos, costo y riesgos.
Asignar los requerimientos para cada componente del producto
Durante el análisis de requisitos se asocian éstos a los componentes del producto del proyecto.
Definir las medidas de performance de un requisito y la capacidad para ser probados
Estas definiciones nos permiten verificar posteriormente el desarrollo del requisito.
Stakeholders
Se debe analizar si los stakeholders identificados en los requerimientos corresponden a los definidos en los documentos del proyecto.
Documentación
La documentación debe poder ser revisada, evaluada, controlada y aprobada sistemáticamente.
Validación y verificación de requisitos
La validación y verificación de requisitos es la actividad en la que los stakeholders y el team del proyecto revisan los productos obtenidos durante las actividades anteriores para confirmar que realmente reflejan sus necesidades y que definen el producto deseado. Se debe determinar si los requisitos son completos y correctos, los productos de cada fase de desarrollo satisfacen los requisitos o condiciones impuestas por la fase previa y el sistema o componente final es acorde con los requisitos especificados.
Consideraciones
A continuación se expone una serie de elementos a considerar cuando se desarrollan actividades de validación y verificación de requisitos.
Validar los aspectos dinámicos para determinar las reacciones del sistema ante determinados estímulos.
Validar aspectos estáticos, representado por los datos y las relaciones entre éstos que el sistema gestiona.
Validar los aspectos funcionales que corresponden a las funciones de transformación de datos en información y de ésta en conocimiento.
Verificar que los cambios en los requerimientos sean aprobados y se actualice la planificación y la especificación del producto del proyecto de acuerdo al cambio. Verificar que la suma de los requisitos describen el producto deseado.
Definir una metodológica para la validación de requisitos que incluya las tareas a realizar y productos a obtener durante la realización de la actividad de validación de requisitos.
Validar los requisitos funcionales y no funcionales, de almacenamiento de información, verificar funciones y capacidades del sistema, verificar requisitos de negocio, organizativos y de usuario.
Verificar requisitos de seguridad física, requisitos de ingeniería de factores humanos (ergonomía), verificar interfaces y requisitos de operación y mantenimiento.
Verificar limitaciones de diseño y requisitos de calificación, características físicas y condiciones del entorno en el que el elemento software ha de funcionar, interfaces externas al elemento software, métodos de operación y mantenimiento, definición de datos y requisitos de las bases de datos.
Verificar requisitos de instalación y aceptación del producto software entregado, documentación de usuario, requisitos de operación y de mantenimiento por parte del usuario.
Los requisitos deben ser verificados antes de que los recursos sean asignados. Verificar la asignación de los recursos disponibles a los distintos requisitos.
Verificar utilidad de los requisitos, en cuanto aporta al éxito del proyecto. Verificar la garantía del cumplimiento de los requisitos en términos de disponibilidad, capacidad, continuidad y seguridad.
Verificar que todos los requisitos deben respetar las normas de confidencialidad del acceso y divulgación de información definida por la organización.
Verificar que los requisitos satisfagan los aspectos legales como la identificación de la legislación a aplicar, derechos de propiedad intelectual, protección de datos
e información de la organización y de las personas, prevención del uso inadecuado de información. Seguridad frente al acceso por parte de terceros.