Please enable JavaScript.
Coggle requires JavaScript to display documents.
Validación de requisitos - Coggle Diagram
Validación de requisitos
Validación de requerimientos
Busca ratificar que los requerimientos realmente están especificando lo que el cliente desea y necesita.
Un error en los requerimientos puede consumir muchos recursos si se detecta en fases avanzadas del proyecto.
Un error en los requerimientos se propaga en cascada en todas las fases subsiguientes del ciclo de la vida.
Según Sommerville (2011), en el proceso de validación de requerimientos se llevan a cabo las siguientes verificaciones:
Verificaciones de completitud:
se incluyen todas las funcionalidades y restricciones definidas por los usuarios del sistema.
Verificaciones de realismo:
los requerimientos son realizables de acuerdo con la tecnología existente, el presupuesto y los tiempos definidos.
Verificabilidad:
es posible demostrar la realización de cada requerimiento y que hace lo que debe hacer. Es decir, existe una forma clara en la que se le pueda realizar pruebas.
Verificación de validez:
los requerimientos son razonables e identifican realmente todas las funciones necesarias para cumplir con las necesidades del cliente.
Verificación de consistencia:
los requerimientos no presentan contradicciones.
Existen varias técnicas que pueden usarse para la validación de requisitos
Revisiones de requerimientos
es un proceso manual que involucra la participación de personas de parte de la organización constructora del software así como la de los clientes.
en el proceso de verificación debe resolverse cada una de las siguientes preguntas:
Verificabilidad:
¿Es posible probar este requerimiento en la realidad?
Comprensibilidad:
¿Es claro lo que expresa este requerimiento para las personas que lo van a usar?
Rastreabilidad:
¿Es posible observar el origen del requerimiento y también evaluar los cambios que pueden generar en el sistema?
Adaptabilidad:
¿El cambio en el requerimiento impacta o no a gran escala sobre otros requerimientos?
Construcción de prototipos
Un prototipo es una versión inicial de un sistema que permite probar:
Conceptos
Diseño
Flujo
Y otros aspectos por medio de la interacción directa de los cliente o usuarios finales en las primeras etapas del proceso del software.
Un prototipo puede ayudar a:
Validación de los requistios del sistema
Permite explorar soluciones y posibles interfaces de usuario.
Ayudan en el proceso de pruebas.
puede revelar errores u omisiones en los requerimientos.
Los prototipos son ideales para encontrar elementos faltantes o sobrantes en las definiciones de los requerimientos.
también puede generar algunos riesgos, entre los que se encuentran:
El prototipado puede estimular un número excesivo de cambios de peticiones.
Los prototipos operativos pueden inducir a pensar a la directiva y a los clientes que el producto final está prácticamente dispuesto para su salida al mercado.
Para verificar requisitos, se recomiendan prototipos de baja fidelidad (escenarios con maquetas estáticas) y exploratorios (no reutilizables, solo para clarificación e identificación de requerimientos).
Los prototipos pueden encarecer el producto.
Un prototipo puede ser una representación gráfica en papel o con herramientas ofimáticas. Existen herramientas, gratuitas y de pago, que facilitan su creación, algunas en el navegador y otras requieren instalación.
Adobe XD
Marvel App
Moqups
LucidChart
Proto.io
Balsamiq
Wirify
Picodo
Generación de casos de prueba
Desarrollar pruebas para los requerimientos permite evidenciar problemas antes de escribir cualquier línea de código.
Normalmente, si es complejo construir un caso de prueba para un requerimiento, esto indica que podría ser difícil de implementar y debe considerarse.
La validación de requisitos por casos de prueba requiere el desarrollo de cuatros fases:
i) planeación de la prueba.
Aquí se define la estrategia a utilizar, el alcance de la prueba a realizar y los tiempos requeridos para el desarrollo de la prueba;
ii) diseño de los casos de prueba
iii) ejecución de los casos de prueba
iv) elaboración del informe final de la prueba donde se describen los aspectos más importantes y hallazgos de la ejecución de la prueba.
De otra parte, el diseño de un caso de prueba requiere:
i) la construcción de un instrumento donde se debe detallar para cada requerimiento si existen precondiciones, es decir, si se requieren de actividades o valores previos para poder iniciar la ejecución del requerimiento;
ii) identificar los pasos a seguir para la validación de un requisito
iii) los resultados esperados de la realización de cada paso.
Formato de caso de prueba, adaptado de Pantaleo (2018)
Requerimientos duraderos y volátiles
Los requerimientos de un proyecto inevitablemente sufren variaciones en el tiempo y puede ser por varios motivos entre los que se podrían destacar cambios en las políticas gubernamentales, sociales, económicas o, sencillamente, por solicitudes de los clientes.
dependiendo de la perspectiva evolutiva de los requerimientos estos se pueden clasificar en dos grupos:
Requerimientos duraderos:
Son relativamente estables y normalmente se derivan de las actividades principales de la organización y están directamente relacionados con el dominio del sistema
Por ejemplo, en un sistema académico los requerimientos relacionados con la gestión de estudiantes, profesores y grupos hacen parte del dominio y, seguramente, el modelo de negocio asociado a estos requerimientos no van a cambiar mucho en el tiempo.
Requerimientos volátiles:
Son los que, muy probablemente, cambian durante el proceso del desarrollo del sistema o después que este entra en funcionamiento.
Por ejemplo, en un sistema académico un requerimiento asociado al proceso de pago de pensión podría definirse de forma manual en un principio; es decir, la secretaria una vez reciba el dinero o los recibos de pago registra el pago en el sistema, más adelante si la institución educativa adquiere un servicio de pasarela de pagos en línea el requerimiento podría modificarse totalmente.
Los requerimientos volátiles según Sommerville (2011) se clasifican en:
Requerimientos cambiantes:
cambian de acuerdo con el entorno, por ejemplo: una pandemia.
Requerimientos emergentes:
surgen como producto de un mejor entendimiento del sistema, por ejemplo, al estructurar el diseño de las interfaces del sistema puede ser que se requieran adicionar componentes que no estaban contemplados.
Requerimientos consecuentes:
son resultado de la puesta en marcha de un sistema. Generalmente la adopción de un nuevo sistema involucra el cambio de procesos e incluso roles dentro de la organización que, a la vez, puede influir en cambios en los requerimientos del sistema.
Requerimientos de compatibilidad:
dependen de otros sistemas o procesos, cuando estos cambian generalmente producen también cambios en los requerimientos dependientes.
Herramientas para la gestión de requisitos
existe una variedad de herramientas para ser utilizadas específicamente en la gestión de requisitos
la utilización de estas ayuda a mejorar la calidad del desarrollo de un proyecto y permite un mayor control en el mantenimiento previniendo posibles errores durante la ejecución del proyecto
Existen herramientas básicas de requerimientos y herramientas complejas
Herramientas básicas:
se manejan en la planeación de gestión de requisitos muy básica y se pueden utilizar las hojas de cálculo, o una plantilla de documento en Word; es difícil su utilización cuando se trata de actualización con varias personas y el manejo de las versiones de los documentos.
Herramientas complejas:
para una planificación de gestión de requisitos más compleja, se necesita un sistema de software completo para administrar las relaciones entre los requisitos, analizar el impacto de cualquier cambio, administrar las aprobaciones y demás aspectos.
las herramientas de gestión de requisitos se caracterizan por las siguientes propiedades:
● Gestión de requisitos basados en modelos de información como por ejemplo casos de uso o historias de usuario.
● Organización de requisitos: es fácil agrupar el conjunto de requisitos y determinar su orden.
● Acceso y gestión multiusuario: múltiples personas pueden participar en los procesos de construcción o modificación de requisitos.
● Gestión de la trazabilidad: se puede ver a nivel histórico los cambios realizados en los requisitos con su marca de tiempo y usuarios involucrados.
Existen herramientas libres y comerciales; a continuación, se indican las más conocidas.
Comerciales
IBM Rational
Aplicación de gestión de requisitos para optimizar la comunicación, la colaboración y la verificación de requisitos.
Link
IBM RequisitePro
Herramienta de administración de requisitos que permite crear y compartir basado en documentos potenciados.
Link
Jama Software
Herramienta de administración de requisitos que permite visibilidad y control.
Link Title
Libres
HELER
Herramienta de requisitos automatizada.
REM
Totalmente desarrollada para la elicitación de requisitos.
OSRMT
Permite la descripción avanzada de diversos tipos de requisitos y garantiza la trazabilidad entre todos los documentos relacionados con la ingeniería de requisitos (funcionalidades, requisitos, casos de uso, casos de prueba).
