Levantamiento de requisites

de software
Actividad TI037 - Análisis y Diseño Integral de Sistemas y Requerimientos
MDEISW - Máster en Dirección Estratégica en Ingeniería de Software
Rosa Angela Parra Pachón
 Objetivo
 Dar solución al caso práctico propuesto en la actividad TI037 - Análisis y
Diseño Integral de Sistemas y Requerimientos; con respecto al levantamiento
de requerimientos en cuanto a sus técnicas, limitantes y metodologías
aplicadas.
 Introducción
El propósito principal de la construcción o adecuación de aplicaciones de software
es cubrir las necesidades de negocio y lograr cumplir las expectativas del cliente;
así como acatar las normas contractuales, legales o reglamentarias que existan;
es por esto que la etapa de levantamiento de requerimientos es crítica y
fundamental para definir el alcance y estrategia del proceso de desarrollo.
El lograr extraer los requerimientos de forma adecuada y llevarlos posteriormente
a requisitos, traducirlos en las condiciones que se deben cumplir para garantizar
que el sistema es correcto y adecuado para su uso.
Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y cada
cambio involucra un costo; por esto los artefactos generados dentro de la etapa de
definición de requerimientos y requisitos debe ser custodiada en un esquema de
administración de la configuración.
 Conceptos clave

➢ Una condición o necesidad de un ➢ Condición o capacidad que debe

usuario para resolver un problema ser satisfecha o que debe poseer
o alcanzar un objetivo. una solución o componente para
satisfacer una necesidad.
➢ Una solicitud que podrá resolver
una problemática que existe ➢ Declaración que traduce o expresa
actualmente en una organización. una necesidad y sus restricciones
y condiciones asociadas.
➢ Una necesidad expresada de alto
nivel que presenta una dificultad,
restricción u oportunidad del
negocio y que require ser resuelta
 Transformar necesidades en
requisitos
➢ La definición de los requisitos comienza con las intenciones de las partes interesadas
(necesidades, metas u objetivos), que evolucionan en una declaración formal antes de
llegar como requisites válidos de las partes interesadas.
➢ Las intenciones del interolocutor inicial, no sirven como requerimientos de las partes
interesadas, ya que a menudo carecen de definición, análisis y consistencia y
factibilidad.
➢ Los requerimientos de las partes interesadas se transforman luego en requisitos de
Sistema, la práctica consistente ha demostrado que este proceso require iterativas y
recursivas en paralelo con otros procesos del ciclo de vida a través de la jerarquía de
diseño del Sistema.
➢ La aplicación recursiva de los procesos generará requisites de elementos de Sistema
de nivel inferior.
Importancia de la especificación
 ¿Cuáles son las principales dificultades
encontradas en la fase de levantamiento
de requisitos?
¿Cuáles son las principales dificultades encontradas en la fase
de levantamiento de requisitos?

Fallas de comunicación y baja claridad en la definición de necesidades

❖ Dado que el cliente es quien tiene el contexto y detalle de la necesidad; se hace
fundamental que se tenga una comunicación asertiva con el fin de poder entender y
orientar incluso al cliente para en conjunto lograr desglosar las necesidades.
❖ Normalmente los clientes se expresan en términos muy generales de lo que
necesitan del nuevo programa, sin saber expresar del qué debe hacer el software
(producto solución), donde sus peticiones con frecuencia suelen ser inalcanzables
porque no saben qué es factible y qué no lo es.
❖ Es necesario fortalecer vínculos de comunicación entre clientes, analistas y
desarrolladores; en las metodologías ágiles se habla del poder de los 3; donde en
conjunto, teniendo los 3 puntos de vista es más fácil llegar a consenso y lograr el
entendimiento de las necesidades más claramente; para así obtener un mejor
aprovechamiento, entendimiento, y rendimiento al momento que entre en ejecución
el sistema que se esté desarrollando.
❖ El ingeniero de requisitos, analista o rol asignado para el levantamiento de requisitos
debe conocer y manejar el lenguaje de negocio ya que el nivel de conocimientos
técnicos y la experiencia en el campo determinan la eficiencia de las actividades y el
mejor entendimiento de las necesidades.
¿Cuáles son las principales dificultades encontradas en la fase
de levantamiento de requisitos?

Falta de documentación o información para delimitar

el alcance:
❖ Los clientes no tienen una comprensión clara de los
requisitos del sistema, incluyendo el alcance del
mismo, las principales características funcionales y los
atributos no-funcionales.
❖ Las necesidades y la comprensión de los usuarios
cambia constantemente.
❖ Los ingenieros de software no tienen suficiente
acceso al conocimiento y a la experiencia del dominio.
❖ No existe documentación o está desactualizada la
documentación de la necesidad.
¿Cuáles son las principales dificultades encontradas en la fase
de levantamiento de requisitos?
❖ Dentro del proceso de levantamiento de requisitos se hace fundamental cumplir con las características básicas:
Correctitud - conciso
• Un requisito es concreto si
y solo si refleja alguna
necesidad real de la
organización o
cumplimiento legal.
• Cada requisito debe ser
revisado y aceptado por
los interesados.
• Cada requisito tiene
definidas entradas, salidas
y relación con otros
requisitos.
• El requisito debe ser
necesario, esto es que
defina una capacidad
esencial, característica,
restricción y /o un factor
de calidad.
Consistente y único No ambigüedad Verificable y medible
• Los requisitos deben ser • Cada requisito debe tener • El requisito debe ser
coherentes con los una sola interpretación completo, no requiere
requerimientos y con otros • Debe ser expresado de ampliaciones ni
documentos de forma clara, sencilla y sin aclaraciones.
especificación. dar espacio a suponer. • Debe ser factible
• Los requisitos deben estar • Debe especificar su técnicamente
libres de conflictos y comportamiento ante los • Debe ser trazable, esto es
contradicciones con otros diferentes eventos. rastreable a lo largo del
requisitos. proyecto
• No deben existir dos • Debe ser verificable, esto
requisitos iguales es que tenga forma de ser
probado
• Debe ser medible con
respecto a las
necesidades del negocio
¿Cuáles son las principales dificultades encontradas en la fase
de levantamiento de requisitos?

❖ Falta de claridad en la tipología de requisitos, es importante identificar los difetentes niveles de

los requisitos:
Beneficios de una buena definición
de requisitos
❖ Disminución de errores y reprocesos en la codificación del software
❖ Claridad en el alcance del proyecto desde sus inicios
❖ Soluciones enfocadas en lo que realmente necesita el negocio
❖ Clientes satisfechos
❖ Gestión de necesidades del proyecto en forma estructurada
❖ Sistemas de información que apoyan en desarrollo y crecimiento de la organización
❖ Documentación de los sistemas de información actualizada
❖ Disminución de costos y de retrasos del proyecto
❖ Mejor comunicación entre equipos
❖ Evitar rechazos de usuarios finales
¿Cuáles son las principales técnicas para
el levantamiento de requisitos? Explique
brevemente cada una de las técnicas
¿Cuáles son las principales técnicas para el levantamiento de requisitos?
Explique brevemente cada una de las técnicas
Revisión documental
• Consiste en obtener la
información sobre los
requerimientos funcionales y
requerimientos no funcionales de
software a partir de documentos
que ya están elaborados.
• Es útil cuando los expertos de
negocio no están disponibles
para ser entrevistados o ya no
forman parte de la organización.
• Utiliza la documentación que sea
relevante al requerimiento que
se está levantando.
• Ejemplos de documentación:
Planes de negocio, actas de
constitución de proyecto, reglas
de negocio, contratos,
definiciones de alcance,
memorandos, correos
electrónicos, documentos de
entrenamiento, entre otros.
Observación Entrevistas
• Consiste en estudiar el entorno de
trabajo de los usuarios, clientes e • Se lleva a cabo mediante conversaciones estructuradas donde es fundamental que la
interesados relevantes de proyecto relación con el cliente este basada en la confianza para dar a conocer la información
(Stakeholders). de la manera mas detallada
• Es una técnica útil cuando se está • . Son útiles para obtener y documentar información detallada sobre los
documentando la situación actual requerimientos y sus diferentes niveles de granularidad.
de procesos de negocio. • Se recomienda:
• Puede ser de dos tipos, pasiva o
• Estudiar el tipo de personas a las cuales se les realizará la entrevista.
activa. • Estudiar como será el entorno donde se llevara a cabo la entrevista para identificar
• En observación pasiva, el
que tan confortables estarán las personas y así obtener la información de la manera
observador no hace preguntas, más eficiente.
limitándose solo a tomar notas y a
• Estudiar como es la manera de hablar de las personas individualmente o en un
no interferir en el desempeño equipo de trabajo.
normal de las operaciones.
• Verificar que las personas tengan la disponibilidad para dar a conocer las
• En observación activa, el necesidades que posterior a esto se puedan convertir en requerimientos.
observador puede conversar con el
usuario. • Revisar como es la relación del cliente con la organización que realizará la
identificación de los requerimientos, esto con el fin de facilitar el trabajo y la
disposición de ambas partes.
• Entender que es importante obtener la mayor información para la definición de los
requerimientos, teniendo en cuenta que nada es obvio para las organizaciones de
desarrollo de software
¿Cuáles son las principales técnicas para el levantamiento de requisitos?
Explique brevemente cada una de las técnicas
Mesas de trabajo
• Es una técnica efectiva para obtener
información rápidamente de varias
personas.
• Es recomendable tener una agenda
predefinida y preseleccionar a los
participantes, siguiendo buenas prácticas
para reuniones efectivas.
• Se puede utilizar un facilitador neutral y un
transcriptor (que no sea el mismo
• facilitador).
• Se puede utilizar un material común sobre
el cual enfocar la atención y conversar,
por ejemplo una presentación con un
desglose del proceso que se está
estudiando o un flujograma.
• Se pueden combinar con otras técnicas
como pueden ser las entrevistas y
cuestionarios.
Lluvia de ideas
• Esta técnica es abierta y se utiliza para
explorar necesidades iniciales con la
ayuda de la identificación de ideas de
todas las personas que hacen parte del
equipo de apoyo para la identificación de
los requerimientos. Es utilizada para
investigar nuevos servicios o necesidades
que no son claramente identificadas.
• Algunos Tips para tener en cuenta cuando
se realice una lluvia de ideas:
• Escoger un sitio tranquilo que permita que
las personas involucradas se sientan
cómodas y dispuestas para dar a conocer
sus ideas.
• Tomar la iniciativa para iniciar una reunión
enfocada en la confianza.
• Tomar nota de las ideas que las personas
expresan en los equipos de trabajo.
• Tener una preparación sobre el tema que
se va a desarrollar en la lluvia de ideas
Historias de usuario
• Las historias de usuario, son una
aproximación simple al levantamiento de
requerimientos de software, en la cual la
conversación pasa a ser más importante
que la formalización de requerimientos
escritos.
• Es recomendable que sean escritas por el
mismo cliente o interesado (con apoyo del
facilitador si es necesario), con énfasis en
las funcionalidades que el sistema deberá
realizar.
• Al redactar una historia de usuario deben
tenerse en cuenta describir el Rol, la
funcionalidad y el resultado esperado de
la aplicación en una frase corta.
• Las historias de usuario son una de las
técnicas más difundidas para levantar
requerimientos de software en
metodologías ágiles.
Encuestas o cuestionarios
• Esta técnica puede ir dirigida a un público
específico o general, lo que permite
obtener una información mayor, ya que
se tiene la posibilidad de involucrar más
personas para el desarrollo de los
cuestionarios y que estos tengan
diferentes puntos de vista.
• Lo importante es tener en cuenta que se
debe tener un mayor cuidado en la
selección de los encuestados y de la
forma en que se pregunta para obtener
respuestas concretas y confiables
• La clave para el éxito es que tengan un
propósito y audiencia claramente definida,
establecer fechas topes para llenar la
encuesta, con preguntas claras y concisas
• Deben enfocarse en los objetivos de
negocio que se necesitan identificar.
• Pueden apoyarse con entrevistas de
seguimiento con usuarios individuales.
• Pueden contener tanto preguntas
cerradas como preguntas abiertas.
JAD (Joint Aplicación Diseño) principios
básicos y sus principales etapas
 JAD (Joint Aplicación Diseño) definición y objetivos

Definición
JAD es una técnica de definición de requisitos y de
diseño de la interfaz de usuario, basada en reuniones
participativas entre clientes, directiva y desarrolladores.
En dicha reunión los temas a tratar se centran más en
el negocio que en el asunto técnico. Lógicamente está
más orientado a proyectos de cliente (o bien sistemas a
medida, como también se los conoce), y permite
recolectar requisitos eficientemente.
Objetivos
➢Acelerar el diseño de soluciones informáticas
➢Utilizar la participación del cliente y dinámica de
grupo para representar con precisión la visión del
usuario y desarrollar conjuntamente una solución.
➢Identificar problemas y participantes
➢Clarificar los requerimientos
➢Cuantificar procesos e información necesitados

Perfiles
Moderador (líder Jad) con amplios conocimientos de la metodología de trabajo, dinámica de grupos,
psicología del comportamiento, así como de los procesos de la organización objeto del estudio.
Promotor persona que ha impulsado el desarrollo.
Jefe de proyecto, responsable de la implantación del proyecto.
Especialista en modelización responsable de la elaboración de los modelos en el transcurso de la sesión.
Desarrolladores aseguran que los modelos son correctos y responden a los requisitos especificados.
Usuarios responsables de definir los requisitos del sistema y validarlos.
 JAD (Joint Aplicación Diseño) Dinámica de las sesiones

Para llevar a cabo una sesión JAD, es necesario realizar una
serie de actividades antes de su inicio, durante el desarrollo
y después de su finalización. Estas son
Inicio: se define el ámbito y la estructura del proyecto, los
productos a obtener, se prepara el material necesario para
la sesión, se determina el lugar donde se van a llevar a
cabo, se seleccionan los participantes y se sugiere una
agenda de trabajo.
• Desarrollo: se identifican las salidas del proyecto y se
debe conseguir el consenso entre los participantes de
modo que se materialice en los modelos.
En las sesiones de trabajo tipo JAD se distinguen dos tipos
de productos:
• De preparación donde se incluye, entre otros, la historia y
contexto del proyecto, los objetivos y límites, las
actividades del entorno del negocio que pueden afectar al
éxito del proyecto y los beneficios.
• De resultado de las sesiones de trabajo, que se
establecen con anterioridad

• Finalización: se valida la información de la sesión y se

generan los productos de la metodología de trabajo
propuesta. Si fuera necesario se integran los productos de
salida.
 JAD (Joint Aplicación Diseño) Principios básicos

Trabajo de grupo (gerentes, usuarios y profesionales
del área) en sesiones para analizar los
requerimientos, generar ideas innovadoras y tomar
decisiones que den forma al diseño del nuevo
software
Dinámica
De grupos
JAD introduce numerosos tipos de ayudas visuales
para hacer los conceptos de diseño más tangibles.
Ayudas Utilizar prototipos, gráficos, transparencias, pizarras,
visuales proyectores o cualquier dispositivo para presentar
información, sirve para comunicar y validar mejor las
ideas durante el proceso de diseño.

• La aplicación de JAD produce un

documento, cuyo propósito es
registrar los resultados obtenidos de
tal manera que los usuarios y
profesionales de sistemas de
información puedan entender las
decisiones tomadas.
• Este método de documentación
asegura que el contenido y formato
del documento sean completamente
familiares a los usuarios y • Una vez definido el panorama del sistema, cada nivel de
profesionales de sistemas.
• Todas las ideas y decisiones
expresadas en el documento son
generadas en las sesiones de grupo.
• La familiaridad del formato de los
documentos lleva a un proceso de
revisión más efectivo.
Principios
• Emplea análisis top-down, y tareas bien definidas para
Proceso llevar a cabo la definición de objetivos, requerimientos y
racional y diseño externo.
organizado • Este análisis, consiste en estudiar primero las áreas de
alto nivel y más generales antes que los detalles.
Documentación • Manejar cada nivel de detalle secuencialmente ayuda a
WYSIWYG asegurar un análisis completo por dos razones: primero,
el análisis top-down reduce en gran forma la posibilidad
de obtener diseños incompletos.
detalle sucesivo puede ser relacionado al cuadro
completo.
• Segundo, forzando el análisis top-down, cada nivel de
detalle recibe la cantidad apropiada de atención.
• La tendencia natural en el diseño de software es pasar
directamente a los detalles, asumiendo que los temas
más amplios y de alto nivel son evidentes.
 JAD (Joint Aplicación Diseño) Principales etapas
• El plan es la etapa con la que se inicia un
proyecto; junta a los participantes con una
perspectiva táctica y de alto nivel. Guiados por
el líder de sesión, abordan cuestiones políticas,
estratégicas y organizacionales. Esta etapa
tiene cuatro objetivos mayores:
✓Identificar los requerimientos de alto nivel del
sistema.
✓Definir y limitar el alcance del sistema.
✓Planear la actividad del diseño.
✓Publicar y obtener la aprobación del
documento del plan.
Planificación
Diseño
• El diseño es la etapa donde se detallan los requerimientos, la
interfaz de usuario y las relaciones con los otros sistemas,
teniendo en cuenta el documento que se obtuvo como
resultado de la planificación. Un diseño para un desarrollo de
software tiene cuatro objetivos principales:
✓Definir los requerimientos detallados y el alcance.
✓Diseñar los esquemas de pantallas y reportes.
✓Capturar los requerimientos de edición, validación,
procesamiento e interfaz.
✓Desarrollar un prototipo.
✓Completar y obtener la aprobación del documento de diseño.
 Conclusiones
❖ Es importante mejorar el proceso de gestión de proyectos para facilitar la comunicación, la documentación y el control y
de gestión de cambios.
❖ Es necesario hacer que el cliente sienta que los requisitos y el sistema futuro son de su propiedad y por lo tanto su
responsabilidad.
❖ Algunos de los beneficios del análisis de requisitos en los proyectos de construcción de software son:

❖ Disminución de errores y reprocesos en la codificación del software

❖ Claridad en el alcance del proyecto desde sus inicios

❖ Soluciones enfocadas en lo que realmente necesita el negocio

❖ Clientes satisfechos

❖ JAD reúne un compendio de buenas técnicas de demostrada utilidad, que pueden mejorar el tiempo de desarrollo y
aumentar la visibilidad del proyecto. Además utilizada de forma regular, esta técnica puede aportar una mejora en el
desarrollo de proyectos en general que la puede hacer muy útil. Finalmente señalar que, utilizada con inteligencia,
puede hacer que la satisfacción de los clientes se vea incrementada.
 Referencias Bibliográficas
1. Ali Babar, J. M. Verner & P. T. Nguyen. “Establishing and maintaining trust in software outsourcing
relationships: an empirical investigation”. Journal of Systems and Software, Vol. 80, No. 9, pp.1438-1449,
2007.

2. A. Hickey & A. Davis. “Elicitation Technique Selection: How Do Experts Do It?” Proceedings of the 11th IEEE
International Conference on Requirements Engineering (RE’03), Monterey, USA, 2003.

3. García Villar, S. (s.f.). Diseño integral de sistemas y requerimientos. Material didáctico propio de la
institución.

4. L. Andrade. “Norma ISO 25010 en calidad de software, Ciudad de Mexico. 2019.

5. Material didáctico, campus virtual de la compañía, curso calidad de requisitos. SQA. Colombia 2021.
Gracias por su tiempo
Angela Parra Pachón
Bogotá – Colombia
26-May-2022