Especificación de requerimientos, Ingenieria de Software

1. l o
ue er
ig m
M o
n nR
Sa rvi
B a
G M
U c.
Li
Especificación de requerimientos
www.miceminfo.net

2. l o
ue er
ig m
M o
Documento de especificación del sistema
n nR
Sa rvi
1. Definición del problema
B a
G M
2. Descripción funcional
3.
U c.
Restricciones
Li
4. Diagramas de flujo de datos
5. Modelo de datos
6. Diccionario de datos
7. Casos de uso
8. Documentos adicionales
www.miceminfo.net

3. Especificación de requerimientos
l o
ue er
ig m
M o
Requerimientos
n nR
Definición
Sa rvi
Requerimientos funcionales y no funcionales
B a
G M
U c.
Especificación de requisitos en lenguaje natural
Li
Casos de uso
Documento de especificación del sistema
www.miceminfo.net

4. Requerimientos
l o
ue er
ig m
M o
Los requerimientos/requisitos de un sistema
n nR
describen los servicios que ha de ofrecer el sistema
Sa rvi
y las restricciones asociadas a su funcionamiento.
B a
G M
U c.
Li
Requerimientos:
Propiedades o restricciones
determinadas de forma precisa
que deben satisfacerse.
www.miceminfo.net

5. Requerimientos
funcionales y no funcionales
l o
ue er
ig m
M o
n nR
Requerimientos funcionales:
Sa rvi
Expresan la naturaleza del funcionamiento del sistema
B a
G M
(cómo interacciona el sistema con su entorno y cuáles
van a ser su estado y funcionamiento).
U c.
Li
NOTA: A veces, también es conveniente
indicar lo que no hará el sistema.
www.miceminfo.net

6. Requerimientos
funcionales y no funcionales
l o
ue er
ig m
M o
n nR
Requerimientos no funcionales:
Sa rvi
Restricciones sobre el espacio de posibles soluciones.
B a
G M
Rendimiento del sistema:
U c.
Fiabilidad, tiempo de respuesta, disponibilidad…
Li
Interfaces:
Dispositivos de E/S, usabilidad, interoperabilidad…
Proceso de desarrollo:
Estándares, herramientas, plazo de entrega…
www.miceminfo.net

7. Requerimientos
funcionales y no funcionales
l o
ue er
ig m
M o
n nR
Los requisitos funcionales definen
Sa rvi
qué debe hacer un sistema.
B a
G M
U c.
Li
Los requisitos no funcionales definen
cómo debe ser el sistema.
www.miceminfo.net

8. Requerimientos
funcionales y no funcionales
l o
ue er
ig m
M o
A los requisitos no funcionales se les suele llamar
n nR
coloquialmente “cualidades” del sistema [“-ilities” en
[“-ilities”
Sa rvi
inglés”] y pueden dividirse en dos categorías:
categorías:
B a
G M
Cualidades de ejecución,
ejecución,
U c.
como la seguridad o la usabilidad,
usabilidad,
Li
observables en tiempo de ejecución.
ejecución.
Cualidades de evolución,
evolución,
como la “testabilidad”, mantenibilidad, extensibilidad o
“testabilidad”, mantenibilidad,
escalabilidad,
escalabilidad, determinadas por la estructura estática
del software.
www.miceminfo.net

9. Requerimientos
funcionales y no funcionales
l o
ue er
ig m
M o
La distinción entre requerimientos funcionales y no
n nR
funcionales no siempre resulta evidente.
Sa rvi
B a
Ejemplo: La seguridad puede interpretarse inicialmente
G M
como un requerimiento no funcional al principio. No
U c.
obstante, su elaboración puede conducir a nuevos
Li
requerimientos funcionales, como la necesidad de
autentificar a los usuarios del sistema.
Más allá de si decidimos incluir este tipo de requisitos
en una sección u otra, lo importante es identificarlos
correctamente.
8
www.miceminfo.net

10. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
Los requerimientos…
n nR
Sa rvi
se suelen especificar en lenguaje natural,
B a
G M
se expresan de forma individual
U c.
(p.ej. esquemáticamente),
Li
se organizan de forma jerárquica
(a distintos niveles de detalle),
a menudo, se numeran
(para facilitar su gestión),
9
www.miceminfo.net

11. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
Los requerimientos han de ser…
n nR
Sa rvi
claros y concretos
B a
G M
(evitando imprecisiones y ambigüedades)
U c.
p.ej. Uso de puntos suspensivos, etcétera…
Li
concisos
(sin rodeos ni figuras retóricas),
completos y consistentes,
consistentes,
www.miceminfo.net

12. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
Los requerimientos han de indicar…
n nR
Sa rvi
lo que se espera que haga el sistema (¿qué?),
B a
G M
U c.
su justificación
Li
(¿por qué ha de ser así? ¿quién lo propuso?) y,
en su caso, los criterios de aceptación que sean
aplicables (¿cómo se verifica su cumplimiento?).
11
www.miceminfo.net

13. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
Los requerimientos funcionales…
funcionales…
n nR
Sa rvi
deben estar redactados de tal forma que sean
comprensibles para usuarios sin conocimientos
B a
G M
técnicos avanzados (de Informática, se entiende),
U c.
Li
deben especificar el comportamiento externo del
sistema y evitar, en la medida de lo posible, establecer
características de su diseño,
deben priorizarse (al menos, se ha de distinguir entre
requisitos obligatorios y requisitos deseables).
12
www.miceminfo.net

14. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
Los requerimientos no funcionales…
funcionales…
n nR
Sa rvi
han de especificarse cuantitativamente,
B a
G M
siempre que sea posible
(para que se pueda verificar su cumplimiento).
U c.
Li
13
www.miceminfo.net

15. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
MAL
n nR
Sa rvi
Para facilitar el uso del editor gráfico, se podrá activar
B a
y desactivar una rejilla que permitirá alinear las figuras
G M
del diagrama. Cuando se ajuste la figura al tamaño de
U c.
la pantalla, se reducirá el número de líneas de la rejilla
Li
para que no se dificulte la visualización del diagrama.
¿Por qué?
Amalgama de varios requisitos.
14
www.miceminfo.net

16. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
BIEN
n nR
Sa rvi
El editor permitirá el uso de una rejilla de líneas
B a
horizontales y verticales que aparecerán dibujadas
G M
tras el diagrama.
U c.
Li
Justificación:
Justificación: La rejilla facilita la creación de diagramas
cuidados en los que las figuras se puedan alinear con facilidad
(Manual Práctico de Usabilidad, sección 15.3).
¿Por qué?
Preciso, conciso y justificado correctamente.
15
www.miceminfo.net

17. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
MAL
n nR
Sa rvi
El sistema será lo más fácil de utilizar posible.
B a
G M
El sistema proporcionará una respuesta rápida al
usuario.
U c.
Li
El sistema se recuperará automáticamente tras
producirse un fallo.
¿Por qué?
Objetivos generales, vagos
y abiertos a distintas interpretaciones. 16
www.miceminfo.net

18. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
BIEN
n nR
Sa rvi
Un usuario experimentado debe ser capaz de utilizar
B a
todas las funciones del sistema tras un entrenamiento
G M
de 2 horas, tras el cual no cometerá más de 3 errores
U c.
diarios en media.
Li
Cuando haya hasta 100 usuarios accediendo
simultáneamente al sistema, su tiempo de respuesta
no será en ningún momento superior a 2 segundos.
www.miceminfo.net

19. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
BIEN
n nR
Sa rvi
Ante un fallo en el software del sistema, no se tardará
B a
más de 5 minutos en restaurar los datos del sistema
G M
(en un estado válido) y volver a poner en marcha el
U c.
sistema.
Li
¿Por qué?
Requisitos verificables.
18
www.miceminfo.net

20. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
PROBLEMAS HABITUALES:
n nR
Sa rvi
La existencia de un requerimiento
B a
G M
ha de estar debidamente justificada
(debemos saber por qué es un requisito del sistema).
U c.
Li
Un requerimiento es, a veces, difícil de verificar
(especialmente, si es un requisito no funcional).
Además, si somos incapaces de especificarlo,
¿cómo sabemos que realmente es un requisito?
19
www.miceminfo.net

21. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
EJEMPLO: REQUERIMIENTOS FUNCIONALES
M o
Matriculación
n nR
La matrícula será realizada de forma interactiva. Se le preguntará al alumno cuál
es el plan de estudios en que desea matricularse (pueden ser varios).
Sa rvi
Se podrá generar una copia impresa de la matrícula (sin valor oficial) en el
ordenador desde donde se realice el proceso de matriculación.
B a
G M
Se podrá generar el impreso de pago debidamente cumplimentado.
Para la matriculación se consultarán los datos del expediente y se realizarán las
U c.
validaciones necesarias, descritas a continuación…
Li
Pago de matrícula:
La aplicación generará un impreso para que el alumno realice el pago
correspondiente a la matrícula en 1 ó 2 plazos (según las fechas
establecidas).
Si el alumno tiene matrículas de honor de cursos anteriores o disfruta de
algún tipo de beca, la aplicación deberá calcular automáticamente los
descuentos correspondientes…
Organizados jerárquicamente
20
y desglosados en requisitos individuales
www.miceminfo.net

22. Especificación de requerimientos
en lenguaje natural
l o
ue er
ig m
M o
EJEMPLO: REQUERIMIENTOS
n nR
NO FUNCIONALES
Sa rvi
Interfaces
Hardware: El sistema se debe implementar sobre la infraestructura existente en
B a
G M
las aulas de prácticas de la E.T.S. Ingeniería Informática.
Software:
U c.
No existe posibilidad de adquirir licencias de software.
Li
La aplicación deberá funcionar sobre Oracle.
www.miceminfo.net

23. Casos de uso
l o
ue er
ig m
M o
Los casos de uso…
n nR
Sa rvi
Describen el modo en que un actor interactúa con el
B a
G M
sistema (descripción de un rol en lenguaje natural).
U c.
Li
Narran el comportamiento dinámico del sistema desde
un punto de vista concreto (el del actor).
Pueden expresar tanto requerimientos funcionales
como no funcionales.
22
www.miceminfo.net

24. Casos de uso
l o
ue er
ig m
M o
Los casos de uso…
n nR
Sa rvi
Son muy útiles para explicar el funcionamiento del
B a
G M
sistema, priorizar requerimientos cuando el sistema se
desarrolla de forma incremental, elaborar manuales de
U c.
Li
usuario y especificar pruebas de aceptación.
Mejoran la trazabilidad de los requerimientos durante
el proceso de desarrollo de software.
Se pueden desarrollar en paralelo con los
requerimientos del sistema de forma iterativa. 23
www.miceminfo.net

25. Casos de uso
l o
ue er
ig m
M o
Dependiendo de la situación, los casos de uso se
n nR
pueden especificar con distinto grado de detalle:
Sa rvi
B a
G M
Especificación textual de un caso de uso
(enumeración de pasos del caso de uso).
U c.
Li
Especificación “esencial” de un caso de uso
(eliminando todos los detalles no estrictamente necesarios).
Especificación detallada de un caso de uso
(utilizando una plantilla para no olvidarnos de nada).
24
www.miceminfo.net

26. Casos de uso
l o
ue er
ig m
Especificación textual de un caso de uso (1/2)
M o
n nR
Actor Profesor
Sa rvi
Rol Consultar estadísticas
B a
G M
El profesor ejecuta el programa de consulta de estadísticas.
Se le pide su identificativo (login) y palabra clave de acceso
U c.
(password).
Li
El sistema verifica la identificación del usuario.
Si la identificación es positiva, se presenta una lista con las
estadísticas disponibles:
Nº de alumnos y porcentaje de repetidores de sus
asignaturas.
Clasificación de alumnos por nota en cada asignatura.
25
www.miceminfo.net

27. Casos de uso
l o
ue er
ig m
Especificación textual de un caso de uso (2/2)
M o
n nR
Actor Profesor
Sa rvi
Rol Consultar estadísticas
B a
G M
…
Una vez que el profesor ha seleccionado una de las estadísticas,
U c.
el programa presenta los datos correspondientes a la misma,
Li
agrupando la información por asignaturas y, al final, para todas
sus asignaturas en conjunto.
Al profesor se le da la opción de imprimir la estadística.
Cuando el profesor termina de ver la estadística, se presenta de
nuevo la lista de estadísticas disponibles.
Si no desea ver otra estadística, termina la ejecución de la
aplicación. 26
www.miceminfo.net

28. Casos de uso
l o
ue er
ig m
Especificación esencial de un caso de uso
M o
Consulta de estadísticas
n nR
Sa rvi
Profesor Sistema
El profesor se identifica.
B a
G M
El sistema autentifica al profesor y le
U c. ofrece una lista de estadísticas disponibles.
El profesor selecciona una
Li
de las opciones disponibles.
El sistema presenta un informe con los
datos solicitados.
Si así lo desea, el profesor
imprime el informe.
27
www.miceminfo.net

29. Casos de uso
l o
ue er
ig m
Especificación detallada de un caso de uso (1/3)
M o
n nR
Nombre Consulta de estadísticas
Sa rvi
Descripción Se permite a los profesores consultar las
B a
estadísticas correspondientes a sus asignaturas
G M
Dependencias Autentificación de usuarios
U c.
Li
Actores Profesor (principal e iniciador)
Precondiciones -
Postcondiciones -
28
www.miceminfo.net

30. Casos de uso
l o
ue er
ig m
Especificación detallada de un caso de uso (2/3)
M o
n nR
Escenario principal Profesor Sistema
1. El profesor se
Sa rvi
identifica.
B a
2. El sistema autentifica al
G M
profesor y le ofrece una lista
U c. de estadísticas disponibles.
Li
3. El profesor
selecciona una de
las opciones.
4. El sistema presenta un
informe con los datos
solicitados.
5. Si así lo desea, el
profesor imprime el
29
informe.
www.miceminfo.net

31. Casos de uso
l o
ue er
ig m
Especificación detallada de un caso de uso (3/3)
M o
n nR
Alternativas 2. Si, tras un tercer intento, la
autentificación no se realiza
Sa rvi
con éxito, se guarda la
B a
incidicencia en un registro y
G M
se impide volver a acceder a
U c. la aplicación desde la misma
Li
IP durante 15 minutos.
Observaciones -
Requisitos El sistema debe estar preparado para aceptar 100
no funcionales sesiones simultáneas de profesores consultando
sus estadísticas sin degradar su rendimiento más
de un 50% con respecto a un usuario único.
30
www.miceminfo.net

32. Apartados del documento
de especificación del sistema
l o
ue er
ig m
M o
Definición del problema.
n nR
1.
2. Descripción funcional
Sa rvi
(lista de requerimientos funcionales)
B a
Restricciones
G M
3.
(requerimientos no funcionales)
U c.
Diagramas de flujo de datos
Li
4.
5. Modelo de datos
(diagrama E/R, CASE*Method o diagrama de clases UML)
CASE*Method
6. Diccionario de datos
7. Casos de uso
8. Documentos adicionales
(p.ej. modelos de informes y formularios) 31
www.miceminfo.net