Softqanetwork.com » Requisitos

Requisitos No-Funcionales (NFR)

Javierpello — Mon, 13 Jul 2009 10:12:22 +0000

Un requisito no funcional (NFR) especifica los criterios que se deben usr para juzgar el funcionamiento de un sistema (operation of a system), en lugar de un comportamientos específico (specific behavior). En general, los requisitos funcionales definen lo que el sistema debería de hacer, mientras que los requisitos no funcionales verifican cómo un sistema debería de ser. Requisitos no funcionales son a menudo llamados las “cualidades de un sistema”. Puede dividirse en dos categorías:

1. Execution qualities: como por ejemplo la seguridad y facilidad de uso, que son observables en tiempo de ejecución.
2. Evolution qualities, como por ejemplo el mantenibilidad, extensibilidad y escalabilidad, que están más vinculados a la estructura del sistema de software.

Algunos ejemplos de requerimientos no funcionles son: Accesibilidad, Auditoría y control, Disponibilidad, Copia de seguridad, Capacidad actual y previsiones, Certificación, Recuperación de Desastres, Eficiencia (consumo de recursos para la carga dada), Eficacia (resultante de rendimiento en relación con el esfuerzo), Extensibilidad, Interoperabilidad, Mantenimiento, Operatividad, Rendimiento / Tiempo de respuesta (véase el rendimiento de Ingeniería), Portabilidad, Recuperación, Fiabilidad (por ejemplo, Tiempo medio entre fallos – MTBF), Las limitaciones de recursos (la velocidad del procesador, memoria, espacio en disco, ancho de banda de red etc), Tiempo de respuesta, Robustez, Escalabilidad (horizontal, vertical), Seguridad, Estabilidad, Seguridad, testeabilidad…

Una buena definición de requirimientos no funcionales (NFR) es tán importante como los requisitos funcionales. Deben de ser apropiadamente definidos, analizados y trazados.

RQNG – Requirements Network Group

Javierpello — Tue, 30 Jun 2009 20:23:24 +0000

De RQNG o “Requirements Network Group” es una comunidad sobre la gestión de requisitos la cual incluye artículos, foro, herramientas, podcasts y un montón de cosas más. Podrás encontrar artículos sobre la “elicitation” de los requisitos, comparativas de herramientas, tipos de requisitos, responsabilidades de un BA…etc. Este grupo nace de la necesidad de juntar a toda la gente que se dedica a la gestión de requisitos.

Link: RQNG

Quality Assurance comienza en la “fase de Requisitos”

Javierpello — Mon, 21 Jan 2008 05:01:49 +0000

Los defectos más graves de cualquier software suelen ocurrir en la fase de análisis de requisitos y en muchos casos son defectos que no son detectados hasta fases finales del proyecto. Es por eso que debemos considerar Quality Assurance teams como una parte importante del equipo que debe de integrarse con el ciclo de desarrollo desde etapas tempranas, y no sólo en la fase final de pruebas.

¿Porque es tan importante? Muy sencillo, cuanto más tardemos en identificar estos defectos, más costoso será arreglarlo. Pero no sólo será costoso a nivel técnico, sino también económicamente ya que añadirá un coste extra al proyecto.

Es de gran importancia que el equipo de calidad participe en esta etapa de definición para buscar ambigüedades (que solamente haya una manera de interpretar un requisito y que sean entendibles), revisar que no haya conflictos entre ellos (tal vez la implementación de uno genera conflictos en otro), revisar la testabilidad (¿podemos realizar las pruebas necesarias?) y sobre todo revisar la viabilidad del coste.

Participar en la fase de requisitos nos permite también realizar el análisis de riesgo, que es de vital importancia si queremos mitigar futuros problemas que nos podemos encontrar, pero bueno, esto es otro tema aparte que hablaremos en otra ocasión.

Una vez tenemos los requisitos es de vital importancia tener una buena trazabilidad. Siempre debemos relacionar los casos de prueba con los requisitos y siempre deben de estar todos los requisitos debidamente cubiertos. Para hacer esto lo mejor es usar alguna de las muchas herramientas que hay en el mercado. Podemos usar el Mercury Quality Center, el qatrack, el Test Link, el Silk Central Manager o el Doors. No importa la herramienta que utilicemos, lo importante es tener una buena trazabilidad.

Comenzar en fases tempranas del ciclo de vida del software nos permitirá mejorara la calidad global de nuestras aplicaciones.