Con la moda de arquitectura (aunque es indiscutiblemente necesario tener un arquitecto en la organización… jejeje), se ha tomado mas en serio el tema de los REQUISITOS NO FUNCIONALES (aunque no lo crean, se deben tener en cuenta al hacer software), hoy voy a dar unos primeros conceptos para estos requisitos no funcionales.
Según Somerville, los requisitos no funcionales definen propiedades y restricciones del sistema, - aunque la palabra restricciones puede ser ambigua, porque en otros textos, una restricción es algo impuesto por la organización, desde el punto de vista de software, pero sigamos con Somerville. Algunos ejemplos de estos requisitos no funcionales son: Tiempo de Respuesta, Requisitos de almacenamiento, confiabilidad.
Estos requisitos pueden ser mas críticos que los requisitos funcionales, ya que son normalmente a los que debe apuntar la arquitectura y si estos no son cumplidos, el software puede no funcionar o el cliente simplemente no acepta el producto (OJO: No se dejen meter goles con las definiciones de requisitos no funcionales).
Dentro de estos requisitos no funcionales encontramos una clasificación que nos permite identificarlos mas fácilmente (cuando se definen taxonomias de lo que sea lo que se busca es entender mejor el concepto, DIVIDE y CONQUISTARAS; y les puedo garantizar que una clasificación no acelera la terminación del proyecto, pero permite trabajar mejor). Podemos encontrar tres grupos de requisitos no funcionales. Los requisitos de producto, los cuales especifican que el producto debe comportarse de una forma en particular. Ej. Velocidad de ejecución, confiabilidad, escalabilidad y otras tantas que en la parte 2 de esta nota explicaré.
Los requisitos Organizacionales (y aquí nos empezamos a perder porque solo pensamos en bolear código), los cuales son consecuencia de políticas y procedimientos organizacionales. Ej. Delivery, Requisitos de Implementación, Estándares.
Y los requisitos Externos, y estos si se pierden por causa del “síndrome del estudiante” (Otro concepto que explicaré después, pero que tiene que ver con la teoría de los proyectos que dice mi amigo John, donde al principio del proyecto nos dormimos, para después estar apurados), estos requisitos emergen de factores que son externos a los sistemas y sus procesos de desarrollo. Ej. Interoperabilidad, Requisitos Legislativos (Privacidad y Seguridad), Requisitos ETICOS Y MORALES.
Los requisitos no funcionales pueden ser difíciles de encontrar y enunciar de forma precisa y los requisitos que son imprecisos son difíciles de verificar. Por eso se deben definir muy bien las metas (OJO, diferentes a los objetivos… yo creía que eran lo mismo… ahí que arreglar el Enterprise Architect, Ej: El objetivo es medible, la meta es un esfuerzo) porque estas ayudan a los desarrolladores a transmitir las intenciones de los usuarios del sistema y a verificar los requisitos no funcionales.
Podemos ver que las metas y los requisitos no funcionales toman la siguiente forma:
Meta: Intención general de usuario, tal como facilidad de uso.
Requisito no funcional verificable: Un enunciado usando alguna MEDIDA que pueda se objetivamente probada (Y AQUÍ ES DONDE SE METEN LOS GOLES).
Ejemplos:
Una meta del sistema: El sistema debe ser fácil de usar por controladores experimentados y debe estar organizado de tal manera que los errores de usuario sean minimizados (ASI LO ENTREGAN… increíble!!!!).
Un requisito no funcional verificable: Los controladores experimentados deben ser capaces de usar todas las funciones del sistema después de un total de dos horas de entrenamiento. Después de este entrenamiento, el número promedio de errores generados por estos usuarios experimentados no deberá exceder de 2 por día. (ASI LO DEBEMOS TRADUCIR)
Si lo ven bien, si cumplimos este requisito no funcional, indiscutiblemente podemos cumplir con la meta, y por otro lado tenemos una base para iniciar un TRADE-OFF (negociación) con el cliente. Para que se entienda mejor, los requisitos no funcionales pueden presentar conflictos entre ellos, algunas veces cumplir un requisito NF al 100% implica impactar otro requisito. Ej: Portabilidad - Performance. Escalabilidad – Administrabilidad.
Requisito NO FUNCIONAL MAL ESCRITO: El sistema debe ser escalable. (Cuidado con los goles).
Otros ejemplos:
Requisito NF de producto: La interfaz de usuario para el sistema X, debe ser implementada como HTML simple sin FRAMES o Applets de Java (Para que tengan en cuenta a los diseñadores también).
RQ NF Organizacional: El proceso de desarrollo del sistema y los documentos entregables deberán estar conforme al proceso y entregables definidos en XYZ_1234. (Uichhhh… este no lo he visto escrito en un catalogo de requisitos).
RQ NF Externo: El sistema no revelará información personal acerca de los clientes aparte de su nombre y número de referencia a los operadores del sistema. (Aquí es donde dicen, “pero eso es obvio”… claro que puede ser obvio… pero hay que escribirlo).
(NOTA ADICIONAL: Escribir requisitos como lo especifica el estándar IEEE 830-1998, es decir, empezando “El sistema deberá”, no nos permite escribirlos de forma fácil, porque nos lleva a pensar inmediatamente en el software (es decir, debemos trabajar sobre lo no construido) y no nos dan idea de lo que realmente necesita el usuario (Por eso se deben utilizar Casos de Uso o Historias de Usuario).
posted by Unknown @ 11:19 a. m.
8 Comments:
interesante y util
muchas gracias
un saludo
Hola, me llamo Julian y estudio Sistemas en EAFIT, actualmente me encuentro desarrollando la etapa de requisitos en un proyecto y me parecio muy bacano este articulo porque me ayudo a clarificar algunos conceptos acerca de los requisitos no funcionales. Muchisimas Gracias!!.
Saludos.
Muchas gracias, muy interesante. En el fondo el eterno dilema entre "lo que el cliente quiso decir que deseaba" y "lo que el idiota del informático no entendió" en fin, espero que estas lecciones nos ayuden a hacerle vislumbrar al cliente quién es el idiota XD
Hablando en serio, muchas gracias
no se si lo que usted entendio fue lo que yo quise decir ....dilema mejorado!! muy interesante tu articulo muchas gracias
Este comentario ha sido eliminado por el autor.
Bajo mi punto de vista, define de manera exacta la diferencia entre requisito funcional y no funcional algo que no siempre es fácil de hacer. Muchas gracias por tu aporte, me ha ayudado a entender la diferencia necesaria para realizar un trabajo de sistemas de información.
Gracias viejo, me fue de mucha utilidad. Un abrazo desde Córdoba, Argentina.
Huy y Yo cabeciandome...muy Buen Aporte DIVIDE Y VENCERAS!!
Publicar un comentario
<< Home