💬 La parte independientemente más difícil de crear en un sistema de software es decidir precisamente qué crear
Fred Brooks, “The mythical man-month"
Un requisito es una necesidad que el producto software debe suplir. El cliente puede sufrir de ciertas necesidades “funcionales” que hacen referencia a problemas específicos derivados de su negocio. A este tipo de necesidades se les denomina “Requisitos Funcionales”. Estos requisitos deben ser suplidos por la funcionalidad que el producto software ofrecerá.
Por otro lado, existen otro tipo de necesidades que el producto software también debe suplir. Son necesidades “técnicas” que hacen referencia a problemas específicos derivados de las exigencias de explotación de los sistemas, del nivel de soporte que se desea ofrecer, de la legislación referente a la protección de datos, de las ubicaciones físicas, etc. A este tipo de necesidades se les denomina “Requisitos No Funcionales” o “Requisitos Técnicos”.
Recoger erróneamente los requisitos del software conllevará la construcción de un producto equivocado, un producto que no suple las auténticas necesidades del cliente.
El termino “requisito” puede resultar confuso, ya que es igualmente empleado tanto para definir los problemas de negocio que debe resolver el software como para definir las capacidades y funcionalidades del software que dan solución a los problemas de negocio. En lo sucesivo, el termino “requisito” se emplea para definir los problemas de negocio. Para definir las capacidades y funcionalidades del software se empleará el término “especificación funcional”. Las especificaciones funcionales y técnicas del software serán entregadas tras el Análisis.
🔍 En la ingeniería de desarrollo de sistemas, un requisito es una necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio. Se usa en un sentido formal en la ingeniería de sistemas, ingeniería de software e ingeniería de requisitos.
En la ingeniería clásica, los requisitos se utilizan como datos de entrada en la etapa de diseño del producto. Establecen qué debe hacer el sistema, pero no cómo hacerlo.
La fase de captura, elicitación y registro de requisitos precede a la fase de análisis conceptual del proyecto. Esta fase de requisitos puede dividirse en recolección de requisitos, análisis de consistencia e integridad, definición en términos descriptivos para los desarrolladores y un esbozo de especificación, previo al diseño completo. [..]
Un requisito de negocio o funcional es una necesidad o problema que sufre el cliente. Los requisitos funcionales, también llamados requisitos de negocio, se caracterizan por:
Describen problemas, no soluciones. Es decir, responden al qué, no al cómo.
Se descubren, no se recogen.
Se expresan en lenguaje de negocio, no en lenguaje técnico.
Son concretos, no abstractos.
Al indagar con el cliente, las necesidades que debe suplir el software es imprescindible distinguir la situación actual (“as is”) y la situación deseada (“to be”). La situación actual ayuda a describir el problema, la situación deseada ayuda a entender una posible solución. En ocasiones, a la hora de descubrir los requisitos del negocio resulta conveniente poner el foco en los problemas o necesidades del cliente en lugar de en sus deseos. En lugar de expresar los requisitos como deseos, por ejemplo: “disponer de esta nueva funcionalidad me va a ofrecer estas ventajas: …” puede resultar más claro, real y tangible, expresar los requisitos como problemas, por ejemplo: “no tener esta funcionalidad me está generando estos problemas: …”.
Identificar cuál es realmente la necesidad del cliente no es siempre sencillo.
🔎 Una empresa del sector del automóvil desea implantar un nuevo ERP (Enterprise Resource Planning). El ERP le facilitará la gestión logística, registro de inventario, facturación, etc. Para ello contrata a una consultora informática. La empresa traslada a la consultora sus necesidades. La siguientes tres afirmaciones expresan una misma necesidad:
Necesito reembolsar la factura al proveedor
Necesito enviar un mail al proveedor con la factura como archivo adjunto
Necesito desarrollar un cliente SMTP y un exportador de documentos a PDF
¿Cuál de las tres afirmaciones expresa de forma más adecuada el auténtico requisito?
Todas estas afirmaciones expresan una necesidad. Sin embargo, un requisito no se define solo como una necesidad, además un requisito debe expresar el “qué” pero no el “cómo”. La tercera afirmación “Necesito desarrollar un cliente SMTP y un exportador de documentos a PDF” indica cómo dar solución técnica a la segunda afirmación. En este sentido, la tercera afirmación es una solución, no un problema. La tercera afirmación es el “cómo” y la segunda afirmación es el “qué”: para poder enviar por mail la factura al proveedor habrá que exportar la factura a PDF y usar un cliente de correo. La tercera necesidad no puede ser un requisito funcional de negocio.
A su vez la segunda afirmación “Necesito enviar un mail al proveedor con la factura como archivo adjunto” expresa la solución a la primera afirmación: para poder reembolsar la factura al proveedor es necesario enviar por mail la factura. La segunda afirmación es el “cómo” de la primera afirmación. La segunda necesidad no puede ser un requisito funcional de negocio.
Es la primera afirmación “Necesito reembolsar la factura al proveedor” la que expresa el auténtico problema del negocio y por lo tanto el requisito funcional.
Es habitual que, durante la redacción de requisitos, el cliente (negocio) traslade, no los problemas o necesidades que sufre, sino las soluciones que cree más adecuadas a sus problemas o necesidades. En ocasiones los deseos de negocio no reflejan adecuadamente sus auténticas necesidades. Lo que el cliente cree que quiere no siempre es lo que realmente necesita.
🔎 La jefa de la unidad de enfermería trasladó a la analista:
- Necesito poder imprimir (en papel) informes obtenidos a partir de los datos recogidos por el pulsioxímetro. Habrá que instalar una impresora y…
A la experimentada analista le resultó sorprendente esta petición.
- Perdona, ¿Estás segura de necesitar imprimirlo? Los impresos en papel no suelen resultar muy útiles hoy en día.
- Es imprescindible.
- ¿Por qué?
- Necesito imprimir el informe para poder consultarlo en el software de historia clínica.
- No lo entiendo. ¿Cómo es eso?
- Verás, una vez impreso el informe, un celador lo lleva a admisión. Diariamente los mensajeros trasladan los informes al Archivo, en Archivo lo escanean y una vez digitalizado el informe es anexado a la ficha del paciente en la historia clínica informatizada. De esta forma, el informe puede ser consultado por las especialistas.
Tras la explicación de la jefa de enfermería, a la analista le quedó claro que la auténtica necesidad no era imprimir el informe del pulsioxímetro, sino incorporar los datos clínicos (saturación y frecuencia) a la historia clínica del paciente para poder ser consultados por la especialista. La jefa de enfermería no estaba expresando un requisito, sino la solución que cree más conveniente, o quizás la única solución que conoce.
La analista propuso a la jefa de enfermería no imprimir el informe. Los pulsioxímetros son capaces de generar el informe en PDF en una unidad de red. Desde la unidad de red, la enfermera puede anexarlo directamente a la ficha correspondiente de la historia eliminando de este modo el farragoso proceso basado en papel.
Los requisitos rara vez son recogidos “al dictado”. En lugar de ello, los requisitos deben ser extraídos y refinados a partir de la observación, conversación y el trato con el cliente. En este sentido, los requisitos no se “recogen” sino que se “descubren”. Es habitual usar el término “elicitar requisitos”. “Elicitar” es un anglicismo proveniente de la palabra “Elicitation” que significa “sonsacamiento”.
Existen algunas técnicas que pueden ayudar a encontrar la auténtica necesidad del cliente, por ejemplo la técnica de los “Cinco Por Qué” de Toyota propone encontrar la raíz del problema preguntando “¿por qué?” cinco veces consecutivas.
Para identificar correctamente si el requisito funcional refleja adecuadamente el problema o, por el contrario, indica equivocadamente la solución es útil observar el lenguaje utilizado. Si el supuesto requisito de negocio se expresa con términos técnicos probablemente sea una solución.
🔎 A continuación, se subrayan los términos técnicos de las siguientes afirmaciones:
Necesito enviar un mail al proveedor con la factura como archivo adjunto
Necesito desarrollar un cliente SMTP y un exportador de documentos a PDF
Esta otra afirmación está expresada en términos de negocio:
Necesito reembolsar la factura al proveedor
Al indagar las auténticas motivaciones del negocio en busca de sus necesidades reales eliminando de los requisitos las soluciones técnicas, es posible que erróneamente se redacten requisitos excesivamente abstractos que apenas aportan información sobre los problemas que pretenden solventar.
🔎 “Necesito generar de la forma más precisa posible informes que han de ser enviados al ministerio”
Este requisito apenas aporta información sobre la naturaleza del problema. “mostrar información precisa”, es una afirmación obvia, la negación de esta afirmación no tiene sentido: nadie desea mostrar informes imprecisos. Al profundizar sobre estos requerimientos los problemas se concretan. Por ejemplo, una redacción más adecuada del requisito hubiese sido:
“Necesito que los datos relativos a la cobertura poblacional de las vacunas administradas que comunico al ministerio no queden desvirtuados al incluir en ellos a personas que no son residentes en la comunidad Foral, que solo están de paso.”
🔎 “Necesito mejorar el algoritmo que determina las horas de toma diarias en la integración de la prescripción. Farmacia necesita en la validación que las horas de toma de ciertas prescripciones que dispensa sean correctas”
Este requisito apenas aporta información sobre la naturaleza del problema. “mejorar el algoritmo” u “horas de toma correctas” son afirmaciones obvias, la negación de estas afirmaciones no tiene sentido: nadie desea empeorar el algoritmo u horas de toma incorrectas. Al profundizar sobre estos requerimientos los problemas se concretan. Por ejemplo, una redacción más adecuada hubiese sido:
“Necesito que cuando los farmacéuticos del hospital consulten las prescripciones realizadas por los intensivistas de la UCI para preparar las mezclas vean el patrón horario pautado sin incluir la hora “forzada” de la primera toma al ser esta anómala (artificial).”
Un requisito de negocio debe ser SMART (inteligente):
Specific. Es comprensible, no abstracto y refleja claramente su propósito
Measurable. Puede medirse para ver si cumple su objetivo
Achievable. Es realista, alcanzable y/o realizable
Relevant. Contribuye de forma relevante al producto o servicio
Time-boxed. Es realizable en un plazo máximo de tiempo.
Por ejemplo, el siguiente requisito no funcional relativo a la usabilidad está pobremente expresado: “El sistema deberá ser fácil de usar”. La expresión SMART del requisito podría ser: “Después de una capacitación de dos horas, a los controladores especializados les deberá ser posible utilizar todas las funcionalidades del sistema. Después de esta capacitación, el número de errores cometidos por los usuarios experimentados no excederá de dos por día”
Una forma sencilla de concretar el requerimiento es indicar ejemplos que ilustran el problema o necesidad que se pretende solventar. La Especificación Por Ejemplo (Specification by example, SBE) es un enfoque colaborativo que permite unir el requisito con su prueba funcional basado en capturar e ilustrar requisitos utilizando ejemplos realistas en lugar de declaraciones abstractas. Specification By Example es habitualmente aplicado en la visión adaptativa de la construcción de software. Técnicas de diseño y codificación como ATDD hacen uso de estas prácticas.
Existen otro tipo de requisitos que expresan necesidades de otros partícipes o stakeholders que no son funcionales:
Requisitos técnicos de explotación. Los responsables de explotación y operación pueden requerir el uso de ciertas plataformas servidoras o cumplir con ciertos escenarios tecnológicos de la organización. Por ejemplo, la solución propuesta debe correr en un servidor windows 2012.
Requisitos relativos al nivel de servicio exigido. El cliente u otros actores (stakeholders) pueden exigir una determinada disponibilidad (número máximo de paradas asumidas en un mes), capacidad (número de usuarios concurrentes) o rendimiento (tiempos de respuesta) a la solución planteada. Por ejemplo, la solución propuesta debe ofrecer una disponibilidad del 99,9999% del tiempo.
Requisitos de soporte técnico. Pueden existir requerimientos especiales de soporte ante incidencias técnicas o funcionales en cuanto a los horarios de atención y la capacidad y calidad del soporte. Por ejemplo, el cliente requiere soporte los siete dias de la semana y las veinticuatro horas del día.
Requisitos de seguridad. El responsable de seguridad de la organización puede requerir cumplir ciertas exigencias en el marco normativo del RGPD (Reglamento General de Protección de Datos) o el ENS (Esquema Nacional de Seguridad) como por ejemplo la auditoría de accesos a datos protegidos o el respaldo de copias de seguridad.
Requisitos técnicos de integración. Los responsables técnicos pueden requerir el uso de ciertas plataformas de integración como por ejemplo los Bus de Mensajería Empresarial (Enterprise Service Bus)
Requerimientos de ubicación física y material asociado. Las restricciones del entorno físico pueden tener impacto en la solución técnica, por ejemplo, no disponer de espacio para el teclado o ratón puede exigir el uso de pantallas táctiles.
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