Inicio > Arquitectura, Desarrollo > Checklist de requisitos no funcionales

Checklist de requisitos no funcionales

lunes, 15 septiembre 2014, 10:30 Juan Francisco Adame Lorite Deja un comentario Go to comments

La presente entrada pretende ser un pequeño recopilatorio o lista de control de requisitos no funcionales. No es una entrada definitiva, y de hecho la idea es que vaya creciendo y actualizándose con el tiempo. Invito a todo el que quiera a que aporte correcciones, añadidos y observaciones.

Aunque me gustaría que fuese completa, no pretendo que sea exhaustiva. En las diferentes áreas y aspectos existen grupos de trabajo, estándares y procedimientos suficientemente completos si se quiere profundizar. Por ejemplo, el apartado de la seguridad, por su propia sensibilidad, está muy trabajado en este sentido y existen estándares como el ISO 27002 o la iniciativa OWASP que contienen checklists y mecanismos de certificación muy completos y detallados. De igual manera, algunos aspectos como Usabilidad son especialmente ambiguos y poco detallados debido a mi falta de experiencia en ellos.

Requisitos

Un requisito es una propiedad física o funcional de un sistema o solución que representa la necesidad, con sus restricciones y detalles, que debe cumplir por diseño, para que cumpla el fin o utilidad con el que fue creado. Es, junto con el alcance, lo que nos dice «qué tiene que hacer y cómo» nuestra solución para que sea útil y tenga valor.

Si nos ceñimos a la norma ISO/IEC/IEEE 29148:2011 los requisitos deben ser:

Necesarios. Deben definir una capacidad, característica o restricción sin la cuál el objeto del proyecto o producto sería incompleto. Aunque también pueden documentarse como opcional, deseables, negociables…
De libre implementación. Aún siendo suficientemente completo su definición debería ser completamente independiente del modo en que se implemente. En la medida que independicemos la fase de diseño de la de análisis, daremos más libertad a la implementación y obtendremos un mejor producto.
Unívocos. Que su definición solo pueda interpretarse de una única manera.
Consistentes. Que no entren en conflicto con otros requisitos.
Completos. Describe de manera completa, sin deficiencias ni necesidad adicional de información, el requisito. También es necesario especificar el nivel y alcance del requisito, no es lo mismo que el sistema por diseño sea capaz de cumplir el requisito, que verificar de manera continuada y rigurosa que el requisito se cumple durante la explotación del sistema.
Singulares. La definición incluye un único requisito. Lo que luego nos puede ayudar a auditar y validar cada requisito de manera única y sencilla.
Posibles. Que sean técnicamente posibles, dentro de las restricciones propias del proyecto. Esto incluye que sean posibles bajo los análisis de riesgo o coste-beneficio.
Referenciable. Que pueda ser referenciado o identificado de manera única, ordenada y estructurada. Que tenga una codificación correcta y unívoca.
Verificables. Que existan mecanismos que permitan verificar que realmente el requisito se cumple y criterios definidos para validarlo

Aunque me gustaría también añadir una propiedad que se mencionaba en el estándar original de esta norma (IEEE 830)

Modificable/gestionable. Que existan mecanismos para, cuando sea necesario y dentro de los procedimientos y formalismos establecidos para la gestión del producto o proyecto, poder modificar la definición del requisito, su eliminación o la inclusión de nuevos requisitos siguiendo los criterios anteriores.

Los requisitos pueden ser funcionales o no funcionales:

Funcionales. Hacen referencia a funciones o resultados esperados del sistema, enfocados en resolver el problema o la operativa para el que fueron creados. Responden a la pregunta de qué debe hacer el sistema.
No funcionales. Hacen referencia a detalles, aspectos, atributos o propiedades del sistema enfocados en cómo se debe resolver el problema o la operativa objeto del sistema. Responden a la pregunta de cómo lo debe hacer el sistema.

Se podría decir que los requisitos funcionales representan la parte del mundo real que toca al sistema y los no funcionales la parte tecnológica.

El análisis completo de los requisitos funcionales es relativamente sencillo. Si se nos pasa alguno, es muy seguro que estemos olvidando una funcionalidad relevante del sistema. Los cambios, añadidos y eliminaciones de requisitos funcionales suelen tener impacto en el alcance del proyecto. Además, son aquellos donde el usuario o los no especialistas en tecnología aportan mucho más, siendo el feedback practicamente suyo por completo.

Sin embargo, hacer un análisis completo de los requisitos no funcionales es más complicado. Primero, porque los actores que más feedback pueden dar en el análisis de los requisitos no funcionales son necesariamente aquellos con conocimientos técnicos; y normalmente no están en el conjunto de actores que conocen la naturaleza del problema, sino en el de los analistas.

En segundo lugar y más importante, porque se confunden con facilidad con decisiones propias del diseño. Algo, que aparentemente, parece una restricción o exigencia técnica, es solamente un efecto de una decisión de diseño tomada, y su obligación se debe a la vinculación con este diseño. Si cambiamos el diseño, muy posiblemente el requisito cambie o pierda consistencia. Si un requisito no funcional puede cambiarse por otro o cambia si cambiamos el diseño, es muy probable que estemos hablando de una consecuencia del diseño de la solución, y no de un requisito como tal. Este aspecto es importante, porque los requisitos no deben condicionar la implementación (solo su resultado o producto). Por eso, el exceso de definición en este aspecto, no es todo lo beneficioso que pensamos.

Desgraciadamente un requisito no funcional pasado por alto puede tener efectos catastróficos en un diseño o implementación ya iniciados. Esta lista, como checklist que es, tiene como único objetivo facilitar que el análisis de requisitos sea completo y evitar que se nos pase por alto algún aspecto que podría ser útil a nuestro análisis. La gran mayoría de los requisitos de esta lista no van a aplicar ni tener sentido para el problema que estemos analizando, pero lo importante es que no se nos pase aquel requisito que sí es relevante, beneficioso o imprescindible.

Por último, el conjunto de los requisitos no funcionales tienen unos efectos en el reparto de la carga de trabajo de implementación que, por lo general, son mayores que el de los requisitos funcionales. Cada diferente requisito no funcional debe abordarse como una solución separada, heterogénea y poco acoplada con las de otros requisitos, con las consecuencias que esto tiene en el desempeño y en la curva de aprendizaje. Las plataformas más generalizadas como son Java o Microsoft .net, han infravalorado este aspecto de manera habitual. En Java suelen ser implementados por librerías de terceros, que aveces tienen su clon en versiones oficiales posteriores de la plataforma; en el caso de .net, es común que cambien bastante de versión en versión. Nuevas plataformas como Django o Ruby on Rails, se centran precisamente en la reusabilidad del código relativo estos requisitos con bastante acierto, facilitando y focalizando el trabajo del desarrollador en lo funcional.

Checklist

Seguridad
- Seguridad física tanto de los sistemas como los medios de almacenamiento, líneas de comunicación, copias de respaldo.
- Cifrado de datos, tanto en las comunicaciones, como medios de almacenamiento, copias de respaldo.
- Auditabilidad, qué información y mecanismos existen para revisar la operativa de la solución, qué mecanismos garantizan la fiabilidad e integridad de esa información.
- Control de acceso, cómo se autentican los usuarios, cuál es el modelo de autorización, cuál es el ciclo de vida de las credenciales y sesiones
- Qué información está disponible en el acceso anónimo, qué damos a conocer de la organización, cómo protegemos nuestros sistemas del fingerprinting
- Cómo protegemos la integridad de la información, cómo validamos que sea correcta, cómo impedimos su manipulación no autorizada
- Cómo se gestionan los errores para que sean siempre controlados y no desvelen información no autorizada
- Cómo impedimos la operativa no autorizada, cómo protegemos la manipulación de peticiones o servicios qué información es insertable mediante formularios, servicios o uploads de ficheros
- Cómo se van a gestionar los incidentes de seguridad
- Si nos vamos a ceñir a algún tipo de guía de seguridad o si va a ser necesario certificar el sistema contra algún estándar u obligación legal, bien por criterios de calidad o por exigencia externa
Capacidad y Escalabilidad
- Qué niveles de rendimiento se necesitan:
  - Nivel mínimo aceptable para no mermar la experiencia de usuario
  - Número de usuarios concurrentes
  - Operaciones o transacciones por unidad de tiempo
- Qué niveles de capacidad se necesitan:
  - Requisitos de memoria principal
  - Requisitos de memoria secundaria, terciaria y offline
  - Cachés de memoria intermedios
  - Requisitos de capacidad de la copia de respaldo
  - Tamaños de colas de mensajes y de servidores antes del desbordamiento o descarte de la petición
  - Número máximo de peticiones concurrentes por servicio
- Si el sistema debe estar preparado para la escalabilidad vertical (más recursos por nodo) u horizontal (más nodos simultáneos por nivel)
- Plan de capacidad o cómo se espera que evolucionen los requisitos anteriores con el tiempo
Disponibilidad
- Qué componentes están replicados de manera activa o pasiva
- Ciclo de vida de la información
  - Cómo discurre la información desde que se procesa hasta que se almacena en la copia de respaldo
  - En qué componentes se almacena de forma persistente y en cuáles volátil
  - Dónde se pueden introducir sondas para extraer información, bajo qué criterios o restricciones
  - Cómo y cuándo se historifica la información, cómo se borra, soft-delete (marcado del registro como borrado) o hard-delete (borrado físico de la información)
  - Qué estados de la información pueden considerarse estables o coherentes (¿un rollback destruye la transacción o la devuelve a un punto estable intermedio anterior?)
- Cuál es el nivel de detalle o de precisión de la información
- Si las operaciones y servicios son idempotentes o puras
- La copia de respaldo:
  - Qué contiene la copia de respaldo
  - Cuál es el punto de recuperación objetivo
  - Cuál es el tiempo de recuperación objetivo
  - Cómo se cifra la copia de respaldo
  - Cómo se almacena de modo ordenado y seguro
  - Cómo se recupera dicha información
  - Cómo se destruye
- Plan de continuidad
  - Ante una caída de servicio cómo se espera continuar la actividad sin el sistema
  - Cuál es el tiempo máximo admisible de esta caída o cómo afecta a la actividad en función de este tiempo
- Plan de recuperación
  - Ante una caída de servicio cómo se espera recuperar el sistema para que dé servicio
  - Cuál es el tiempo de recuperación estimado
Mantenibilidad
- Qué arquitectura, framework, infraestructura de hardware o software base
- Qué metodologías de trabajo
- Qué estándares de codificación, nomenclaturas o convenciones
- Qué herramientas de ciclo de vida de producto, de construcción del producto, de integración continua o de chequeo de software
- Qué sistemas de versionado y nombrado de versiones, así como las políticas de versionado
- Qué políticas de adopción/integración de librerías y de software de terceros
- Qué políticas de gestión y configuración de entornos, qué políticas de gestión del cambio
- Cómo se gestionan de logs y trazas y con qué herramientas
- Qué políticas, procedimientos y herramientas de gestión de incidencias
- Qué documentación se va a generar y en qué formato
- Qué indicadores o estadísticas se monitorizan para conocer el estado o salud del sistema
Ciclo de vida
- Cómo se despliega/repliega
- Cómo se realizan las intervenciones o paradas del sistema
- Cómo se realizan el upgrade de componentes, así como de los datos y parametrizaciones del aplicativo
Robustez y estabilidad
- Cómo se gestionan los errores del sistema
  - qué información muestran al usuario
  - cómo se informa al usuario de la situación actual de su transacción y de cuáles son los siguientes pasos a seguir
  - qué información almacenan para la identificación y el análisis del error
- Cómo se recupera el sistema de los errores, cómo vuelve a un punto estable parcial (punto de recuperación intermedio) o total
- Cómo se gestionan los bugs desde su descubrimiento hasta su resolución, cómo se incluyen en las pruebas de regresión del sistema
Integridad y Consistencia
- Qué es una transacción, qué componentes comprende, cuál es su alcance
- Si se permiten faltas de sincronismo en la replicación de la información entre componentes (porque tarda en llegar de uno a otro) o de integridad (porque se permiten inconsistencias entre componentes)
- Qué controles de integridad y coherencia de datos
Integración
- Qué interfaces se definen con otras aplicaciones, de qué tipo
- Qué componentes ya existentes en la organización se utilizan, cuál es la política de reusabilidad
- Cómo de divide en módulos diferenciados, cómo se integran entre sí
Configuración
- Cómo se configura y parametriza
- Qué es parametrizable
- Cuál es el alcance de cada parámetro: del sistema, por entorno, por usuario, por región…
- Cuáles son los valores por defecto
Internacionalización
- Cómo se soporta el uso de múltiples idiomas, qué idiomas se soportan, cómo se traduce la solución a otros idiomas
- Cómo se parametrizan los diferentes aspectos regionales de formato numérico, fechas, aspecto…
- Cómo se soportan las zonas y usos horarios, cómo se gestionan los cambios de horario, qué convenciones tiempo se utilizan
Portabilidad
- Es necesario portar la solución a más de un entorno de ejecución o plataforma
Legales
- Cuál es la licencia o condiciones de uso de la aplicación
- Cuáles son y cómo afectan las licencias y condiciones de uso del software de terceros
- Qué requisitos o exigencias legales deben tenerse en cuenta
Operación
- Qué conjunto de operaciones o catálogo de servicios es necesario
- Cómo trabajan o que interfaz utilizan los operadores con la solución
- Qué requisitos técnicos necesitan los operadores
- Cómo se forma a operadores
- Qué nivel de demanda o disponibilidad de operadores requiere la operación de la solución
- Cómo y hasta qué nivel se automatizan las operaciones
Usabilidad
- Navegabilidad
  - Cuál es el mapa de navegación
  - Cuáles son los criterios de navegación (adelante, atrás, histórico, menus, error…)
  - Cómo se indica en todo momento en qué lugar nos encontramos
- Ayuda en pantalla
  - Cuál es el nivel de detalle de esa ayuda
  - Cuál es la terminología utilizada
  - Cómo se referencia a las diferentes partes del manual o documentación
- Aspecto
  - Colores, fuentes y maquetación
    - Cómo se usan para que estén acorde al sentido o significado de lo que muestran
    - Guía corporativa de diseño y estilo
    - Cómo se adapta el interfaz a dispositivos con poco tamaño o monocromo
  - Contenido
    - Cómo se maqueta y distribuye
    - Cómo es de legible el texto
    - Cómo se introducen y validan valores y formularios
    - De dónde se pueden obtener imágenes (banco corporativo de imágenes)
- Responsible design
  - Cómo se adecua, transforma y maqueta el contenido en los diferentes dispositivos y tamaños
- Qué estándares de formateado o visualización se siguen
- Qué cliente se utiliza
  - Qué navegadores son soportados
- Usabilidad
  - Cuál es el glosario de términos y comandos
  - Cómo se informa al usuario del estado actual de su operación:
    - En espera o ejecutando una acción, del estado de dicha operación y del tiempo estimado de espera
    - En la llegada de eventos
    - Del resultado de una operación
  - Cómo se avisa de errores, alertas y se solicitan confirmaciones
  - Cómo se adapta el UI para mostrar las opciones posibles
  - Cómo se definen los atajos y el uso del teclado
  - Cómo se define el uso del ratón o de un dispositivo multitáctil
  - Cómo se habilita el deshacer/rehacer de operaciones, cómo se gestiona ese default