Cap2.

Captura de requisitos

CARLA SALAZAR SERRUDO

DPTO. INFORMÁTICA Y SISTEMAS
UNIVERSIDAD MAYOR DE SAN SIMÓN
MAYO 2020
Introducción
Requisito se puede definir:
A) Condición o capacidad necesitada por un
usuario para resolver un problema o lograr
un objetivo.
B) Condición o capacidad que debe poseer
un sistema para satisfacer un contrato,
estándar, especificación u otro documento
formalmente impuesto.
 1. Introducción (2)
•La captura de requisitos permite identificar, registrar, modelar y
documentar los requisitos del futuro sistema.
•Establecer y mantener la conformidad de las necesidades de los
clientes/usuarios acerca de lo que el sistema debe hacer.
•Proporcionar a los desarrolladores una mejor comprensión de los
requisitos del sistema
•Definir las fronteras/límites del sistema
•Proporcionar la base de estimación de costos y tiempo de
desarrollo del sistema
•Definir una interfaz de usuario para el sistema centrada en las
necesidades y metas de los usuarios.
 1. Introducción (3)

•Problemas en la identificación de requisitos

• Los clientes/usuarios no saben lo que quieren
• Los clientes/usuarios cambian de opinión
• Los clientes/usuarios no se involucran en la
identificación de los requisitos
• Se me ocurren a mi cientos de requisitos que los
clientes/usuarios no han identificado.
 1. Introducción (4)

Fuentes de requisitos:
• Conocimiento del dominio de la aplicación
• Clientes / usuarios
• Entorno físico y organizativo
• Metas u objetivos
• Regulaciones, leyes, normas
Fuentes de requisitos
Técnicas de captura requisitos
•Entrevistas
•Observación
•Estudio de documentación
•Cuestionario
•Brainstorming
•Prototipado
Entrevista
•Se interroga de manera verbal al cliente/usuario acerca
de cómo quiere que funcione el sistema.
•Es la técnica mas usada y es inevitable durante las
primeras etapas de la captura de requisitos
•Las entrevistas forman parte de la documentación del
proyecto de desarrollo.
•Se pueden distinguir dos tipos fundamentales de
entrevistas, cada una de las cuales tiene su momento y
objetivo específico:
• Entrevista abierta
• Entrevista cerrada
Entrevista abierta
•Es aquella donde el conjunto de preguntas a realizar
está predeterminado, pero no es de obligatorio
cumplimiento.
•Se usan al principio, cuando se necesita obtener mucha
información
•Por ello, cuando durante la entrevista surja algo
interesante, se puede salir del guión y aprovechar el
filón de información.
•Se usan por lo general las preguntas abiertas donde el
entrevistado se siente libre de expresar sus opiniones.
Entrevista cerrada
•Es recomendable (obligatorio) no salirse del guión
pre-establecido.
•Acostumbran a usarse durante las últimas etapas
de la captura de requisitos, cuando gran parte de
los requisitos están identificados y se desea
confirmar, mas que averiguar, algún tipo de
información.
• Se usan preguntas cerradas (Ej: falso / verdadero)
para limitar las respuestas del entrevistado. Se
ahorra tiempo y se llega al punto.
Pasos para realizar entrevista
•Preparación
• Estudiar el dominio del problema
• Seleccionar a las personas a entrevistar
• Determinar el objetivo y contenido de las entrevistas
• Planificar la entrevista
•Realización, con toda la interacción social que supone.
•Análisis y consolidación
• Transcribir la entrevista completa a la brevedad posible
• Identificar requisitos
Observación in situ
•La observación de las personas en el trabajo ofrece una
experiencia de primera mano sobre la forma en que
funciona el sistema actual.
•Los datos se recogen en tiempo real y pueden tener un
elevado grado de validez
•Puede utilizarse la observación para verificar la
información de otras fuentes.
•Es una técnica cómoda y poco costosa de
complementar una entrevista abierta. Por ejemplo
dando un paseo por las instalaciones de la empresa.
Observación de tareas
•También denominada “análisis de tareas”
•Consiste en observar y documentar el modo en que
algún usuario realiza una tarea que el futuro sistema
tendrá que implementar.
•La secuencia de tareas, recursos usados, excepciones y
otros constituyen una valiosa fuente de información.
•Pero a la mayoría de las personas no les gusta ser
observadas y pueden comportarse de manera distinta a
la habitual.
Estudio de documentación
•Consiste en la lectura y asimilación de información
contenida en documentos, manuales de función,
estadísticas, etc.
•Los documentos son una valiosa fuente de
información.
•Es obligatorio estudiar la documentación antes de
las entrevistas, por ejemplo.
Cuestionarios
•Consiste en una serie de preguntas escritas.
•Es útil cuando es necesario obtener información de
muchos potenciales clientes/usuarios. También cuando
no es posible entrevistar a todos los clientes/usuarios
por restricciones espaciales o temporales.
•Si el cuestionario está bien diseñado, los resultados se
podrán analizar fácilmente.
•No es fácil crear un buen cuestionario.
•Las respuestas a los cuestionarios pueden ser lentos,
incompletos, falsos, etc.
Brainstorming
•Tiene como objetivo la generación de ideas.
•Se usa para inventar requisitos para productos
novedosos.
•Es una técnica grupal que requiere de una gran
seriedad para producir resultado adecuado.
Brainstorming (2)
Desarrollo de una sesión de brainstorming
◦ Preparación de la sesión (logística): quiénes, dónde,
cuánto tiempo, cómo registrar las ideas, etc.
◦ Generación de la “semilla” (tema)
◦ Generación libre de ideas
◦ Generar el mayor número de ideas
◦ Intentar completar las ideas de los demás (sobre todo las mas
avanzadas o interesantes)
◦ Nunca criticar o juzgar una idea
◦ Consolidación
◦ Revisar, descartar, priorizar
◦ Documentar
Prototipado
•Un prototipo es una versión inicial de un sistema
(demostración)
•Al ser una versión inicial de un sistema, el
prototipo debe construirse rápidamente, al mínimo
coste posible.
• Hay 2 alternativas:
• Maquetas: es habitual que se implementen en papel.
• Prototipos electrónicos implementados en
computadora a muy diversos niveles de completitud
(ventanas, funcionalidad, requisitos no funcionales).
Escritura de requisitos
La forma mas usual de especificar los requisitos es
utilizar una frase corta, que típicamente comienza por
“el sistema permitirᨅ” o alguna variante.
• El sistema permitirá registrar los datos identificados y
contables de los clientes.
• El sistema deberá generar un listado de facturas
impagadas por un periodo mayor de 15 días.
• La consulta de un artículo en stock debe proporcionar los
datos requeridos en un tiempo menor que 0.5 segundos.
• El sistema deberá funcionar en entornos Windows 7
• La tabla de mejores resultados no se borrará nunca al
apagar la computadora
Cómo escribir requisitos
Decir lo que el sistema no va a hacer: El sistema
determinará la cantidad de reposición óptima de los
productos en almacén. Sin embargo, el sistema no generará
de forma automática la orden de pedido a proveedores.
Indicar excepciones, restricciones: El sistema emitirá un
balance de cuentas los días laborables, esto es, de lunes a
sábado. El listado no se emitirá automáticamente, sino que
un operador dará la orden de impresión.
Proponer ejemplos: El sistema validará los datos de entrada.
Por ejemplo: si el código es incorrecto, el sistema emitirá un
mensaje de error inteligible y pedirá que se repita la
entrada.
Requisitos funcionales
•Describen qué debe hacer el sistema (la funcionalidad o
servicios del sistema.
• Deben tener 1 solo propósito
• Deben ser escritas de manera declarativa
• Deben ser especificadas cuantitativamente
• Deben tener el mismo nivel de abstracción
• Deben omitir detalles de implementación
• Las funciones clave deben ser identificadas
El sistema LIBSYS
Un sistema de biblioteca que proporciona una
única interfaz a una serie de bases de datos de
artículos en diferentes bibliotecas.
Los usuarios pueden buscar, descargar e imprimir
estos artículos para el estudio personal.
Algunos ejemplos de requisitos funcionales
•El usuario será capaz de buscar ya sea todo el conjunto
inicial de bases de datos o seleccionar un subconjunto de
ella.
•El sistema deberá ofrecer visualizadores adecuados para
que el usuario puede leer documentos del almacén de
documentos.
•A cada orden se asignará un identificador único (ORDER_ID)
que el usuario será capaz de copiar a una zona de
almacenamiento permanente de la cuenta.
Imprecisión en Requisitos
Los problemas surgen cuando los requisitos no son,
precisamente, establecidos.
Requisitos ambiguos puede ser interpretados de diferentes
maneras por los desarrolladores y usuarios.
Considere el término “visualizadores adecuados"
◦ La intención del usuario - Visor de propósito especial para
cada tipo de documento diferente;
◦ La interpretación del programador - Proporcionar un visor
de texto que muestra el contenido del documento.
Completitud y Consistencia de los
Requisitos
En principio, los requisitos deben ser completos y
consistentes.
Completos
◦ Deben incluir la descripción de todos los servicios
necesarios.
Consistentes
◦ No debe haber conflictos o contradicciones en las
descripciones de los servicios del sistema.
En la práctica, es imposible producir un documento de
requisitos completo y consistente.
Requisitos no funcionales
Definen las propiedades y restricciones del sistema, por
ejemplo, fiabilidad, tiempo de respuesta y requisitos de
almacenamiento.
También se pueden especificar los requisitos de proceso,
como un sistema CASE en particular, el método de
desarrollo o el lenguaje de programación.
Los requisitos no funcionales pueden ser más críticos que
los requisitos funcionales. Si éstos no se cumplen, el
sistema podría no usarse.
Tipos de requisitos no
funcionales
Requisitos del producto
◦ Requisitos que especifican que el producto entregado debe comportarse
de una manera particular, por ejemplo la velocidad de ejecución,
fiabilidad, etc.

Requisitos organizacionales
◦ Requisitos que son consecuencia de las políticas y procedimientos de
organización, por ejemplo, las normas de procesos utilizados, los
requisitos de implementación, etc.

Requisitos externos
◦ Requisitos que se derivan de factores que son externos al sistema y su
proceso de desarrollo, ejemplo, requisitos de interoperabilidad,
requisitos legislativos, etc.
Tipos de requisitos no
funcionales
Ejemplos de requisitos no funcionales
Requisitos del producto
La interfaz de usuario para LIBSYS se llevará a cabo como HTML
simple, sin marcos o applets de Java.
Requisitos organizacionales
El proceso de desarrollo de sistemas y documentos entregables se
ajustarán al proceso y entregables definidos en XYZCo-SP-STAN-95.
Requisitos externos
El sistema no revelará ninguna información personal sobre los
clientes, aparte de su nombre y número de referencia para los
operadores del sistema.
Ejemplos de requisitos no
funcionales (2)
Requisito de usabilidad
•Un usuario experimentado debe ser capaz de utilizar todas las
funciones del sistema tras un entrenamiento de 2 horas, tras el cual no
cometerá más de 3 errores diarios en media.

Requisito de rendimiento
•Cuando haya hasta 100 usuarios accediendo simultáneamente al
sistema, su tiempo de respuesta no será en ningún momento superior a
2 segundos.

Requisito de fiabilidad
•Ante un fallo en el software del sistema, no se tardará más de 5 minutos
en restaurar los datos del sistema (en un estado válido) y volver a poner
en marcha el sistema
Ejemplos de requisitos no
funcionales
Requisitos de implementación
•Hardware: El sistema se debe implementar sobre la infraestructura
existente en los laboratorios de computación de la empresa.
•Software: No existe posibilidad de adquirir licencias de software. La
aplicación deberá funcionar sobre Oracle.

Lo que NO debe hacerse

• El sistema será lo más fácil de utilizar posible.
• El sistema proporcionará una respuesta rápida al usuario.
• El sistema se recuperará automáticamente tras producirse un fallo.
Requisitos funcionales y no
funcionales
•La distinción entre requisitos funcionales y no funcionales
no siempre resulta evidente.

•Ejemplo: La seguridad puede interpretarse inicialmente

como un requisito no funcional al principio. No obstante, su
elaboración puede conducir a nuevos requisitos
funcionales, como la necesidad de autentificar a los
usuarios del sistema.

•Más allá de si decidimos incluir este tipo de requisitos en

una sección u otra, lo importante es identificarlos
 Captura de requisitos en PU

•Listar requisitos candidatos

•Entender contexto del sistema
• Modelado del negocio
• Modelo del dominio
•Capturar requisitos funcionales
•Capturar requisitos no funcionales
Contexto del sistema

• Modelado del dominio

– Describir los “objetos” del dominio
– Construir un glosario de términos
• Modelado del negocio
– describir los procesos
Capturar los requisitos funcionales y
no funcionales

• Requisitos funcionales
– Modelar con casos de uso
• Requisitos no-funcionales
– Son propiedades o restricciones del sistema
Artefactos a obtener en la captura
de requisitos
• casos de uso (modelo del negocio)
• actores
• prototipos de interfaces de usuario
• glosario
• diagrama de clases (modelo del dominio)
• descripción de la arquitectura
Artefacto: actor
• Es una idealización de una persona, sistema
software o hardware que interactúa con el
sistema ( o subsistema o clase).
• Los actores se encuentran fuera del sistema
y colaboran con él
• Los actores pueden heredar asociaciones de
otros actores (jerarquía de generalización)
Actor en UML

Empleado Sistema Bancario

SÓLO SI ES EXTERNO AL
SISTEMA DE INFORMACIÓN
QUE SE ESTÁ MODELANDO
 Artefacto: caso de uso
• El modelo de casos de uso captura el comportamiento de un
sistema, subsistema o clase, desde el punto de vista del usuario.
• El modelo de casos de uso particiona la funcionalidad del sistema
en transacciones significativas para los actores (usuarios
idealizados).
• Las piezas de funcionalidad se llaman casos de uso
• Un caso de uso describe una interacción con actores como una
secuencia de mensajes entre el sistema y uno o más actores.
Caso de Uso en UML

Realizar Matrícula

Estudiante

El estudiante DECIDE EJECUTAR EL C.U.

 Caso de Uso en UML

Realizar Matrícula
iniciador

Estudiante Sistema Bancario

 Caso de Uso en UML
Flujo de eventos normal (o de éxito)
◦ El estudiante proporciona su CI
◦ El sistema muestra todas las asignaturas en las que puede
matricularse y que, de momento, no están completas
◦ El estudiante escoge las asignaturas que desea
◦ El sistema calcula el precio de la matrícula y realiza el cobro de la
cuenta del estudiante en el sistema bancario
Flujos de eventos alternativos:
◦ 1.- El CI proporcionado no es el de un estudiante. Fin.
◦ 2.- Alguna de las asignaturas está completa. Fin.
 Caso de Uso en UML
Requisitos especiales ( requisitos no funcionales)
◦ Debe poder ejecutarse de manera simultánea por al menos 20
estudiantes.
◦ El tiempo de cobro no debe excederse de 5 segundos.
◦ La interfaz de usuario debe ser intuitiva
◦ El tiempo de aprendizaje de este caso de uso es menor a 5
minutos.
◦ Se necesita una DBMS para almacenar las matrículas.
◦…
 Errores típicos en CU

Realizar Matrícula
iniciador

Estudiante Sistema

FLUJO DE EVENTOS:
• El estudiante introduce el DNI, …
• Se almacenan los datos de las matrículas en el sistema,…

NO SE TRATA DE UN SISTEMA EXTERNO

SINO DEL PROPIO SISTEMA (EL C.U. ES PARTE DE ÉL)
Artefacto: Modelo de CU

• Modelo que contiene todos los actores, casos de uso

y sus relaciones
• Con el modelo de casos de uso, los clientes y
desarrolladores se pueden poner de acuerdo
• Entrada al análisis, diseño, implementación y prueba
 Modelo de CU (MCU) en UML

iniciador

Realizar Matrícula

Estudiante
Escoger Asignaturas
Sistema
iniciador Bancario
Pagar Nóminas
Profesor
MCU Ejemplo 2
MCU Ejemplo 3
MCU Ejemplo 4
MCU Ejemplo 5
MCU Ejemplo 6
MCU Ejemplo 7
 Relaciones entre actores en UML

iniciador
Solicitar Carnet
Deportivo

Estudiante Sistema
Bancario
¿ Y si los profesores
también pueden solicitar
carnet deportivo?
 Errores típicos en CU

iniciador Solicitar Carnet

Deportivo

Estudiante Sistema
iniciador Bancario

NO, ya que eso significa que

los 3 actores participan en
Profesor el caso de uso y eso no es
lo que queremos
 Relaciones entre actores en UML

iniciador Solicitar Carnet

Deportivo Estud.

Estudiante Sistema
Bancario
iniciador
Solicitar Carnet
Deportivo Prof.

Profesor ¿SOLUCIÓN? 1: CUs distintos

 Relaciones entre actores en UML

iniciador
Solicitar Carnet
Deportivo

Universitario Sistema Bancario

SOLUCIÓN 2:
(MEJOR)
generalización
entre actores
Profesor Estudiante
 Relaciones entre CU: includes

<<includes>>
CASO DE CASO DE
USO A USO B

ACTOR El CASO DE USO A includes al

CASO DE USO B si SIEMPRE que
se ejecuta el caso de uso A, se
ejecuta el caso de uso B
 Relaciones entre CU: extends

CASO DE <<extends>> CASO DE

USO B USO A
- cond. C

El CASO DE USO A extends al CASO

ACTOR
DE USO B si SIEMPRE que se ejecuta
el caso de uso B, si se cumple la
condición C, entonces se ejecuta el
caso de uso A
 Relaciones entre CU: generalización

CASO DE CASO DE
USO A USO B

El C.U. A es una especialización

ACTOR (o un caso particular) del C.U. B.
Todo lo que se haya definido que
se va a ejecutar para B se
ejecutará también para A
 Relaciones entre CU en UML

Realizar Matrícula

<<includes>>
Estudiante
Escoger Asignatura

<<includes>>

Identificarse
Profesor
 Relaciones entre CU en UML

Reservar Libro

<<includes>>
Lector

Buscar Libro
por código

AMBOS CASOS DE USO DEBEN TENER

SENTIDO EN EL SISTEMA
 Relaciones entre CU en UML

Realizar Matrícula
- No identificado

<<extends>>
Estudiante
Escoger Asignatura
- No identificado

<<extends>>

Identificarse
Profesor
 Relaciones entre CU en UML

Ingresar Dinero

Cliente
Retirar Dinero

Flujo de eventos de RT:

- Identificar cliente
- Obtener su número de cuenta Realizar
- Comprobar que la cuenta no Transacción
está bloqueada
 Errores típicos en CU

Definir CU que no lo son

◦No hay actor que lo ejecute
◦Es un procedimiento interno del sistema
Ocurre normalmente al “buscar” includes
o extends
REGLA DE ORO: Un CU es funcionalidad del
sistema que proporciona algún RESULTADO o
VALOR a por lo menos un ACTOR.
 Errores típicos en CU
Realizar Matrícula

<<includes>>
Estudiante
Seleccionar
asignatura

Si al realizar la matrícula, se van

seleccionando (en la interfaz) asignaturas en
las que matricularse NO ES CASO DE USO
 Errores típicos en CU
Imprimir informes

<<includes>>
Empleado
Imprimir
informe

Un posible flujo de eventos sería:

• El empleado proporciona su identificador
• Se seleccionan los informes del empleado aún no impresos
• Se imprime cada uno de ellos
Posible excepción: generalización
Ingresar Dinero

Cliente
Retirar Dinero

Flujo de eventos de RT:

- Identificar cliente Realizar
- Obtener su número de cuenta Transacción
- Comprobar que la cuenta no está bloqueada

En este caso no parece que “Realizar Transacción” sea un

CASO DE USO REAL, pero PUEDE resultar ÚTIL para no repetir
muchos flujos de eventos. Puede ocurrir en el caso de
GENERALIZACIÓN
Ejemplo 1
Ejemplo 2
Ejemplo 3
Ejemplo 4
Artefactos: glosario y prototipo
de interfaz
• GLOSARIO:
– Documento donde se definen los términos más
comunes e importantes utilizados
• PROTOTIPO DE INTERFAZ DE USUARIO:
– Ayudan a entender las interacciones entre los
actores y el sistema
– Conseguir mejores interfaces de usuario
 Ejemplo de GLOSARIO

ESTUDIANTE: es una persona que está estudiando una carrera en la universidad UnivX.
Necesariamente debe estar matriculado en por lo menos una ASIGNATURA.

MATRÍCULA: es el resultado de un proceso administrativo por el cual un ESTUDIANTE

adquiere el derecho a ser evaluado en dos convocatorias de una ASIGNATURA. Se le
asocia a un GRUPO. Tiene derecho a asistir a las clases del PROFESOR responsable de
dicha ASIGNATURA en el GRUPO asignado.

PROFESOR: es una persona que trabaja en UnivX y que imparte al menos una asignatura
de una determinada TITULACIÓN. Se encarga de evaluar a todos los estudiantes
matriculados en la asignatura y asignados a sus grupos. El profesor no puede ser
estudiante en la misma carrera en la que imparte clases, pero sí en otras.

ASIGNATURA: …

…
 Ej. prototipo de interfaz de CU

Tomar Préstamo <<extends>>

Copia Libro Reservar Libro
- No disponible

Socio
Flujo de eventos normal:
El socio da su número de socio y la signatura del libro que desea
tomar en préstamo
El sistema comprueba si existe alguna copia no prestada de dicho
libro
Se comprueba que el socio no se pasa de su número máximo de
libros en préstamo
Se registra el nuevo préstamo con la fecha actual
Flujo de eventos alternativo:
Si no hay copias disponibles: EXTENDS RESERVAR LIBRO
 Ejemplo prototipo de interfaz de CU
CASO DE USO: TOMAR COPIA LIBRO EN PRÉSTAMO

SIGNATURA LIBRO:

NÚMERO SOCIO:

Área de texto donde aparecerá el número de copia del libro que se

ha tomado en préstamo.

Si no hay ninguna libre o si el socio ha sobrepasado su número

máximo de préstamos entonces se indicará aquí mismo.

TOMAR EN PRÉSTAMO RESERVAR LIBRO Cancel

Artefacto: modelo del dominio

• Captura los tipos de objetos en el contexto

del sistema y sus relaciones.
– “cosas” que existen
– eventos que suceden
• Seguramente aparecerán en el GLOSARIO
 Anexo: Trabajadores
• Son las personas responsables de obtener los artefactos
anteriores. En realidad se trata más bien de “puestos”
que de “personas” ya que una misma persona podría
desempeñar más de un puesto o trabajo. Son los
siguientes:
– Ingeniero de requisitos
– Analista de sistema
– Especificador de casos de uso
– Diseñador del interfaz del usuario
– Arquitecto
Trabajadores (2)
– Analista de sistema:
• es responsable del modelo de casos de uso (el conjunto de
requisitos), encontrar actores y casos de uso, asegurarse de
que el conjunto es completo y consistente (con el glosario). No
es responsable de especificar en detalle cada caso de uso.
– Especificador de casos de uso:
• detalla específicamente casos de uso. Necesita trabajar
estrechamente con los usuarios reales.
– Diseñador del interfaz del usuario
• define los prototipos de los interfaces de usuario
– Arquitecto
• describe la vista arquitectural del modelo de casos de uso
Anexo: Actividades en requisitos

• 1.- Encontrar actores y casos de uso

• Encontrar actores
• Encontrar casos de uso
• Describir brevemente cada caso de uso
• Describir el modelo de casos de uso como un todo
• 2.- Priorizar los casos de uso
• 3.- Detallar un caso de uso
• Estructurar la descripción de un caso de uso
• Qué incluir en la descripción de un caso de uso
• Formalizar las descripciones de casos de uso
Actividades en requisitos
• 4.- Prototipo de interfaz de usuario
• Crear diseño lógico de interfaz de usuario
• Crear prototipo y diseño físico de interfaz de usuario
• 5.- Estructurar el modelo de casos de uso
• Identificar descripciones compartidas de funcionalidad
• Identificar descripciones de funcionalidad adicionales y
opcionales
• Identificar otras relaciones entre casos de uso