METODOS PARA LEVANTAR REQUERIMIENTOS DE UN SOFTWARE

¿QUE ES REQUERIMIENTO?

Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

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, con el énfasis puesto en los sectores más afectados o que harán un uso

más frecuente del nuevo sistema. Los requisitos que surgen de las entrevistas a menudo se contradicen unos a otros o se formulan desde la

ignorancia de los detalles del funcionamiento del sistema, sus potencialidades, interdependencias o limitaciones; por lo que se debe trabajar con los

mismos para corregir sus fallos. Las entrevistas pueden ser personales o grupales.

COMO SE APLICA UNA ENTERVISTA

1) PREPARACION DE LA ENTREVISTA:

DEDETERMINAR la posición que ocupa de la organización el futuro entrevistado, sus responsabilidades básicas, actividades, etc.

(Investigación).

PREPARAR LAS PREGUNTAS que van a plantearse, y los documentos necesarios (Organización).

FIJAR UN LIMITE DE TIEMPO y preparar la agenda para la entrevista. (Sicología).

ELEGIR UN LUGAR donde se puede conducir la entrevista con la mayor comodidad (Sicología).

HACER LA CITA con la debida anticipación (Planeación).

2) CONDUCCION DE LA ENTREVISTA

Explicar con toda amplitud el propósito y alcance del estudio (HONESTIDAD).

Explicar la función propietaria como analista y la función que se espera conferir al entrevistado. (IMPARCIALIDAD).

Hacer preguntas específicas para obtener respuestas cuantitativas (HECHOS).

Evitar las preguntas que exijan opiniones interesadas, subjetividad y actitudes similares (HABILIDAD).

Evitar el cuchicheo y las frases carentes de sentido (CLARIDAD).

Ser cortés y comedio, absteniéndose de emitir juicios de valores. (OBJETIVIDAD).

Conservar el control de la entrevista, evitando las divagaciones y los comentarios al margen de la cuestión.

Escuchar atentamente lo que se dice, guardándose de anticiparse a las

3) SECUELA DE LA ENTREVISTA

Escribir los resultados (Documentación).

Entregar una copia al entrevistado, solicitando su conformación, correcciones o adiciones. (Profesionalismo).

Archivar los resultados de la entrevista para referencia y análisis posteriores (Documentación).

4) D) RECABAR DATOS MEDIANTE LA ENTREVISTA

La entrevista es una forma de conversación, no de interrogación, al analizar las características de los sistemas con personal seleccionado

cuidadosamente por sus conocimientos sobre el sistema, los analistas pueden conocer datos que no están disponibles en ningún otra

forma.

5) DETERMINACION DEL TIPO DE ENTREVISTA

La estructura de la entrevista varia. Si el objetivo de la entrevista radica en adquirir información general, es conveniente elaborar una serie

de pregunta sin estructura, con una sesión de preguntas y respuesta libres 

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en

las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas 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. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión,

liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

COMO SE APLICA UN TALLER

1. Nombre: Taller Estructurado de Requerimientos

2. Descripción: Reunión especial dedicada a examinar y discutir un grupo de Requerimientos

3. Elementos: Paquete de Requerimientos, Alcance, Comprensión, Confirmación y Aprobación de Requerimientos

4. Roles:

A. Autor.- El analista de negocio responsable de recolectar los requerimientos. Objetivo: contestar preguntas,

escuchar comentarios y sugerencias, realizar cambios a los requerimientos

B. Experto(s).- Persona o personas especializadas en la Solución. Objetivo: realizar preguntas, escuchar

comentarios y sugerencias, analizar información, determinar viabilidad

C. Moderador.- Facilitador Neutral. Objetivo: facilitar la sesión, mantener el foco en los requerimientos, imponer

la participación, reglas del juego y disciplina, vigilar el cumplimiento de la agenda, facilitar el proceso de

toma de decisiones y consenso

D. Escribano: Persona que registra los resultados de la sesión. Objetivo: Documentar todos los comentarios,

sugerencias y asuntos surgidos en la sesión

E. Participantes : Cualquier otra persona involucrada en el proyecto. Objetivo: Leer la documentación,

Presentar y Discutir Comentarios, Realizar Preguntas, Sugerir Cambios a Requerimientos

F. Autorizador: Persona con facultades para aprobar cambios a los requerimientos. Objetivo: Aprobar los

Requerimientos durante o al final de la sesión.

5. Reglas del juego

A. Definir cuáles son las condiciones de la reunión, por ejemplo: no influencia de puestos jerárquicos,

participación activa, la duración de las discusiones, que se hace si un tema no se resuelve en el tiempo

límite, uso de un “parking lot”etc.

6. Entregables

A. Qué resultados debe de generar la reunión: requerimientos confirmados y aprobados, minuta de la reunión,

relación de preguntas, supuestos, comentarios, temas pendientes, sugerencias y pendientes del “Parking

Lot”, etc.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

Prototipos

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de

los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

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. Dado que el

propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y

determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los

desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta

técnica se enfrenta a los siguientes peligros potenciales.

A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente

cuáles son los requisitos.

Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un

sistema que sirva el proceso del negocio.