Tema V.

Requerimientos Funcionales
Versión: 1.1

Realizado por:
Profa. Ana María Padrón

Revisado por:
Prof. Nancy Zambrano UCV

Fecha:
Mayo de 2006

3.1 Requerimientos Funcionales

Los requerimientos funcionales definen el comportamiento interno del
software, es decir, sus tareas o funciones. Un requerimiento funcional se
describe con un nombre único, un breve resumen y una explicación, lo cual
ayudará a entender el requerimiento y hacerle seguimiento a lo largo del
desarrollo del software (trazabilidad). Al definir el requerimiento funcional se
debe describir el comportamiento que tendrá el software de forma clara y
legible.
 3.2 ¿Cómo obtener los Requerimientos Funcionales?
Para saber cual es el comportamiento que debe realizar el software, se
debe elicitar los requerimientos con los usuarios, stakeholders, y otros expertos
dentro de la organización haciendo uso de las técnicas de Elicitación.

3.3 ¿Características de los Requerimientos Funcionales?

Los requerimientos funcionales, al igual que los requerimientos en
general, deben ser claros, correctos, inequívocos, específicos, y comprobables.
Generalmente, los requerimientos funcionales se expresan mediante el
modelo de casos de uso.

3.3.1 Ejemplos
1) En el sistema telefónico celular algunos requerimientos funcionales son:
a) Recibir llamadas
b) Hacer llamadas
c) Enviar mensajes
d) Recibir mensajes
e) Conectarse a Internet

2) En un procesador de palabras algunos requerimientos funcionales son:

a) Incluir comandos para corrección de palabras
b) Guardar el documento
c) Copiar
d) Pegar
e) Cambiar el formato al texto

3.4 Casos de Uso

Los casos de uso son una técnica para la especificación de
requerimientos funcionales propuesta inicialmente por Jacobson y que
actualmente forma parte de la propuesta de UML. Un caso de uso muestra la
secuencia de interacciones entre el sistema y uno o más actores, para lograr la
funcionalidad expresada, en la que se considera al sistema como una caja
negra y en la que la que los actores obtienen resultados observables. Los
actores son personas u otros sistemas que interactúan con el sistema cuyos
requerimientos se están describiendo.
Los casos de uso presentan ciertas ventajas sobre la descripción
puramente textual de los requerimientos funcionales, en función a que
permiten expresar los requerimientos de una forma estándar. Además, pueden
servir de base a las pruebas del sistema y a la documentación para los
usuarios.

3.5 Diagramas de casos de uso

Los casos de uso tienen una representación gráfica denominada
diagramas de casos de uso. En estos diagramas, los actores se representan en
forma de pequeños muñecos y los casos de uso se mediante elipses contenidas
dentro de un rectángulo que representa al sistema. La participación de los
actores en los casos de uso se indica mediante una flecha que une al actor y al
caso de uso. Cada caso de uso debe tener una descripción textual.
Los diagramas de casos de uso sirven para proporcionar una visión global
del conjunto de casos de uso de un sistema (todas sus funcionalidades) así
como de los actores y los casos de uso que intervienen. Las interacciones
concretas entre los actores y el sistema no se muestran en este tipo de
diagramas.

Sistema

Caso de uso A

Caso de uso B

Actor 1 Actor 2

Caso de uso C
Figura 1. Diagrama de casos de uso

3.6 Relaciones entre casos de uso

A veces conviene establecer un refinamiento de los casos de uso para
mostrar claramente las interacciones. Las dos relaciones posibles y sus
semánticas según UML son las siguientes:
▪ Includes: Se dice que un caso de uso A incluye al caso de uso B, cuando B es
parte del caso de uso A, es decir, el comportamiento expresado en B forma
parte del comportamiento de A. El caso de uso B se realiza siempre dentro del
caso de uso A. Además, siempre que ocurre A ocurre también B, por lo que se
dice que Bes un caso de uso abstracto.
Un caso de uso es abstracto si no puede ser realizado por sí mismo, por
lo que sólo tiene significado cuando se utiliza para describir alguna
funcionalidad que es común a otros casos de uso. Por otra parte, un caso de
uso será concreto si puede ser iniciado por un actor y realizado por sí mismo.
Se suele utilizar esta relación cuando se detectan subsecuencias de
interacciones comunes a varios casos de uso.

include B
A
Ir al cine Comprar
entrada

Figura 2. Relación de Inclusión (include) entre casos de uso

▪ Extends: Un caso de uso A extiende a otro caso de uso B, cuando A expresa

un comportamiento posible de B, que ocurre en una determinada
circunstancia. El caso de uso A puede realizarse o no cuando se realiza el caso
de uso B, según las circunstancias.

Figura 3. Relación de extensión (extend) entre casos de uso

extend
B: Ir al A: Comprar
cine cotufas
 Figura 4. Representaciones de las relaciones includes y extendes

3.7 Organización de casos de uso

En la mayoría de sistemas, el número de casos de uso es lo
suficientemente elevado como para que sea oportuno organizarlos de alguna
forma, en lugar de tener una lista plana por la que no es fácil navegar. Una
posible forma de organizar los casos de uso es recurrir a los paquetes descritos
en UML. De esta forma, los casos de uso pueden organizarse en niveles,
facilitando así su comprensión.
Cada paquete contiene a otros paquetes o a varios casos de uso. Cuando
los casos de uso se agrupan por criterios funcionales, los paquetes que los
contienen pueden denominarse subsistemas, como se ve en la siguiente figura:
Figura 5. Organización de los Casos de Uso

3.8 Ejercicios resueltos

1) Tomando como caso de estudio el Punto de venta en un supermercado,
realizar el diagrama de casos de uso.
Para realizar un caso de uso se deben realizar varios pasos:
a) Describir el procedimiento que se realiza en un punto de venta,
identificando los escenarios claves y las actividades que se realiza en
cada escenario: En éste caso, existen dos escenarios denominados
Procesar venta y Efectuar Pago. A continuación se identifican las
actividades propias de cada escenario:
Procesar venta
 El Cajero comienza una nueva venta inicializando una caja de la tienda
 El Cajero introduce por cada producto la identificación del producto y
la cantidad
– El sistema registra y presenta la línea de venta de producto (la
descripción del artículo, precio y el total asi como el total
acumulado)
  El cajero finaliza la venta
– El sistema presenta el total con el impuesto calculado

Efectuar Pago
 El cajero muestra el total a cobrar, recibe el pago, cancela la venta (y
entrega ticket)
– El sistema maneja el pago.

b) Identificar los actores presentes: El actor de un punto de venta es el

Cajero.
c) Realizar el diagrama de casos de uso, indicando las interacciones del
actor (cajero) con el sistema:

a
Vent
d e
u nto
P e
lud
inc
e
lud
inc
e
lud Iniciar
inc

Procesar e
lud Introducir
Venta
inc Id

Cajero
Introducir
Procesar cantidad
Pago

Totalizar

2) Caso de uso para el Juego del ahorcado. Los pasos a seguir son:
a) Descripción del procedimiento: En el juego del ahorcado participan dos
personas, el jugador y el juez; el primero es quien solicita la palabra y
dice la letra y el segundo es quien evalúa el juego del jugador. El
procedimiento para jugar es el siguiente:
▪ El jugador solicita una palabra y el juez presenta el esquema de la
palabra
▪ El jugador dice una letra y el juez la marca
▪ El juez examina si la letra existe o no en la palabra:
▪ Si la letra existe en la palabra se coloca en la o las posiciones
correctas: Si es la última letra de la palabra, el jugador gana el juego
▪ Si la letra no existe en la palabra, el juez coloca una parte de la
horca. Si es la última parte de la horca el jugador pierde el juego

b) Identificar los actores: El juez y el jugador

c) Realizar el Diagrama de Caso de Usos:
Nota: Los ejemplos de Casos de Uso presentados se extrajeron de un material
elaborado por la Prof. Nancy Zambrano (UCV)

3.9 Ejercicios propuestos

Realice el caso de uso para los siguientes casos:
1) Creación de un grupo o comunidad virtual en yahoo.com
2) Compra del ticket del metro, tanto por taquilla como por la máquina
3) Comprar café en una máquina expendedora
4) Ingresar al comedor de la UBV

Bibliografía
▪ Durán A. y Bernárdez B. Metodología para la Elicitación de Requisitos de
Sistemas Software Versión 2.3. Universidad de Sevilla. Abril 2002.

▪ Functional Requirements. Disponible en el URL:

http://en.wikipedia.org/w/index.php?
title=Functional_requirements&redirect=no

▪ Functional Requirements and Use Cases. Disponible en el URL:

http://www.bredemeyer.com/use_cases.htm