Introducción
Primero que todo, es bueno recordar que esto es única y exclusivamente desde mi punto de vista, a algunas personas puede gustarles y a otras disgustarles, lo único que se busca con la creación de este blog es una pequeña guía para los que vamos empezando en esto, y porque no, puede servirme de referencia para futuros proyectos.
Toma de requerimientos
¿A que llamamos requerimiento?
Básicamente un requerimiento es un componente que se necesita implementar para finalizar una función o un producto. Es lo que tu producto debe cumplir para satisfacer las necesidades del cliente. Existen cientos de requisitos de software, pero todos ellos los podemos englobar en:
- Necesarios: Se necesita cumplir con este requisito para poder lograr los objetivos previstos del producto.
- Específicos: Debe de ser sumamente detallado y tener claro su propósito.
- Fáciles de entender: Debe de estar correctamente redactado para una fácil comprensión.
- Precisos: No solamente es colocar el requisito, si no detallar el porque es importante que se implemente.
- Viables: Aunque sea una idea muy buena, no servirá de nada si no se adecua a la infraestructura actual del proyecto, por lo que antes de hacer el requerimiento es necesario preguntarse ¿lo puedo implementar actualmente?
Es importante conocer la necesidad real del cliente, ya que en muchas ocasiones ni siquiera el cliente mismo sabe lo que quiere. Hay bastantes técnicas para poder conocer la visión real del proyecto. Entre ellas están:
Importancia de los requerimientos
Gestionar los requisitos de una manera práctica es verdaderamente eficaz a la hora de comprender lo que en realidad quiere el cliente. Principalmente porque esto conlleva:
- Entregar funciones completas: Este proceso es útil cuando se trata de establecer lo que el cliente necesita conforme la interpretación de su interacción con el producto.
Existen 3 tipos principales de requisitos:
Requisitos comerciales
Son los objetivos generales de negocios de la empresa. No necesariamente tiene que ser una funcionalidad del producto, sino cosas que el negocio necesita para complacer a las partes interesadas, tanto externas como internas. Por ejemplo:
Supongamos que trabajas para una empresa de servicios de taxi y el equipo de desarrollo está trabajando en un nuevo software de reservas en línea. El requisito comercial para este proyecto podría ser "aumentar la eficiencia de reservas en línea para aumentar la satisfacción del cliente y aumentar las reservas en un 30% en el próximo trimestre". Para cumplir con este requisito, el software de reservas en línea debe ser fácil de usar, permitir reservas rápidas y fáciles, y proporcionar información clara sobre las tarifas y los horarios de los viajes. Además, el software debe integrarse con los sistemas de facturación y administración de la empresa para garantizar una experiencia de usuario sin problemas.
Requisitos del usuario
Se define que necesitan los usuarios y como interactúan con tu producto. Se describen las acciones que el cliente desee cumplir.
Generalmente, en los equipos ágiles a los requisitos del usuario se les da el formato de historias de usuarios, que consisten en explicaciones informales de una función de software, redactadas desde la perspectiva de un usuario final. Las historias de usuarios siguen este formato: “Como [perfil], quiero [objetivo del software], para lograr [resultado]”.
Requisitos del sistema
Con esto se define que es lo que el producto hará.
En la mayoría de los casos, los requisitos del sistema se desglosan en requisitos funcionales y no funcionales. Con los requisitos funcionales se define qué hará el producto, mientras que con los no funcionales se determina en qué medida las funciones del producto trabajarán como se espera. Esto significa que, normalmente, los requisitos no funcionales están vinculados a la seguridad, el rendimiento y la fiabilidad.
Y por que me gusta complicarme la existencia, a continuación un ejemplo.
| Requisitos funcionales | Requisitos no funcionales |
|---|---|
| 1. El software debe permitir a los usuarios hacer reservas en línea de manera rápida y sencilla, en cualquier momento del día o la noche. | 1. El tiempo de respuesta del sistema para hacer una reserva no debe de superar los 3 segundos. |
| 2. La plataforma debe ofrecer información clara sobre las tarifas y los horarios de los viajes. | 2. El software debe ser fácil de usar y tener una interfaz intuitiva para los usuarios. |
| 3. El software debe permitir a los usuarios ver y editar su historial de reservas anteriores. | 3. El sistema debe ser seguro y proteger la información personal y financiera del usuario. |
| 4. El software debe permitir a los usuarios cancelar o modificar una reserva existente. | 4. El software debe estar disponible las 24 horas del día, los 7 días de la semana, con una disponibilidad del sistema de 99,99%. |
Técnicas de obtención de requerimientos
- Cuestionarios: Es increíble la cantidad de información que se puede recabar a través de los cuestionarios, es la forma (creo yo) más antigua, sin embargo una de las más eficientes.
- Lluvia de ideas: No es bueno subestimar las ideas que salen de este tipo de prácticas, a veces una buena idea no requiere tiempo pensarse.
- Prototipo: Consiste en mostrar al cliente un prototipo, esperando que este te brinde funcionalidades adicionales, puede ser realmente útil si ya se tiene un prototipo previo, ya que en caso de no tenerlo se corre el riesgo de ocupar tiempo valioso en algo que no está ni cerca de lo que el cliente quiere, teniendo que desechar ese prototipo (al menos para ese cliente) y empezar de cero.
Las técnicas anteriores pueden ser bastante útiles en mayor o menor medida, según se vea, siento que todos concordamos en que la más sencilla y la más efectiva es:
- Pregúntale directamente que es lo que quiere: Lo sé, lo sé, suena sumamente obvio pero es un poco más que eso, ya que en ocasiones el cliente no tiene claro lo que quiere. Lo que se espera que se obtenga utilizando esta técnica es aterrizar las ideas del cliente para poder llegar a lo que quiere que su software realice.
Analiza los requisitos
El análisis de los requisitos es una parte crítica del proceso de desarrollo de software. Una vez que se han recopilado los requerimientos, es importante dedicar tiempo y esfuerzo a comprenderlos adecuadamente para poder satisfacer las necesidades del cliente. En el caso de nuestro proyecto de software de reservas de taxis, los requisitos comerciales incluyen aumentar la eficiencia de reservas en línea, mejorar la satisfacción del cliente y aumentar las reservas en un 30% en el próximo trimestre. Para lograr estos objetivos, debemos analizar cuidadosamente los requisitos y desarrollar una solución que cumpla con todas las necesidades del cliente, incluyendo una interfaz de usuario intuitiva, información clara sobre tarifas y horarios de viaje, y una integración sin problemas con los sistemas de facturación y administración de la empresa.
Diseño y arquitectura
Cuando hablamos de desarrollo de software, el diseño y la arquitectura son dos conceptos clave que marcan el inicio de todo el proceso. En esta etapa, los programadores se concentran en cómo se va a construir el software y cómo funcionará en términos generales.
En primer lugar, el diseño del software se enfoca en los aspectos funcionales que debe cumplir el sistema, los casos de uso, las interacciones entre los usuarios y el software, y los requerimientos del cliente. Los programadores deben ser muy minuciosos en este proceso, ya que el diseño determinará cómo se va a construir el software y cómo se verá su interfaz.
Una vez que se tiene un diseño sólido, es momento de considerar la arquitectura del software. La arquitectura es la estructura o el esqueleto del software y se enfoca en cómo se comunicarán las distintas partes del sistema. En esta etapa se definen las relaciones entre los distintos módulos, cómo se van a manejar los errores, y cómo se va a distribuir el software en la red o en distintas máquinas.
La arquitectura representa la primera decisión de diseño sobre el sistema y es uno de los puntos más importantes en el proceso de desarrollo. Es esencial que los programadores realicen un buen trabajo en esta etapa, ya que una mala arquitectura puede afectar la escalabilidad, el desempeño y la calidad del software a largo plazo.