Capítulo N°3

REQUERIMIENTOS

Copyright © 2007, Cibertec. Todos los derechos reservados

TEMAS

• Etapa de Requerimientos.
– Objetivos a cumplir.
– Workflow de trabajo.
– Actividades a desarrollar y artefactos.
• Especificación de Requerimientos de Software.

• Diagramas de Casos de Uso de Sistema

– Notación UML
– Elementos: Actores y Casos de Uso

Copyright © 2007, Cibertec. Todos los derechos reservados

1
 Rational Unified Process (RUP)

Copyright © 2007, Cibertec. Todos los derechos reservados

Requerimientos: Objetivos

• Llegar a un acuerdo formal con los clientes y

usuarios finales sobre lo que el sistema debe de
hacer.
• Proporcionar a los miembros del proyecto una
idea clara de los requerimientos del sistema.
• Delimitar las fronteras del sistema.
• Proporcionar las bases para la planificación del
contenido técnico de las iteraciones, los costos y
el tiempo para el desarrollo del sistema.
• Definir la interfase gráfica del sistema.

Copyright © 2007, Cibertec. Todos los derechos reservados

2
 REQUERIMIENTOS. Workflow

Copyright © 2007, Cibertec. Todos los derechos reservados

Requerimientos. Actividades

Copyright © 2007, Cibertec. Todos los derechos reservados

3
 Requerimientos. Artefactos

Copyright © 2007, Cibertec. Todos los derechos reservados

REQUERIMIENTO. Definición

Un requerimiento es considerado una

condición o capacidad a la que se debe
ajustar el sistema que se está
desarrollando

Copyright © 2007, Cibertec. Todos los derechos reservados

4
 DONDE BUSCAR REQUERIMIENTOS?

Business Analysis Model

Business Use Case Model
REQUERIMIENTOS

Stakeholders
Business Rules Request

Copyright © 2007, Cibertec. Todos los derechos reservados

¿Cómo capturar requerimientos?

• Entrevistas.
• Cuestionarios.
• Encuestas.
• Descripción de puestos.
• Artefactos del Modelado de Negocio

Copyright © 2007, Cibertec. Todos los derechos reservados

5
 Requerimientos. Estereotipos

• Estereotipos más importantes en la etapa de

Requerimientos.

Actor Package Caso de Uso

Copyright © 2007, Cibertec. Todos los derechos reservados

Requerimientos. Actividades

1) Identificar los requerimientos del sistema.

2) Encontrar los actores y casos de uso del sistema.
3) Identificar los paquetes del sistema.
4) Construir el Modelo de Casos de Uso del Sistema.
5) Estructurar el Modelo de Casos de Uso del Sistema.
6) Priorizar los casos de uso del sistema.
7) Detallar los casos de uso del sistema.
8) Construir el Modelo Conceptual.

Copyright © 2007, Cibertec. Todos los derechos reservados

6
 Actividad 01

1. Identificar los Requerimientos del sistema:

– Requerimientos Funcionales
– Requerimientos No Funcionales

Copyright © 2007, Cibertec. Todos los derechos reservados

Tipos de requerimientos del

sistema

• Funtionality. • Interfaces.
• Usability. • Licensing.
• Reliability. • Legal, Copyright, and
Other Notices.
• Performance.
• Applicable Standards.
• Supportability.
• Design Constraints.
• On-line User Documentation and Help System.
• Purchased Components.

Copyright © 2007, Cibertec. Todos los derechos reservados

7
 Requerimientos funcionales

• Funtionality.
– Especifica las condiciones que deben ser
cumplidas por el sistema.
– Se identifican desde el punto de vista del
cliente.
– Se redactan en lenguaje natural.
– Se capturan en dos artefactos.
• Especificación de Requerimientos de Software.
• Modelo de Casos de Uso del Sistemas.

Copyright © 2007, Cibertec. Todos los derechos reservados

Requerimientos funcionales

• Funtionality. Ejemplo:
• Asociados a los casos de uso del sistema.
• El sistema debe:
– Actualizar la información de los profesores que dictan
los cursos de baile del club.
– Registrar los horarios de dictado de clase definidas
por el administrador.
– Consultar la programación del rol de los
campeonatos locales y regionales.
– Cerrar un curso.

Copyright © 2007, Cibertec. Todos los derechos reservados

8
 Requerimientos funcionales

• Funtionality. Ejemplo:
• Asociados a otros aspectos generales.
• El sistema debe:
– Obligar al usuario a cambiar su contraseña cada 60
días.
– Incluir un mecanismo que permita su actualización
automática sin la intervención del usuario.
– Mantener un registro de los errores y para cada uno
debe registrar: el código del error, una descripción
del error, la fecha y la hora del error.

Copyright © 2007, Cibertec. Todos los derechos reservados

Requerimientos no funcionales

• Usability. Ejemplo.
– El sistema debe permitir al administrador
registrar una matricula como promedio en 30
segundos.
– El lenguaje empleado en la interfaz gráfica
del sistema debe respetar los términos
usados en el negocio.
– El diseño de la interfaz gráfica del sistema
debe alinearse al estándar definido en la
empresa para las aplicaciones Web.

Copyright © 2007, Cibertec. Todos los derechos reservados

9
 Requerimientos no funcionales

• Supportability. Ejemplo.
– El cliente Web del sistema debe soportar los
siguientes navegadores:
• Microsoft Internet Explorer 6.0 o superior
• FireFox 1.5 o superior para Linux y para Windows
– El sistema debe ser compatible con Windows
2000 profesional y Windows XP.
– El sistema debe permitir a un usuario su
instalación sin entrenamiento previo.

Copyright © 2007, Cibertec. Todos los derechos reservados

Actividad 02

2. Encontrar los actores y casos de uso del

sistema.

Actores

Casos de uso

Notación UML
Copyright © 2007, Cibertec. Todos los derechos reservados

10
 Diagrama de CUS

Representa lo que hace el sistema y su relación con el

entorno, desde el punto de vista del usuario.

• Son iniciados por un agente externo: El Actor

• Describen lo que hace el actor y lo que hace el
sistema al interactuar
• Están limitados a una sola tarea

Copyright © 2007, Cibertec. Todos los derechos reservados

ACTOR

El actor representa un rol, no es un usuario individual

del sistema.
Los actores se determinan observando:
• Usuarios directos del sistema
• Trabajadores y/o Actores del Negocio
• Responsables del uso o mantenimiento del
sistema
• Otros sistemas que interactúan con el sistema

El nombre del actor describe el papel desempeñado

Copyright © 2007, Cibertec. Todos los derechos reservados

11
 Identificando Actores

¿Dónde empiezo a encontrar a los actores del sistema?

¾ Por cada trabajador

del negocio con
actividades a
automatizar identificar
a un actor del sistema.
¾ Dar al actor del
sistema el mismo
nombre del trabajador
del negocio.

Copyright © 2007, Cibertec. Todos los derechos reservados

Identificando Actores

• Preguntas para ayudar a identificar mas actores:

– ¿Quién usará la funcionabilidad principal del
sistema?
– ¿Quién está interesado en cierto requerimiento?
– ¿Quién se beneficia con el uso del sistema?
– ¿Quién administrará, soportará y mantendrá el
sistema?
– ¿El sistema usa un recurso externo?
– ¿Alguna persona juega varios roles diferentes?
– ¿El sistema interactúa con otro sistema?

Copyright © 2007, Cibertec. Todos los derechos reservados

12
 Sugerencias

Sugerencias para identificar adecuadamente a los actores del

sistema.
9 Son roles (humanos, software o hardware), no personas
con nombres propios.
9 No siempre están asociado con el nombre de un cargo en
la planilla de la organización objetivo.
9 El nombre no debe representar áreas, departamentos o
partes de una organización sino roles de ejecución.
9 Cada actor debe estar asociado con al menos un caso de
uso del sistema.
9 Si no participa en ningún proceso debe ser eliminado del
modelo.

Copyright © 2007, Cibertec. Todos los derechos reservados

EJEMPLOS

1. Identifique algunos actores en un sistema de ventas de

una ferretería

Comprador Vendedor Cajero

Copyright © 2007, Cibertec. Todos los derechos reservados

13
 CASOS DE USO

• Acciones que debe realizar el sistema

• Nombre: verbo + objeto afectado

• Ejemplo:
Generar
Reporte

Copyright © 2007, Cibertec. Todos los derechos reservados

IDENTIFICANDO CUS

• El proceso va relacionado con la identificación de

actores.
• Por cada actor identificado podemos preguntar:
– ¿Cuáles son las tareas automatizables del actor?
– ¿Qué información crea, guarda, modifica, destruye o
lee?
– ¿El actor debe notificar al sistema los cambios
externos?
– ¿El sistema debe informar al actor los cambios
internos?

Copyright © 2007, Cibertec. Todos los derechos reservados

14
 Ejemplos de Casos de Uso

• Identifique algunos casos de uso del sistema de

ventas de una ferretería

Consultar Precio Registrar pedido Generar Documento

Copyright © 2007, Cibertec. Todos los derechos reservados

Identificar los CUS

• Caso de Uso vs Requerimiento Funcional.

– ¿Existen diferencias?
– Existe una correspondencia directa entre
ambos.
– La diferencia radica en la manera en que
describen la necesidad de funcionalidad.
• Los RF se describen desde la perspectiva del
usuario o cliente del proyecto.
• Los CUS se describen desde la perspectiva de la
arquitectura del sistema.
Copyright © 2007, Cibertec. Todos los derechos reservados

15
 ACTIVIDAD 03

3. Identificar los paquetes del sistema.

• Un paquete es una colección de artefactos (casos de

uso, actores, relaciones, diagramas y otros paquetes)
que se utiliza para dividir un modelo en partes de
menor tamaño.

• Ejemplo:
– Paquete Logística.
Nombre del
– Paquete Seguridad. Paquete

Copyright © 2007, Cibertec. Todos los derechos reservados

Encontrar los diferentes módulos

del sistema

• Un paquete.
– Hace más fácil la definición de la arquitectura.
– Facilita la asignación de responsabilidades y
tareas a los miembros del equipo de
proyecto.
• ¿Cuándo utilizar paquetes dentro del Modelo de
Casos de Uso del Sistema.
– Si el número de actores y casos
de uso es elevado.

Copyright © 2007, Cibertec. Todos los derechos reservados

16
 Encontrar los diferentes módulos
del sistema

• ¿Cómo definir los paquetes del sistema?

– Por cada grupo de casos de uso del sistema.
• Manejado por un mismo actor.
• Que respondan a una funcionalidad similar.
• Por complejidad de desarrollo.
– Los procesos del negocio (casos de uso del
negocio) pueden ayudar a identificar los
paquetes.

Copyright © 2007, Cibertec. Todos los derechos reservados

Diagrama de Paquetes del sistema.

Ejemplo
Solicitud de Evaluación de
servicio solicitud

Reportes de Seguridad
gerencia

Copyright © 2007, Cibertec. Todos los derechos reservados

17
 ACTIVIDAD 04

4. Construir el modelo.

Registrar
Retiro

Cajero
Consultar
Tipo de Cambio

Copyright © 2007, Cibertec. Todos los derechos reservados

Diagrama de Casos de Uso del Sistema

• El Diagrama de Casos de Uso del sistema es:

– Herramienta proporcionada por UML.
– Muestra gráficamente los requerimientos funcionales del
sistema.
– Muestra los procesos que son usados por los roles del sistema.
– Solo se tiene en cuenta “¿QUIÉN realiza QUÉ proceso?”
• ¿QUIÉN? (actor del sistema identificado).
• ¿QUÉ? (caso de uso del sistema identificado).
• Relaciones entre ellos (asociaciones).
– No constituye un Diagrama de Flujo de Datos.

Copyright © 2007, Cibertec. Todos los derechos reservados

18
 Relación en los Diagramas

Un diagrama de Casos de Uso muestra las relaciones entre

los Actores y los Casos de uso dentro de un sistema

Uc Pagar Servicio

Registrar Pago

Cajero

Copyright © 2007, Cibertec. Todos los derechos reservados

Ejemplos

1. Identifique la Relación de casos de uso del sistema de ventas de una

ferretería

Consultar
Precio
Generar
Documento
Vendedor Cajero
Registrar
pedido

Copyright © 2007, Cibertec. Todos los derechos reservados

19
 Ejemplo: Casos de Uso de Sistema

Se tiene un sistema de “delivery”. El Cliente realiza una

llamada comunicándose con el vendedor, el cual verifica
su identidad. Posteriormente el cliente coloca un pedido de
compra con el vendedor. Debido a que es una venta al
crédito, este pedido debe ser aprobado por el supervisor.
De estar todo conforme el despachador programa la
entrega.

Copyright © 2007, Cibertec. Todos los derechos reservados

Solución

Verificar Cliente

Colocar pedido

Cliente Vendedor

Autorizar crédito

Supervisor

Programar entrega

Despachador

Copyright © 2007, Cibertec. Todos los derechos reservados

20