Documentación generada en el ciclo de vida
1
Fase análisis: Documento de requisitos de software (SRD)
Contiene una especificación precisa y completa de lo que tiene
que hacer el software, sin entrar en detalles técnicos.
Es decir, explica detalladamente en lenguaje natural lo que el
software va a realizar, por medio de una lista detallada de
requisitos. Se pondrá especial cuidado en evitar contradicciones
y ambigüedades.
Si es necesario porque pudiese haber lugar a duda, se
especificará también lo que NO se va a hacer.
Este documento se genera a partir de reuniones mantenidas con
el cliente.
2
El documento de requisitos debe tener las siguientes
propiedades:
• Completo y sin omisiones
• Conciso y sin trivialidades
• Sin ambigüedades
• Sin detalles de diseño o implementación
• Fácilmente entendible por el cliente
• Separando requisitos funcionales y no funcionales
• Dividiendo y jerarquizando el modelo
• Debe fijar los criterios de validación del sistema (cuándo se
puede considerar que el sistema es válido)
3
Requisitos funcionales y NO funcionales
Un requisito funcional es aquel que necesita el usuario que
tenga el software.
Un requisito NO funcional es aquel que viene impuesto por
otros factores (capacidad del sistema, velocidad de respuesta,
recursos necesarios…), o que no realizará el software pero se
debe hacer para su correcto funcionamiento (responsabilidades
de los usuarios o técnicos).
4
¿Requisito funcional o no funcional?
• Se podrán consultar los usuarios.
• El coordinador tendrá que dar de alta a los usuarios manualmente.
• Trimestralmente se revisará el software para ver si hay que hacer algún
tipo de evolutivo.
• Cuando se elimine un usuario, se deberá eliminar también su histórico.
• Será necesario que las máquinas cuenten con 16 gigas de ram.
• El máximo de usuarios será de 100.
5
¿Requisito funcional o no funcional?
• Se podrán consultar los usuarios. FUNCIONAL
• El coordinador tendrá que dar de alta a los usuarios manualmente. NO
FUNCIONAL
• Trimestralmente se revisará el software para ver si hay que hacer algún
tipo de evolutivo. NO FUNCIONAL
• Cuando se elimine un usuario, se deberá eliminar también su histórico.
FUNCIONAL
• Será necesario que las máquinas cuenten con 16 gigas de ram. NO
FUNCIONAL
• El máximo de usuarios será de 100.
Si el máximo viene determinado por el entorno: NO FUNCIONAL, si es porque así se
desea: FUNCIONAL
6
Estructura del documento de requisitos
El siguiente modelo está basado en la propuesta de la Agencia
Espacial Europea.
No siempre necesitaremos rellenar todos los apartados, en los
casos en los que no lo veamos necesario, indicaremos en el
apartado “No aplica”.
7
1. INTRODUCCIÓN
1.1. Objetivo
Debe exponer brevemente el objetivo del proyecto, a quién va
dirigido, los participantes y el calendario previsto.
1.2. Ámbito
Se dará nombre al producto o productos resultantes, y se
explicará qué hace cada producto y qué no será capaz de hacer
(si fuese necesario). Además se detallarán las aplicaciones y
beneficios del proyecto.
8
1.3. Definiciones, siglas y abreviaturas
Glosario de definiciones de términos, siglas y abreviaturas que
contiene el documento.
1.4. Referencias
Si el documento contiene referencias a otros documentos, se
dará una lista bibliográfica, y dónde encontrarlos.
1.5. Panorámica del documento
Descripción de la organización y contenido del resto del
documento.
9
2. DESCRIPCIÓN GENERAL
2.1. Relación con otros proyectos
Se describirán coincidencias y diferencias entre el proyecto con
otros similares.
2.2. Relación con proyectos anteriores y posteriores
Se indicará si el proyecto es continuación de otro o si se
continuará.
10
2.3. Objetivo y funciones
Se describirá el sistema en su conjunto con los objetivos y las
funciones principales.
2.4. Consideraciones de entorno
Se describirán las características especiales que debe tener el
entorno en que se vaya a utilizar el software.
2.5. Relaciones con otros sistemas
Se describirán las conexiones del sistema que otros, si debe
funcionar integrado con ellos o utilizando entradas o salidas
indirectas de información.
11
2.6. Restricciones generales
Restricciones generales a tener en cuenta a la hora de diseñar y
desarrollar el sistema: metodologías de desarrollo, lenguajes de
programación, sistema operativo del entorno de desarrollo…
2.7. Descripción del modelo
Describe el modelo conceptual que se propone para desarrollar
el sistema en su conjunto y para cada una de las partes. Puede
incluir desde descripciones en lenguaje natural hasta diagramas
(importante que sean comprensibles por cualquier persona no
técnica) que hagan fácil su entendimiento (veremos algunos de
estos diagramas en la unidad 2).
12
3. REQUISITOS ESPECÍFICOS
3.1. Requisitos funcionales
Es el apartado más importante de todo el documento. Describe
qué debe hacer el sistema (muy ligado al modelo conceptual).
Debe ser una lista numerada y detallada de requisitos que debe
cumplir el sistema.
3.2. Requisitos de capacidad
Referentes a volumen de información a procesar, tiempo de
respuesta, tamaños de ficheros… Deben concretar valores
específicos, e incluso se pueden indicar valores para el peor,
mejor y caso más habitual.
13
3.3. Requisitos de interfaz
Referentes a cualquier conexión a otros sistemas con los que se
debe interactuar (bases de datos, formatos de ficheros, sistemas
operativos… a intercambiar con otros sistemas o aplicaciones).
3.4. Requisitos de operación
Referentes al uso general del sistema e incluyen la interfaz de
usuario (menús, manejo con ratón, teclado etc), arranque y
parada, copias de seguridad, requisitos de instalación y
configuración.
14
3.5. Requisitos de recursos
Referentes a elementos hardware y software, instalaciones etc,
necesarios para el funcionamiento del sistema. Se deberá hacer
una estimación al alza.
3.6. Requisitos de verificación
Requisitos que debe cumplir el software para que sea posible
certificar que funciona correctamente.
15
3.7. Requisitos de pruebas de aceptación
Son los que deben cumplir las pruebas de aceptación (pruebas
necesarias para liberar el software) a las que se someterá al
sistema.
3.8. Requisitos de documentación
Referentes a la documentación que debe formar parte del
producto a entregar.
3.9. Requisitos de seguridad
Referentes a la protección del sistema contra utilización
indebida.
16
3.10. Requisitos de transportabilidad
Referentes a la posible utilización en diversos entornos o
sistemas operativos de forma sencilla.
3.11. Requisitos de calidad
Referentes a aspectos de calidad, que no se incluían en otros
apartados.
3.12. Requisitos de fiabilidad
Referentes al límite aceptable de fallos o caídas durante la
utilización del sistema.
17
3.13. Requisitos de mantenibilidad
Son los que debe cumplir el sistema para que se pueda realizar
adecuadamente su mantenimiento durante la fase de
explotación.
3.14. Requisitos de salvaguarda
Son los que debe cumplir el sistema para evitar que los errores
en el funcionamiento tengan consecuencias graves en los
equipos o personas.
18
4. APÉNDICES
Se incluirá todo aquello que complete el contenido del
documento, y que no esté recogido en otros documentos
accesibles en el apartado “1.4. Referencias”.
19
Fase diseño: Documento de diseño de software (SDD)
Contiene todos los diseños del software para cumplir con las
especificaciones.
Por ejemplo: Diagrama entidad/relación, diagrama de flujo,
UML…
20
Fase codificación: Código fuente
Contiene los códigos fuente, en los lenguajes de programación
elegidos, debidamente comentados para que se entiendan
fácilmente.
Previa a esta fase, en ocasiones algunos perfiles más
experimentados realizan los cuadernos de carga, que es
pseudocódigo que posteriormente puede implementar cualquier
perfil.
A veces también se documentan los programas externamente,
por ejemplo en una wiki de fácil acceso para otros
desarrolladores.
21
Fase integración: Documento de integración
Contiene el procedimiento para integrar el software, así como
todas las pruebas realizadas, incluyendo el resultado obtenido
en cada caso de prueba.
Los documentos de pruebas se realizan a partir de las
especificaciones. Es importante cubrir todas las casuísticas que
pueden darse en el software, y comprobar que se comporta
correctamente para cada uno de ellos.
Normalmente es necesario realizar varios ciclos de pruebas, que
deben documentarse.
22
Fase explotación: Manual técnico y de usuario
Antes de poner en producción el software, se preparará un
manual técnico que contendrá todo lo que un perfil técnico
necesita saber sobre el uso del mismo (por ejemplo: gestión de
contraseñas, creación de usuarios…).
También se preparará un manual de usuario destinado a explicar
el uso general del mismo, para que esté disponible para los
usuarios que lo vayan a utilizar. Adicionalmente, cuando el
software va a implantarse en una empresa, se suele dar
formación a los usuarios.
23
Fase mantenimiento: Documentos de cambios
Cada modificación realizada quedará documentada. Los
documentos de cambios suelen tener la siguiente estructura:
• Información sobre el problema detectado o mejora que se
propone.
• Descripción de la solución adoptada.
• Modificaciones realizadas sobre el sistema, que incluirán
todos los documentos anteriores vistos (los documentos se
irán generando en las fases que corresponde):
• Documento de requisitos
• Documento de diseño
• Código fuente
• Documento de integración
24
