You are on page 1of 31

Facultad de Ingeniería – UNLPam.

Analista Programador en Computación


www.ing.unlpam.edu.ar

Laboratorio
Contenido
Lic. Guillermo
•Requerimientos Javier Lafuente
•Casos de Uso
Requerimientos
 Especificación de requerimientos
 Una colección de documentos y modelos para describir
un sistema de software a ser construido
 El documento (de especificación) contiene:
– Descripción del propósito del documento
– Número de versión
– Contribuciones.
– Lista específica de requerimientos del sistema
 La especificación consiste
– Simple documento
» Sistemas pequeños
– Distribuida en múltiples documentos
» c/u expresando una categoría de requerimientos
Requerimientos
 Sentencia (enunciado) de requerimiento
Es un requerimiento o restricción que el sistema
debe observar.
 Es usualmente expresado como una sentencia
que comienza:
– “El sistema deberá....”
– El propósito de una sentencia de requerimiento es
para expresar un comportamiento o una propiedad
que el sistema debiera tener.
– Las sentencias (frases) deben ser claras
» Para ser entendidas por el equipo de desarrollo
» Validadas por los stakeholders y la comunidad de usuarios
Requerimientos
 Clasificación de requerimientos
 Funcional
– Expresan una acción que el sistema debiera realizar y define
tanto los estímulos como las respuestas, o las entradas y las
salidas
– Identifica las cosas que el sistema puede hacer
 No Funcional
– Restricciones globales sobre cómo debe construirse y funcionar
el sistema
 De la Empresa
– Razones de la creación del sistema
– Restricciones del ambiente en el que el sistema funciona
Requerimientos No Funcionales

Clasificación Requerimientos no Funcionales (RNF)

 Usabilidad (Usability)
 Perfomance
 Confiabilidad (Robustness/Reliability)
 Seguridad (Security)
 Hardware
 De desarrollo (development)
Requerimientos No Funcionales

 Usabilidad (Usability)
Se refiere a todos aquellos aspectos de la
interface entre el usuario y el sistema

El software, es fácil de usar y de aprender?

Ej.
» Comprensión Global del Sitio
» Ayuda y Retroalimentación
» Aspectos de Interface (Ej. el sistema no deberá usar Frames)
» Aspectos Estéticos
Requerimientos No Funcionales

 Usabilidad
 Comprensión Global del Sitio
– Esquema de Organización Global
» Tabla de Contenidos
» Mapa del Sitio
» Indices (Alfabéticos, Temáticos, Híbridos ...)
– Visita Guiada (convencional y/o virtual)
 Aspectos de Interfaces y Estéticos
– Permanencia y Estabilidad en la Presentación de los Controles
Principales
» Controles Directos
» Controles Indirectos
» Estabilidad
– Mantenimiento del Color de los Enlaces
Requerimientos No Funcionales
 Perfomance
 Los requerimientos de perfomance describen la
eficiencia de la ejecución del sistema y están
relacionados con el tiempo.

 Es rápido y minimalista en cuanto a uso de recursos,


bajo ciertas condiciones?

 Ej.
» Tiempo de descarga de una página
» Restricciones de tiempo
» Velocidad de procesamiento de una transacción
Requerimientos No Funcionales
 Confiabilidad (Robustness/Reliability)
 Las aplicaciones deben responder correctamente en
cada momento a las necesidades de los usuarios.

 Puede mantener el nivel de rendimiento, bajo ciertas


condiciones y por cierto tiempo?

 Ej.
» Tolerancia a fallas
» Recuparabilidad
» Nivel de madurez – Frecuencia de errores
» Backups
Requerimientos No Funcionales
 Seguridad (Security)
 Los requerimientos de seguridad tienden a especificar
niveles de acceso al sistema.
– A menudo mapean los roles humanos del negocio
 Especifican los niveles de accesos de sistemas externos

 El sistema me brinda la confidencialidad de los datos?


 Ej:
» permiso de acceso
» niveles de seguridad
» Encriptamiento de información

– “El sistema deberá asegurar que toda la información


confidencial provista por los clientes via Internet deberá ser
encriptada”
Requerimientos No Funcionales

Hardware
Se refieren al hardware mínimo requerido para
implementar el sistema

Ej.
– Utilización de video y voz en sitios Web
» Radios, Canales de TV, etc.

» Una aplicación intranet interna que usa multimeda como un


video o VRML (Virtual Reality Modeling Languaje) puede
requerir que el sistema tenga que ejecutarse sobre una pc
pentium III, 128MB RAM SVGA 1024x768x16
Requerimientos No Funcionales

De desarrollo (development)


 Describen cómo la aplicación es entregada a los
usuarios finales.

 Provee restricciones sobre cómo el sistema va ha ser


instalado, mantenido y accedido por el personal de
mantenimiento.

– Un requerimiento de desarrollo para una aplicación Web puede


requerir que todos los paquetes de software clientes sean
descargados e instalados desde el navegador y no requiera que
el cliente reinicie el SO o realice un instalación manual.
» Instalación de plug-in
Casos de Uso

Los Requerimientos Funcionales (RF)


“Restricciones globales sobre cómo debe construirse y funcionar el
sistema”
Se estructuran de forma natural mediante
casos de uso (CU).
La mayoría de los RNF son específicos de un
solo CU y pueden tratarse en el contexto de ese
CU.
Los RNF restantes, comunes para muchos o
para todos los CU, se mantienen en un
documento a parte y se denominan
requerimientos adicionales.
Casos de Uso

 Los CU proporcionan un medio intuitivo y


sistemático para capturar los requisitos
funcionales.

 Mediante la utilización de los CU los


analistas se ven obligados a pensar:
 En términos de quienes son los usuarios
 y qué necesidades u objetivos de la empresa
pueden cumplir.
Diagramas de Casos de Usos
 Un diagrama (o modelo) de Casos de Uso muestra
las distintas operaciones que se esperan de una
aplicación o sistema y cómo se relaciona con su
entorno (usuario u otras aplicaciones).
 Es una herramienta esencial para la captura de
requerimientos y para la planificación y control de un
proyecto interactivo.
 Permite que los desarrolladores de software y los
clientes lleguen a un acuerdo sobre los
requerimientos que debe cumplir el sistema.
 Un diagrama de CU contiene casos de uso, actores,
u sus relaciones.
Diagramas de Casos de Usos
 Los Casos de Uso se representan en el diagrama
por una elipse que denota un requerimiento
solucionando por el sistema.

Caso de Uso

 Cada CU es una operación completa desarrollada


por los actores y por el sistema en un diálogo.

 El conjunto de CU representa la totalidad de


operaciones desarrolladas por el sistema.
Elementos del Casos de Uso
 Actor: Es un usuario del sistema, que
necesita o usa alguno de los CU.
Un usuario puede jugar más de un rol. Un solo
actor puede actuar en muchos CU;
recíprocamente, un CU puede tener varios
actores.
Los actores no necesitan ser humanos pueden
ser sistemas externos que necesitan alguna
información del sistema actual.
Actores y Casos de uso
- Actor: alguien o algo que interactua con el sistema

profesor estudiante supervisor sistema de facturacion

- Caso de uso: es una forma específica con la cual el actor


puede interactuar con el sistema (lo que puede hacer el actor en
el sistema).
- Los casos de uso describen una sequencia particular de
eventos que ocurren en el sistema.
- Para saber que casos de uso hay, podemos preguntarnos:
¿Que necesidades tienen los actores?
Actores y Casos de uso
Profesor - saber la lista de asistentes
Estudiante - mantener su horario
Sistema facturacion - recibir información cuando el
estudiante se registra.
Supervisor - mantener los cursos

Pedir lista de asistentes Mantenimento del Mantenimiento de los


horario cursos
Diagrama de casos de uso

Pedir lista de asistentes Profesor

Mantenimento del
Estudiante horario

Sistema de Supervisor
facturación Mantenimiento de los
cursos
Diagramas de Casos de Usos

comunica

<<extend>>
Actualizar Carga
Académica Elaborar Informe
De Actividades

Profesor Actualizar Carga <<extend>> <<include>>


Administrativa
Elaborar Planific.
De Actividades
Pedir Permiso

Ejemplo 2.
Elementos del Casos de Usos
Relaciones:
Comunica: <<comunicates>>
Entre un actor y un caso de uso, denota la
participación del actor en el caso de uso
determinado.

En el Ej. 2 el actor profesor se relaciona con los


caso de uso pedir permiso, Actualizar carga
administrativa y Actualizar carga Académica.
Elementos del Casos de Usos
Relaciones:
Incluye <<include>> o Usa <<use>>
Relación entre dos casos de uso, denota la
inclusión del comportamiento de un escenario en
otro. Se utiliza cuando se repite un caso de uso
en dos o más casos de uso separados.
Elementos del Casos de Usos
Relaciones:
Extiende <<extends>>
Relación entre dos casos de uso, y denota un
caso de uso que es una especialización de otro.
Se usa cuando se describe una variación sobre
el normal comportamiento.
En el Ej. 2 la relación extend se utiliza para
denotar que los escenarios actualizar carga
administrativa y actualizar carga académica son
especializaciones del caso de uso elaborar
informe de actividades.
Elementos del Casos de Usos
Relaciones:
Generalización: Relación entre dos o mas
actores.
Se utiliza para denotar categoría de actores
generales y especializados

Cliente

Cliente Cliente
individual corporativo
Caso de Uso - descripción
Campos usados en la descripción:

1. Nombre del caso de uso.


2. Actores - actores que interactuan con el caso de uso.
3. Propósito - intencionalidad del caso de uso (una frase)
4. Descripción - breve descripción del caso de uso (3 o 4 lineas)
5. Precondiciones - condiciones que se han de cumplir.
6. Postcondiciones - el resultado del proceso.
7. Pasos - sequencia de pasos. Camino básico
8. Flujo excepcional- (o camino alternativo) variaciones en los
pasos que producen un resultado distinto al esperado.
Ejemplo - comprar artículos
Punto de venta

Comprar Artículos

Identificarse Cliente
Cajero

Devolver dinero de
articulos adquiridos
Descripción
Caso de uso: Comprar Artículo
Actores: Cliente, Cajero
Propósito: Capturar una venta y el pago en dinero.
Descripción: Un cliente llega a la caja con artículos para comprar. El
cajero marca los artículos comprados y obtiene el pago en dinero. Al
final el Cliente se marcha con los artículos.
Precondición: La caja está abierta.
Postcondición: El cajero obtiene el pago del artículo.
Descripción (cont)
Pasos:
Actores Respuesta del sistema
1. El cliente llega a la caja con artículos
2. El cajero marca el identificador 3. Determina el precio y añade la información
de cada articulo. y lo añade a la transacción de venta.
(si hay +1, marcar cantidad) (se muestra descripción y precio del articulo)
4. El cajero indica a la caja que 5. Calcula y presenta el total
ya se entraron los artículos
6. El cajero dice el total al cliente
7. El cliente da el dinero (puede que de +)
8. El cajero marca el dinero recibido 9. Muestra el cambio al cliente
10. El cajero deposita el dinero y le da al 11. La venta se registra
cliente el cambio y el recibo
12. El cliente sale con los articulos.
Bibliografía

Building Web Applications with UML


Autor: Conallen, Jim
Editorial Addison-Wesley, 1999
ISBN 020161577

El Lenguaje unificado de Modelado


Autores: Grady Booch, James Rumbaugh, Ivar
Jacobson
Editorial Addison-Wesley, 1999
ISBN: 8478290281
Bibliografía
Sitio Web de Jim Conallen
http://www.conallen.com

You might also like