Hasta ahora se ha explicado qué son y cómo se redactan los requisitos. Pero ¿Cómo se descubren?, ¿Cómo se ordenan y priorizan? El análisis de requisitos pretende modelar, dar forma, a los requisitos. Para ello, el análisis de requisitos ayuda a extraer, ordenar y priorizar requisitos.
Existen ciertas técnicas que ayudan a recoger y recabar información que permita entender las necesidades del cliente: entrevistas, observación in situ de los procedimientos actuales del negocio, revisión de documentación, etc. La extracción de requisitos realizada por el analista es una labor compleja que requiere de experiencia y competencias específicas.
🔎 Para determinar las necesidades que el informe de seguimiento de pacientes diabéticos debía cubrir, el equipo de analistas se reunió con las usuarias líderes y responsables del negocio. La reunión resultó muy fructífera. Tras aflorar muchos requisitos, los analistas, satisfechos, dieron la reunión por acabada. Al despedirse, una usuaria comentó:
- Un último detalle. Estaría muy bien que el informe de seguimiento incluya un campo de “observaciones” en donde anotar lo que queramos.
Los experimentados analistas sabían que la solicitud por parte de los usuarios de campos de texto libre que permiten registrar “lo que quiera” pueden ocultar la auténtica necesidad.
- ¿Qué es lo que te gustaría escribir en ese campo “observaciones”?
- Bueno, me gustaría indicar el peso y la altura del paciente. De esta manera podría calcular el índice de masa corporal. En pacientes crónicos el índice de masa corporal es una información valiosa a la hora de valorar el evolutivo.
Los analistas se miraron y, sonriendo, anotaron un nuevo requisito. En lugar de añadir el requisito “nuevo campo de observaciones”, añadieron el requisito “nuevo campo índice de masa corporal”.
Para descubrir los requisitos funcionales es indispensable entender adecuadamente los procesos de negocio. El analista debe primero entender el proceso de negocio, para posteriormente identificar los problemas y oportunidades de mejora. Una vez recopilada la información, si los procedimientos del cliente son complejos puede resultar conveniente estructurar, moldear y trocear todos estos datos. Modelar los procesos de negocio facilita la detección de problemas y necesidades a los que el producto software deberá dar solución.
🔍 Un proceso de negocio es una colección de actividades o tareas relacionadas y estructuradas que en una secuencia específica produce un servicio para un cliente.
Modelar los procesos de negocio obliga a detallar cómo interactúan los diferentes actores, esto permite hacer “emerger” los requisitos al identificar los problemas e inconvenientes del proceso descrito. Algunos procesos de negocio son modelados en lenguaje natural, otros en lenguaje más o menos estructurado, otros en tablas, otros en diagramas, etc. Documentar estructuradamente y formalmente el proceso favorece la comprensión de las necesidades a aquellos participantes más alejados del negocio como desarrolladores, managers o técnicos de operación y, además, facilita al propio analista encargado de redactarlo entender con mayor profundidad y detalle el proceso descrito. Este profundo conocimiento del proceso permite identificar los problemas y necesidades subyacentes.
Para detallar el proceso de negocio se suele hacer uso de diagramas de flujo, de entidad-relación, de estados o BPMNs. Todos estos diagramas ayudan a entender los roles, las actividades, los artefactos generados, los mensajes intercambiados, así como el orden en qué todo ello sucede. Son “planos” del negocio, “planos” de la actividad del cliente. Entender y conceptualizar el dominio dónde residirá el producto software es clave para su desarrollo exitoso. El modelado del proceso de negocio pretende descubrir los principales actores, los artefactos que generan y actividades que realizan. También ayuda a modelar el “lenguaje” del negocio identificando los conceptos y términos utilizados.
💬 Un hombre saca el alambre, otro lo endereza, un tercero lo corta, un cuarto le saca punta, un quinto lo pule en la parte superior para recibir la cabeza; para hacer la cabeza se requieren dos operaciones distintas; ponerla es un trabajo peculiar, blanquear los alfileres es otra; incluso ponerlos en el papel es un oficio particular; y el negocio importante de hacer un alfiler es, de esta manera, dividido en cerca de dieciocho operaciones diferentes…
Adam Smith, La Riqueza de las Naciones (1776)
En “La Riqueza de las Naciones” (1776), Adam Smith explica el proceso del negocio de lla fabricación de alfileres. Adam Smith identifica los actores, las actividades realizadas y los artefactos a la hora de describir el proceso de negocio. Igualmente hace uso de tecnicismos propios del negocio que se describe.
Durante el modelado del negocio es posible hacer uso de diagramas utilizados también en la actividad de Análisis Funcional. Cuando se hace uso de los diagramas utilizados en el Análisis Funcional para modelar y entender, no la solución funcional ofrecida por el producto software, sino la situación actual de las actividades del cliente, entonces estos diagramas pasan a ser herramientas de análisis de requisitos.
Una vez recopilados los requisitos deben ser priorizados, agrupados o divididos. Este estudio puede realizarse de manera más o menos formal, en función del tipo de metodología empleada en el proyecto.
En la visión adaptativa es habitual disponer las Historias de Usuario en paneles para facilitar su ordenamiento y priorización. El User Story Map muestra estas relaciones agrupando las HUs por módulos funcionales (verticalmente) y por sprints o releases (horizontalmente).
En la visión predictiva es habitual documentar el estudio en los llamados “Estudios de Viabilidad”. El “Estudio de Viabilidad” es un tipo especial de proyecto cuyo objetivo es despejar la incertidumbre sobre plazos, coste y alcance. El resultado entregado por un “Estudio de Viabilidad” no es software, sino una planificación de trabajos.
Cuando no se realiza una adecuada priorización de requisitos, el producto software puede acabar engordando funcionalmente de manera excesiva. Este problema es conocido en la industria como feature creep. Una de sus causas es la falta de liderazgo por parte del dueño del producto a la hora de señalar las funcionalidades esenciales. La falta de estrategia funcional puede provocar que el producto crezca en funcionalidades que se usan rara vez o nunca.
Referencias:
• J.Palacios; https://jeronimopalacios.com/
• J.M. Beas; https://jmbeas.es/
• M. Cohn "User Stories Applied: For Agile Software Development", Addison-Wesley Signature Series, 2004
• S. Gómez, E. Moraleda; "Aproximación a la Ingeniería del Software", Editorial Universitaria Ramón Areces, 2014
• I. Sommerville; “Ingeniería del Software”, Addison Wesley, 2005
• Sam Guckenheimer, “Ingeniería del Software con Microsoft Visual Studio Team System”, Danysoft, 2008