5.1 Funcionales
“Los requerimientos funcionales establecen lo que debe hacer el sistema o las acciones que debe llevar a cabo para satisfacer la razón fundamental de su existencia” (Robertson y Robertson, 2013).
La ingeniería de requerimientos debe detallar los requerimientos funcionales; principalmente porque es lo mínimo que se espera que haga y porque permiten explicar a los desarrolladores qué es lo que deberán construir.
Parte fundamental de la descripción de los requerimientos funcionales es que se mantengan independientes de la tecnología a utilizar. Será trabajo del diseñador ubicar la tecnología más adecuada que soporte las funciones descritas.
Cada requerimiento debe ser descrito de forma precisa, entendible, comunicable y verificable. La mejor forma de hacerlo es a través de los siguientes aspectos.
Haz clic en la imagen para revisar en qué consiste cada aspecto
Excepciones y alternativas
Ver
5.2 No funcionales
Los requerimientos no funcionales establecen las características del desempeño que deberá demostrar el sistema en operación. Son tan importantes como los requerimientos funcionales, porque pueden ser un factor decisivo en la aceptación del usuario final.
Considera el siguiente escenario:
El gerente de una empresa está revisando por qué los usuarios se resisten a utilizar el nuevo sistema. El gerente conoce de antemano que el sistema realiza todo lo que se espera que haga, sin embargo al entrevistar a los usuarios se da cuenta dónde está el error. Las computadoras de los usuarios se encuentran ya saturadas con algunos sistemas con los que han estado trabajando durante varios años. Al instalar el nuevo sistema notan que es bastante lento. Procesar una orden es más tardado que antes, por lo que los usuarios prefieren hacerlo manualmente que utilizar el sistema.
Este escenario se presenta porque los requerimientos no funcionales fueron ignorados. No se consideró medir el desempeño en las computadoras actuales de los usuarios, provocando molestia y resistencia al cambio.
Los requerimientos no funcionales complementan a los requerimientos funcionales.
Es obvio que es necesario especificar las acciones que debe realizar el sistema (requerimientos funcionales), pero también qué características de desempeño se espera que tenga (requerimientos no funcionales) una vez puesto en operación.
Según Robertson y Robertson (2012), los requerimientos no funcionales describen las cualidades que debe tener el producto o, dicho de otra manera, de lo bien que hace las cosas que hace.
Estos requerimientos permiten que el producto sea atractivo, confiable, rápido o seguro.
Por ejemplo, es posible describir requisitos sobre los tiempos de respuesta del sistema en diferentes estados, los límites de precisión al realizar cálculos, tener un aspecto o paradigma de uso particular, etc.
En muchos productos de consumo los requerimientos no funcionales generan características específicas que se traducen en ventajas competitivas. Por ejemplo, el mercado tiene una clara preferencia por el iPad® como dispositivo tipo tableta, debido principalmente a su funcionamiento intuitivo, pues hasta un niño de 4 años podría utilizarlo sin ninguna instrucción. Por su parte la página de Amazon® crea una tienda virtual que es preferida no sólo porque funciona bien, sino porque hace que la experiencia de compra sea única.
Los requerimientos no funcionales son propiedades que debe tener la funcionalidad del producto de software, por ejemplo:
- Look and Feel: es la parte visual y experiencia de uso del producto.
Ejemplo: el producto debe cumplir con los estándares de imagen corporativa.
- Usabilidad: es la facilidad de uso de las diferentes funciones del software.
Ejemplo: el producto debe ser utilizado sin dificultad por usuarios con experiencia limitada en computadoras.
- Rendimiento: tiene que ver con atributos como la rapidez de respuesta, uso eficiente de recursos, disponibilidad de los servicios, precisión de sus procesos, confiabilidad y latencia.
Ejemplo: el sistema deberá soportar 300 usuarios concurrentes.
- Entorno operacional: el entorno o ambiente de funcionamiento del producto.
Ejemplo: el producto deberá ser portátil y soportar temperaturas extremas.
- Mantenibilidad y soporte: permite realizar cambios futuros o adecuarse a nuevas necesidades con facilidad.
Ejemplo: el sistema deberá mostrar el contenido en español e inglés y podrá ser traducido en otros idiomas con facilidad.
- Seguridad: mantiene la confidencialidad, integridad y disponibilidad de los datos.
Ejemplo: el sistema deberá obligar a los usuarios a generar claves de acceso robustas.
- Legales: normas y reglas que debe cumplir el software.
Ejemplo: el producto deberá cumplir con las especificaciones de generación de factura electrónica del SAT, descritas en el diario oficial de la federación del 30 de diciembre de 2013.
Recuerda que cada uno de estos requerimientos debe ser acompañado de una descripción breve, la razón fundamental, el criterio, restricciones y excepciones. Esto permitirá tener una mejor comprensión de cada uno.
5.3 Reusabilidad de requerimientos
Sin duda cada proyecto de desarrollo de software es único; sus objetivos y personas involucradas cambian, por lo que el resultado necesariamente será diferente. Sin embargo, con el tiempo los productos son utilizados de la misma manera entre organizaciones del mismo giro, entonces es posible ahorrar esfuerzos y tiempo cuando hay requerimientos similares en varios proyectos.
Imagina que fuiste parte del proyecto de desarrollo de software para una tienda de conveniencia. El producto les permite a los cajeros ingresar las ventas diarias en terminales con pantallas táctiles. Esto significa que se especificaron requerimientos como base de ese desarrollo, que pueden aplicar para otro proyecto, por ejemplo una gasolinera. No es que se utilicen exactamente los mismos, sino que pueden ser analizados y complementados por el equipo del proyecto para el desarrollo.
La reusabilidad de requerimientos permite al equipo avanzar rápidamente y definir detalles de funcionalidades que al nuevo grupo de usuarios les son más importantes. Esto va generando experiencia en el equipo de desarrollo y puede crear una librería de requerimientos de reuso.
Robertson y Robertson (2012) nos hacen una aclaración: “La reutilización exitosa de requerimientos comienza con tener una cultura organizacional que conscientemente impulse a reutilizar en lugar de reinventar”. Finalmente, lo que necesitamos es que se produzca un software de calidad que sea útil para el usuario y se debe utilizar toda la experiencia generada de proyectos anteriores.
Patrones
Cualquier patrón sirve de guía para repetir una acción y obtener un resultado similar. Un sastre utiliza patrones para confeccionar a medida algún traje. En el desarrollo de software encontrar un patrón en las funciones que se requieren en un sistema sirve también como base para la reutilización y permite describir con precisión cada requerimiento que será documentado en las especificaciones.
El ingeniero de requerimientos debe tener la capacidad de encontrar los patrones entre diferentes proyectos a través de la abstracción de las necesidades que se repiten.
