INGENIERIA DE REQUISITOS

En la ingeniería de sistemas y la ingeniería de software la Ingeniería de requisitos comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos, esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.



Fases de implementación

Desde un punto de vista conceptual, las actividades son de 5 clases.

-Obtener requisitos: A través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus deseos.
-Analizar requisitos: Detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados por el diseño.
-Documentar requisitos: Igual que todas las etapas, los requisitos deben estar debidamente documentados.
-Verificar los requisitos: Consiste en comprobar el correcto funcionamiento de un requisito en la aplicación
-Validar los requisitos: Comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.

Técnicas principales

Entrevistas:
Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización
Talleres:
pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas.

Forma de contrato :
En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.


Objetivos medibles:
Los requisitos formulados por los usuarios se toman como objetivos generales,a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno
Prototipos:
Un prototipo es una pequeña muestra, de funcionalidad limitada.
Casos de uso:
Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas.