Ingenieria De Requisitos

Ingeniería de Requisitos

Ingeniería de requisitos es el proceso de estudiar y refinar los requisitos de sistema, hardware o software. Y definiendo requisito, es una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo. Solamente el 28% de los proyectos en el año 2000 han sido completados satisfactoriamente, siendo los problemas con los requisitos la principal causa de fracaso. A pesar de la evolución de las herramientas y metodologías para la construcción de software sigue siendo el principal problema “el que construir”.

Un proceso de requerimientos mediocre puede en realidad resultar muy caro. Es rentable tomarse el tiempo que sea necesario para comprender el problema y su contexto, y obtener los requerimientos correctos desde el primer momento.

Los propósitos de los requerimientos:

 Permiten que los analistas expliquen cómo han entendido lo que el cliente y usuarios pretende del sistema.

 Indican a los diseñadores qué funcionalidad y características va a tener el sistema resultante.

 Establecen para los desarrolladores la especificación del comportamiento del sistema.

 Indican a los testeadores qué demostraciones llevar a cabo para que el cliente se convenza de que el sistema que se le entrega es lo que había solicitado.

Características de los Requerimientos:

 Correctos, sin errores.

 Consistentes.

 No ambiguos.

 Son completos:

1. Externamente completa si contiene todas las propiedades deseadas por el cliente.

2. Internamente completa si no existen referencias no definidas.

 Son realistas. Puede el sistema hacer lo que el cliente desea.

 Los R. Describen algo necesario para el cliente.

 Verificables. Un requisito es verificable si existe algún proceso finito de coste razonable que pueda probar que el producto software cumple con el requisito.

 Son rastreables. Trazables, el origen de cada requisito está claro y se posibilita la referencia de cada uno de estos requisitos en desarrollos futuros o incrementos de la documentación.

Los requerimientos se pueden clasificar como:

Según el nivel de descripción los requerimientos se clasifican en:

 Requerimientos del usuario: sentencias en lenguaje natural más diagramas con los servicios que se espera que el sistema provea y las restricciones bajo las cuales debe operar. Los pueden definir Clientes gerentes, Usuarios finales o Arquitectos del sistema.

 Requerimientos del sistema: servicios y restricciones operativas en detalle:

o Corresponde con la especificación funcional.

o Debe ser precisa.

o Los pueden definir: Usuarios finales, Desarrolladores o Arquitectos del sistema.

 Requerimientos Funcionales: Representan los servicios que el sistema debe proveer, cómo debe reaccionar ante los estímulos que recibe y cómo el sistema debe comportarse en situaciones particulares. Para determinar los requerimientos funcionales se deciden cuáles son los estados aceptables para el sistema.

o Cómo identificar requerimientos FUNCIONALES:

 Identificar actores (jugadores).

 Identificar necesidades funcionales.

 Revisar que no existan conflictos.

 Requerimientos NO Funcionales: Son las restricciones sobre los servicios o funciones ofrecidas por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares a respetar. Se refieren al sistema como un todo. Estas restricciones limitan la selección del lenguaje, plataforma, etc., sin embargo, la selección se realiza en la etapa de diseño.

o Cómo identificar requerimientos NO FUNCIONALES.

 Identificar necesidades no funcionales.

 Revisar que no existan conflictos.

Los requerimientos también se pueden encontrar y ordenar según el tipo de requerimiento:

Ambiente Físico:

o ¿Dónde está el equipamiento que necesita el sistema para funcionar?

o ¿Existe una localización o varias?

o ¿Existen restricciones ambientales: temperatura, humedad, o interferencia magnética?

Interfaces

o ¿La entrada proviene de uno o más sistemas?

o ¿La salida va a uno o más sistemas?

o ¿Existe una manera prescripta en que deben formatearse los datos?

o ¿Existe un medio prescripto que los datos deban utilizar?

Usuarios y factores humanos:

o ¿Quién usará el sistema?

o ¿Habrá varios tipos de usuarios?

o ¿Cuál es el nivel de habilidad de cada tipo de usuario?

o ¿Qué clase de entrenamiento requerirá cada tipo de usuario?

o ¿Cuán fácil le será a un usuario comprender y utilizar el sistema?

o ¿Cuán difícil le resultará a un usuario hacer un uso indebido del sistema?

Funcionalidad

o ¿Qué hará el sistema?

o ¿Cuándo lo hará?

o ¿Existen varios modos de operación?

o ¿Cómo y cuándo se puede cambiar o mejorar un sistema?

o ¿Existen restricciones de la velocidad de ejecución, tiempo de respuesta o rendimiento?

Datos:

o ¿Cuál será el formato de los datos tanto para entrada como para salida?

o ¿Cuán a menudo serán recibidos o enviados?

o ¿Cuán exactos deben ser?

o ¿Con qué grado de precisión deben hacerse los cálculos?

o ¿Cuántos datos fluyen a través del sistema?

o ¿Debe retenerse algún dato por algún período de tiempo?

Recursos:

o ¿Qué recursos materiales, personales o de otro tipo se requieren para construir, utilizar y mantener el sistema?

o ¿Qué habilidades deben tener los desarrolladores?

o ¿Cuánto espacio físico será ocupado por el sistema?

o ¿Cuáles son los requerimientos de energía, calefacción o acondicionamiento de aire?

o ¿Existe un cronograma prescripto para el desarrollo?

o ¿Existe un límite sobre la cantidad de dinero a gastar en el desarrollo o en hardware o en software?

Seguridad:

o ¿Debe controlarse el acceso al sistema o a la información?

o ¿Cómo se podrán aislar los datos de un usuario de los de otros?

o ¿Cómo podrán aislarse los programas de usuario de los otros programas y del sistema operativo?

...