El documento proporciona una introducción a la gestión de requisitos, incluyendo definiciones de requisitos, tipos de requisitos, artefactos de requisitos y trazabilidad de requisitos. Explica que el modelado de requisitos sirve para capturar las necesidades fundamentales de los usuarios de forma clara y sencilla. También describe los requisitos funcionales y no funcionales, así como diferentes artefactos utilizados durante el proceso de captura de requisitos, como casos de uso, actores y prototipos.

1. CAPTURA DE REQUISITOS (Requerimientos)
Casos de Estudio
EP INGENIERÍA DE SISTEMAS
EC: ANALISIS Y DISEÑO DE SISTEMAS

2. RUP - Disciplinas

3. Modelado de requisitos
Diferentes interpretaciones desde los puntos de vista de los
involucrados en el

4. Modelado de requisitos
Diferentes interpretaciones desde los puntos de vista de los
involucrados en el

5. Competencia
Analiza y Diseña Sistemas de Información con el
Proceso de Desarrollo RUP, expresando sus ideas
con coherencia, lógica, orden, claridad, fundamento y
buen lenguaje; innovando en la búsqueda de
soluciones.

6. Objetivo de la clase
Comprende conceptos y fundamentos de la gestión de requisitos.

7. Agenda de la clase
 Modelados de Requisitos
 Artefactos de requisitos
 Trazabilidad de requisitos

8. Definición de Requisitos:
Características de los requisitos.
Tipos de requisitos.
Artefactos de requisitos.
Trazabilidad de requisitos.

9. Modelado de
requisitos
Definición de requisitos
Es una condición o capacidad que necesita el usuario
para resolver un problema o conseguir un objetivo
determinado.

10. Características de los
requisitos
Necesario: Es necesario si su omisión
provoca una deficiencia en el sistema a
construir, y además su capacidad,
características físicas o factor de calidad
n
o
puede
n
se
r
reemplaza
dos
por otra
s
capacidades
del
producto o del
proceso.
Conciso: Si es fácil de
leer
y entender. Su
redacción
debe ser simple y clara para aquellos
que vayan a
consultarlo en un futuro.
Completo: si no necesita ampliar
detalles en su
redacció
n,
e
s
deci
r
si proporcio
na
informaci
ón
suficiente para su
comprensión.

11. Características de los
requisitos
Consistente:
si
requerimiento.
n
o
e
s
contradictorio con
otro
No ambiguo
:
cuand
o
tien
e
una
sola
interpretació
n.
El lengua
je
usado
en
s
u
definición no debe causar confusiones
al lector.
Verificable:
cuando
puede ser
cuantificado de
manera que permita hacer uso de los
siguientes
métodos de verificación, inspección,
análisis,
demostración o pruebas.

12. Modelado de
requisitos
La finalidad del modelo de requisitos es
capturar
d
e
un
a
maner
a
precisa lo que el cliente
quiere
qu
e
s
e
construy
a.
El modelo de
requisitos es
el prime
r
model
o
en
ba
se
lo
s
el
desarrollar
se
para
formar
y
es
la
todo
s
dem
ás
model
os
e
n
desarrollo de
software.

13. Modelado de
requisitos
El modela
do
d
e
requisit
os
nos
sirve
y tien
e
como
propósito
comprend
er
completame
nte
el problem
a
y todo
lo
qu
e
ést
e
implica y
conlleva.
Su
objetivo principal
es
delimita
r
el siste
ma
y capturar
la
funcionalidad que debe ofrecer desde la
perspectiva del usuario.
Por medio de él representamos los requisitos del sistema de
forma sencilla,
para que de esta manera cualquier usuario pueda revisarlo y
entenderlo, sin necesidad que tenga conocimientos previos.
El modelo de requisitos captura las principales
características del sistema
de software que se desea
construir.

14. Modelado de
requisitos
Capturar
requisitos:
Qué sistema debe construirse
 Es difícil
 Usuarios no saben qué quieren
 Construir sistema correcto
 Usar lenguaje sencillo en vez de documentos
ininteligibles para los usuarios.

15. Modelado de
requisitos
Captura de
requisitos
• Listar requisitos candidatos
• Entender contexto del sistema
• Capturar requisitos funcionales
• Capturar requisitos no funcionales

16. Clasificació
n
software
de requerimiento
s
de un sistema
Requisitos funcionales: Describen el funcionamiento del
sistema. Son la
característica requerida del sistema que expresa una
capacidad de acción del mismo, una funcionalidad. Debe
describir los servicios que hay que proporcionar con todo
detalle (casos de uso).
Ejm. Para un sistema que imprime cheques semanales de pago,
los requerimientos
funcionales deben responder a preguntas como:
¿Qué entrada es necesaria para que un cheque se
imprima?
¿Bajo que condiciones puede cambiar el monto
del pago?
Ejm. En un sistema de biblioteca:
A cada pedido se le deberá asignar un identificador único que
el usuario podrá copiar al área de almacenamiento

17. Clasificación de requerimientos de un
sistema
software
Requisitos no funcionales: característica requerida del
sistema, del proceso de desarrollo, del servicio
prestado o de cualquier otro aspecto del desarrollo.
•
Rendimiento
del
sistema:
fiabilida
d,
tiemp
o
d
e
respues
ta,
disponibilidad, etc.
• Interfaces: dispositivos de E/S, usabilidad,
interoperabilidad, etc.
• Proceso
de
entrega,
desarroll
o:
estándar
es,
herramient
as,
plaz
o
d
e

18. Tipos de
requisitos
Requisitosd
e
usuari
o:
Declaracio
nes
e
n
d
e
la
s
lenguaje natural y en diversos
diagramas
lo
s
servici
os
del
sistema
y d
e
restricciones bajo las que se
debe operar.
Requisitos
del
sistem
a:
Un
documento
estructura
do
qu
e
de
l
determina las descripciones detalladas de
los servicios
sistema.
• Especificación del software:
descripción
detalla
da
de
l
par
a
softwar
e
qu
e
sirv
e
d
e
bas
e
a lo
s
desarrollado
res
diseñar el
sistema.

19. Artefactos de
requisitos
Es el resultado de un producto de trabajo en un proceso,
es decir los trabajadores utilizan artefactos para realizar
sus actividades, y a la vez producen artefactos u objetos
al cumplir con estas tareas.
Artefactos a obtener en los Flujo de Trabajo
“captura requisitos”
Los artefactos utilizados durante la
captura de
proceso de desarrollo en UML son:
lo
s
requisit
os
durant
e
el
• Casos de uso
• Actores
• Prototipos de interfaces de
usuario
• Glosario
• Diagrama de clases (modelo del
dominio)
• Descripción de la arquitectura

20. Trazabilidad de
requisitos
La trazabilidad
es
d
e
vita
l
importanc
ia
y
a
qu
e
permit
e
rastrear los requerimientos durante
todo el
sistema.
desarrollo de
un
Ademáspued
e
permitir a
priori
conoc
er
cuál
es
sería
n
la
s
consecuencias de cambiar o eliminar un
requerimiento en el
sistema, lo que en estrategias carentes de
trazabilidad, no se podía visualizar tan fácilmente.
Es la habilidad de describir y seguir la vida de un requisito desde su
origen, pasando
por su desarrollo y especificación y hasta su despliegue. Ha de
hacerse en ambas direcciones, hacia adelante y hacia atrás.

21. Trazabilida
d
derequisitos
Matriz de trazabilidad de requerimientos funcionales vs Casos de Uso del
Sistema (CUS)

22. Trazabilida
d
derequisitos
Matriz de trazabilidad de los requerimientos de un
sistema

23. Trazabilida
d
derequisitos
Matriz de Trazabilidad de casos de uso y

24. Gracias por su
atención