Técnicas de requisitos

Ingeniería del software 1

Curso 2021-2022
 Entrevistas Prototipos
Escenarios

Casos de uso Historias de usuario

Plantillas Checklist
Reuniones
JAD Walk-throughs

Brainstorming Lenguajes

2
 Técnicas para
identificar y
analizar

Requisitos

Técnicas para Técnicas para

validar especificar

3
Entrevista
• Permite conocer el problema de una
forma natural y comprender los objetivos
de la solución buscada.
• Los pasos de la entrevista son:
identificación de los entrevistados,
preparación de la entrevista, realización
de la entrevista y documentación de los
resultados.
• Se debe tener experiencia y capacidad
para elegir bien a los entrevistados y
obtener de ellos toda la información
posible en un período de tiempo
limitado.

4
Observación

• Permite obtener información precisa

sobre personas o situaciones sin que
los sujetos o hechos observados se
den cuenta de que están ofreciendo
datos sobre los comportamientos
ante actos concretos.
• Proporciona información de primera
calidad y da la oportunidad de
analizar un fenómeno en el mismo
momento en que se produce.

5
Cuestionario

• Esta técnica requiere del conocimiento

previo del ámbito del problema.
• Consiste en redactar un documento con
preguntas cuyas respuestas sean cortas y
concretas, o incluso cerradas (con varias
opciones).
• El cuestionario será cumplimentado por
el grupo de personas entrevistadas o,
simplemente, para recoger información
independientemente de una entrevista.

6
Documentación

• Se trata de documentación referida al

ámbito y entorno del software.
• Los tipos de documentos pueden ser:
relativos a la actividad del usuario,
impresos que se usen (sin cumplimentar y
cumplimentados para conocer los datos
que se manejan), informes que se generen,
información de apoyo a las tareas del
usuario, documentación de los sistemas
con los que haya que interactuar, etc.

7
Brainstorming

• Es una técnica de reunión cuyo objetivo es

que los participantes expongan sus
ideas libremente (Raghavan, Zelesnik & Ford,
1994).
• El grupo debe ser de 10 personas como
máximo y una de ellas debe asumir el rol de
moderador.
• Como técnica de captura de requisitos es
sencilla de aplicar y se aconseja aplicarla en
los primeros encuentros con los stakeholders.
Suele ofrecer una visión general de las
necesidades del sistema sin entrar en
detalles.

8
Reunión TFEA
• TFEA (Técnica para Facilitar la Especificación de
la Aplicación) combina elementos de resolución
de problemas, negociación y especificación.
• Es una reunión de trabajo informal con un
coordinador y un equipo mixto de clientes y
desarrolladores donde se potencia el flujo de
ideas.
• El objetivo es trabajar conjuntamente para
identificar el problema, proponer elementos de
solución, evaluar los diferentes enfoques y
especificar un conjunto preliminar de requisitos
para la solución.

9
Reunión JDA

• JAD (Desarrollo conjunto de aplicaciones) es una

práctica de grupo que se desarrolla en varias
sesiones y en la que participan desarrolladores,
usuarios y clientes (IBM, 1997).
• Está basada en cuatro principios fundamentales:
dinámica de grupo, el uso de ayudas visuales para
mejorar la comunicación (presentaciones,
diagramas, etc.), mantener un proceso organizado
y racional y una filosofía de documentación
WYSIWYG (What You See Is What You Get) por la
que en las reuniones se trabaja directamente
sobre los documentos a generar.

10
Workshop

• Es un taller de trabajo intensivo, focalizado y

concentrado en un propósito concreto que
acelera el proceso de captura de requisitos.
• Promueve la participación, el compromiso y la
motivación de los stakeholders y facilita el
consenso.
• Está dirigido por un facilitador y su duración
es variada (mínimo 3 horas).
• Provee un marco para la aplicación de otras
técnicas de identificación (Brainstorming,
Storyboards, etc.)

11
Concept Mapping
• Son grafos donde los vértices
representan conceptos y las aristas
representan posibles relaciones entre
dichos conceptos (Pan, Zhu & Johnson,
2001) .
• Se desarrollan con el usuario y sirven
para aclarar los conceptos
relacionados con el sistema a
desarrollar.
• Son fáciles de entender por el usuario
si se elaboran en su lenguaje.

12
Glosario y ontología
• Facilitan el entendimiento entre
stakeholders y desarrolladores a la
hora de identificar requisitos.
• Permiten establecer un marco de
terminología común.
• El glosario de términos debe
recoger y definir los conceptos más
relevantes y críticos para el sistema.
• La ontología no sólo contiene los
términos, también las relaciones
entre ellos.

13
Storyboard
• Se trata de una serie de sketches
dispuestos en formato secuencial
de viñetas (o storyboards) que,
aplicada al diseño de sistemas
interactivos, representan cómo un
determinado sistema será usado
durante la consecución de una
determinada tarea.
• Aunque es la noción más simple de
lo que se entiende por prototipo, se
considera más una técnica de
captura inicial de requisitos.

14
Escenario
• Proporciona información importante
sobre las necesidades funcionales de
sistema durante la captura de
requisitos.
• Es una descripción parcial del
comportamiento del sistema en una
determinada situación.
• Esta representación puede ser textual
en forma de secuencia de pasos o
gráfica en forma de diagramas de
flujo.
1. It’s Tuesday morning, and Mary is working on her
computer. She wants to book Roger Smith on a
public Certified Scrum Product Owner course taught
by Roman.
2. Mary visits romanpichler.com and chooses a public
CSPO class.
3. She enters the participant information including first
name, last name, email address, special dietary
requirements.
4. She then chooses a payment option and enters the
payment details.
5. Mary accepts the terms and conditions, and
confirms the booking.
6. Mary sees that her booking has been successful.
After a short while, Roger receives an email
confirmation with the booking details.
15
Caso de uso
• Técnica para definir los requisitos del
sistema que describe la secuencia de
interacciones que se producen entre el
sistema y los actores del mismo para
realizar una determinada función.
• Los actores son elementos externos
(personas, otros sistemas, etc.) que
interactúan con el sistema como si de una
caja negra se tratase. Un actor puede
participar en varios casos de uso y un caso
de uso puede interactuar con varios actores.
• Resulta muy fácil de entender para el
cliente/usuario.

16
Lenguaje natural

• Consiste en definir los requisitos en lenguaje

natural sin usar reglas.
• Es expresivo, intuitivo y universal pero
“El sistema deberá proporcionar una
también puede ser muy ambiguo e respuesta rápida al usuario.”
impreciso.
• Se aconseja usar un formato estándar que “El sistema deberá soportar un máximo
defina cada requisito en una sola oración, de 1000 usuarios concurrentes sin que el
diferenciar entre los obligatorios y deseables, tiempo de respuesta medio aumente más
de un 10%.”
evitar jergas técnicas y asociar una razón a
cada requisito.
• Aunque se critica mucho su uso, es una de
las técnicas más utilizadas para documentar
los requisitos.

17
Plantilla o lenguaje estructurado
• Tiene por objetivo describir los
requisitos mediante el lenguaje
natural pero de forma
estructurada.
• Una plantilla es una tabla con una
serie de campos y una estructura
predefinida que el equipo de
desarrollo va cumplimentando
usando para ello el lenguaje del
usuario.
• Las plantillas eliminan parte de la
ambigüedad del lenguaje natural al
estructurar la información.

18
Notación gráfica
• Los lenguajes gráficos como UML
(Unified Modeling Language)
ayudan a especificar los requisitos
funcionales en forma de
diagramas con la ayuda de
anotaciones de texto.
• UML es el más utilizado en las
últimas décadas para especificar
requisitos funcionales.

19
Historia de usuario
• Se trata de una explicación general e
informal de una funcionalidad del
software escrita desde la perspectiva
del usuario final. No es un requisito
del sistema.
• Su propósito es articular cómo la
funcionalidad proporcionará valor al
cliente.
• Una historia de usuario tiene la
siguiente forma: “As a <role>, I want
<goal/desire> so that <benefit>.”

20
Review o Walk-through

• Un grupo de personas que incluye a

cliente y usuarios revisa el documento de
requisitos.
• Los pasos a seguir son: identificar
problemas, convocar reunión y adoptar
acuerdos.
• Permite validar la correcta interpretación
de la información transmitida, verificar la
consistencia de la documentación y la
completitud de la información.
• Es una de las técnicas más utilizadas.

21
Auditoría

• Consiste en chequear el documento

de requisitos y se usa como guía para
identificar problemas habituales.
• Se pueden utilizar listas de
comprobación (checklists).
• Los checklists suelen estar
predefinidos o definidos al comienzo
del proceso.
• Hay checklists adaptados a
diferentes tipos de sistemas.

22
Matriz de trazabilidad

• Permite alinear los requisitos de

usuario con los objetivos del negocio.
• Se trata de una tabla que relaciona los
requisitos con su origen y permite
hacer un seguimiento desde su
concepción hasta los entregables del
proyecto.
• La matriz debe mantenerse actualizada
en todo momento para hacer un
seguimiento adecuado.

23
Prototipo
• Constituye una visión preliminar del
futuro sistema que permite simular
aspectos relacionados con la interfaz de
usuario o con la funcionalidad.
• Sirve para explorar, comunicar y evaluar
ideas.
• Se realiza mediante un proceso iterativo
con la participación del usuario.
• Ayuda a comprobar si el usuario está
conforme con los requisitos definidos.

24