Requerimientos Funcionales Y No Funcionales
Funcionales y No
Funcionales
Juan Pablo Quiroga
Dpto. de Ingeniería de
Sistemas y Computación
Universidad de los Andes
Re f e r e n c i a
El Lenguaje Unificado de Modelado.
Grady Booch, James Rumbaugh e Ivar
Jacobson. Addison Wesley, 1999.
Capítulos
16 y 17
1
Referencia requerimientos no
fu n c i o n a l e s
Object Oriented SoftwareEngineering.
Bernd Bruegge y Allen H.Dutoit.
Prentice Hall, 2000
Capítulo
4, pág. 100–106, 118-119
Software Requirements. Karl.
E.Wiegers. Microsoft Press, 1999.
Capítulo
9, pág. 153-162
Capítulo 11
Ag e n d a
Requerimientos funcionales
Levantamiento
de requerimientos
Casos de Uso (Requerimientos
Funcionales)
Requerimientos no funcionales
Diferencias
requerimientos funcionales, no
funcionales y pseudo requerimientos
Clasificación de los requerimientos no
funcionales y pseudo requerimientos
2
Requerimientos
Un requerimiento es una característica
que el sistema DEBE tener o es una
restricción que el sistema DEBE
satisfacer para ser aceptada por el
c l i e n te .
Levantamiento de requerimientos es laespecificación del sistema en términos
que el cliente entienda, de forma que se
constituya en el contrato entre el cliente
y los desarrolladores.
Requerimientos funcionales
Describen la interacción entre el
s i s te m a y s u a m b i e n te
independientemente de su
implementación.
El ambiente incluye al usuario y
cualquier otro sistema externo que
interactúa con el sistema.
3
Levantamiento de
Requerimientos
Para el levantamiento se pueden utilizar
dos conceptos:
Escenarios
Describen un ejemplo del uso del sistema en
términos de una serie de interacciones entre el
usuario y el sistema
Casos
de uso
Es una abstracción que describe una clase de
escenarios.
Ambos deben ser escritos en lenguaje natural
para que sean entendidospor el usuario.
Actividades
Identificación de actores
Diferentes
tipos de usuario (no personas
en particular)
Identificación de escenarios
Observar
al us uar io y des ar r ollar un
conjunto de escenarios detallados para la
funcionalidad típica que debe proveer el
sistema.
Identificación de casos de uso
S on
abstracciones que describen todos loscasos posibles descritos en los escenarios.
4
Actividades
Identificación de relaciones entre casos
de us o
Eliminar
redundancias entre los casos de
us o.
Hacer que la especificación del sistema
sea consistente.
1 . Id e n ti fi c a c i ó n d e a c to re s (1 )
Un actor representa un conjunto
coherente de roles, que son jugados
por una persona, undispositivo de
hardware o incluso otro sistema al
interactuar con nuestro sistema.
Se identifican son roles, es decir
usuarios que realizan un conjunto de
actividades definidas respecto a la
funcionalidad del sistema.
5
1 . Id e n ti fi c a c i ó n d e a c to re s Pre g u n t a s (2 )
Cuáles usuarios están soportados por
el sistema para desarrollar su trabajo?
Cuálesusuarios ejecutan las funciones
principales del sistema?
Cuáles usuarios desempeñan funciones
secundarias, como mantenimiento y
administración?
El sistema interactúa con hardware
externo o software?
1 . Id e n ti fi c a c i ó n d e a c to re s No t a c i ó n ( 3 )
Actor
Relación del
actor con el
sistema
6
2. Identificación de escenarios
(1 )
Un escenario es unadescripción
narrativa de cómo las personas hacen
las cosas y muestran como tratarían de
hacer uso del sistema.
El escenario es una descripción
concreta, enfocada e informalmente
descrita de una única característica
del sistema desde el punto de vista de
un único actor.
2. Identificación de escenarios
Nombre del
Consultar listado de cursos
(2)escenario
Instancias de
los...
Regístrate para leer el documento completo.