Requisitos de usuario
El éxito de un proyecto de tecnología es el valor final del resultado para el negocio
Los criterios tradicionales para juzgar el éxito de un proyecto de tecnología ya no valen.
Una deficiente identificación de requisitos, la falta de objetivos claros y la inexistencia de análisis de usuario, son causas frecuentes del fracaso.
Los nuevos modelos de desarrollo, iterativos en su naturaleza, asumen que los requisitos van a cambiar en el tiempo por muchas razones.
Si cambia el modelo de desarrollo, la definición de éxito también debe hacerlo, y fundarse más en el valor final del resultado del proyecto para el negocio.
Características de un buen requisito
- Contiene una idea. Si un requisito tiene más de una, debería ser troceado en dos o más requisitos.
- Es claro. La idea del requisito no está abierta a interpretación, si no lo fuera, las partes deberán clarificarlo.
- Es genérico. Los requisitos deben contener información general, asegurando que las posibilidades del diseño no se encuentren limitadas.
- Es verificable. Al final del proceso es posible comprobar de forma fácil que el requisito se ha cumplido.
Ejemplos de requisitos de usuario:
- La página web deberá visualizarse correctamente para el 95% de nuestros clientes en México.
- Las noticias que no obtengan más de 50 visitas únicas al mes serán archivadas automáticamente.
- Las direcciones de Internet deberán estar bien construidas y en el idioma del usuario.
- Se deben reducir los errores al seleccionar los productos con la herramienta.
- El diseño visual debe cumplir la normativa corporativa existente.
- El nuevo diseño debe aumentar las visitas a la sección de productos.
Ejemplos de requisitos del sistema:
- El sofware debe ser escrito en un lenguaje compatible con el existente.
- La base de datos será Oracle 10 sobre HP-UX.
Identificar y verificar requisitos de usuario implica una relación y conocimiento entre el diseñador y los usuarios del producto. Si en tu empresa el diseñador «sólo pone colores», tienes muchos puntos para que tu proyecto no produzca ningún beneficio.
Referencias:
- IT projects: sink or swim, ITNOW 2000; 42: 24-26
- Project Management. Failure? Who says?, British Computer Society (BCS)
- Stevens, R. (1998) Systems Engineering, coping with complexity, Prentice Hall Europe.
Artículos relacionados: