View
1.074
Download
3
Category
Preview:
Citation preview
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.
Recommended