5. Requerimientos de software
¿Qué vamos a aprender?
•
¿Qué son los
requerimientos de software
?
•
Tipos
de requerimientos
•
Actividades
para definir los requerimientos
•
Prácticas de Requerimientos de Software:
–
Entender los requerimientos
–
Detallar los casos de uso
–
Definir casos de prueba para los casos de uso
–
Prototipo de interfaz de usuario
–
Definir los requerimientos no funcionales
¿Qué es un requerimiento?
• Un requerimiento expresa una necesidad y restricción que
debe tener un producto de software para contribuir a resolver un problema del mundo real (SWEBOK, 2014).
• Los requerimientos de un producto de software son las
descripciones de lo que hará, los servicios que proporcionará
y las restricciones de su operación.
¿Cómo se expresan los requerimientos?
• Lenguaje natural – texto
• Forma gráfica – diagramas
• Prototipo de interfaz de usuario – pantallas
Verificación y validación de
requerimientos (1)
• Se busca claridad, precisión y no ambigüedad para el desarrollador y para el cliente
• Requerimiento bien definido es el que es verificable
• Verificable significa saber como lo vamos a probar cuando ya
Verificación y validación de
requerimientos (2)
• Verificación – revisiones o pruebas del desarrollador (está bien hecho)
• Validación – revisiones o pruebas del cliente/usuario (cumpla con sus necesidades según se definieron en los
requerimientos)
Objetivos de la definición de
requerimientos
• Entender el problema a resolver
• Construir un modelo de los requerimientos
Tipos de requerimientos
• Funcionales
– Son los servicios, la forma en que el software debe reaccionar a entradas particulares y cómo debe comportarse en situaciones particulares
• No-Funcionales
– Son restricciones que los servicios y funciones de software deben cumplir
Requerimientos No-Funcionales
• Las necesidades de la interfaz externa: hardware y software, comunicaciones, facilidades de uso requeridas por los
usuarios
• Cualidades del software : confiabilidad, eficiencia, seguridad, compatibilidad, portabilidad, mantenimiento
• Restricciones del diseño: formatos, lenguajes, estándares, herramientas
Actividades para definir los
requerimientos
• Obtener – Entender (desarrollador/cliente)
• Analizar (desarrollador)
• Especificar – Documentar texto, diagramas, prototipos (desarrollador)
• Validar (por el cliente)
• Administrar – Cambios a requerimientos (desarrollador)
Casos de prueba
• Para todos los casos de uso se definen casos de prueba
• Los casos de prueba se aplicarán cuando el caso de uso ya esté implementado para asegurar el cumplimiento de los requerimientos especificados
Primer Curso de Ingeniería de Software
Práctica PD1 Requerimientos de software
Objetivo
Comprender y especificar los requerimientos del sistema de software, basándose en el Planteamiento de necesidades.
Entrada Resultado
Condiciones
Productos de trabajo Plan del proyecto
o Diagrama general de casos de uso Planteamiento de Necesidades
Documentación y producto de software de la iteración anterior (excepto la primera iteración)
Condiciones
Productos de trabajo
Especificación de Requerimientos de Software que incluye:
o Enunciado del alcance de problema en la iteración
o Glosario de términos
o Diagrama general de casos de uso de la iteración
o Detalle de los casos de uso
o Prototipo de interfaz de usuario
o Casos de prueba para los casos de uso
o Requerimientos no funcionales
Actividades
1. Entender a detalle el Planteamiento de Necesidades en la parte de funcionalidades dentro del alcance de la iteración y construir el glosario de términos.
2. Analizar y especificar los requerimientos funcionales:
a) Construir el diagrama general de casos de uso de la iteración.
b) Para cada caso de uso dentro del alcance de la iteración, documentar el detalle de flujo normal, alternativo y excepcional . c) Identificar los casos de prueba para cada caso de uso de la iteración en su flujo normal, alterno y excepcional producto de
software
d) Por cada caso de uso de la iteración diseñar el prototipo de interfaz de usuario. 3. Especificar los requerimientos no funcionales.
4. Documentar la Especificación de Requerimientos de Software
Herramientas
Herramienta para hacer diagramas de UML
Técnica R1. Entender el problema
• Hacer entrevistas
• Aplicar cuestionarios
• Observar a los futuros usuarios al realizar las tareas que apoyará el software
• Revisar documentos o sistemas ya existentes que se pretenden mejorar
• Hacer el glosario de términos
Glosario de términos
•
Para que todos los involucrados puedan
comunicarse más fácilmente, se recomienda
construir un
Glosario de términos
para establecer
un
vocabulario común
.
•
El Glosario de términos es un pequeño
diccionario
, donde se registran los términos
importantes para entender el problema y su
significado.
•
El glosario se puede ir
actualizando a lo largo
del
proyecto.
Glosario de términos
Sistema de Bolsa de trabajo
Actor: Es una entidad que interacciona con el sistema para obtener un resultado. Puede ser una persona, otro sistema o un dispositivo, entre otros.
Bolsa de Trabajo: En este caso, es la concentración de información acerca de empresas que tienen puestos disponibles (vacantes) y de personas que tienen la necesidad de conseguir un empleo.
Caso de uso: Es la descripción de un conjunto de secuencias de acciones que un sistema lleva a cabo para regresar un resultado observable a un actor.
Contraseña: Clave de seguridad que se le asigna a un usuario.
Desempleado: Persona que no tiene trabajo y está en busca de un empleo.
Empresa: Organización que tiene la necesidad de contratar a personas con capacidades especificas para su correcto funcionamiento.
Nombre de usuario: Identificación del usuario para poder acceder al sistema.
Técnica R2. Casos de uso
• Documentan requerimientos funcionales en forma gráfica y textual
• Se selecciona el subconjunto del Diagrama General de los casos de uso del proyecto, los que se harán en la iteración.
• Se asigna al menos un caso de uso para cada miembro del equipo que será responsable de él a lo largo de todo el desarrollo.
• Permiten rastrear los requerimientos funcionales a través de todo el proceso de desarrollo hasta el producto terminado
Ver en la Plantilla de Requerimientos
Técnica R3. Detalle de los casos de uso (1)
• Nombre del caso de uso: El nombre deberá ser un verbo en infinitivo representativo de la funcionalidad del caso de uso
• Actor(es): Nombre en singular del actor (o de los actores) encargado de iniciar la acción y es quien recibe el resultado del caso de uso
• Diagrama del caso de uso: indicando el o los actores y el caso de uso en cuestión
• Descripción: Texto breve describiendo la función que representa el caso de uso
Técnica R3. Detalle de los casos de uso (2)
• Flujo normal de eventos : Tabla que describe el flujo de interacciones esperadas (el camino feliz) entre el actor y el sistema durante el caso de uso.
• Flujo alternativo de eventos: Tabla que describe el flujo de interacciones alternativas del camino normal en el caso de uso.
• Flujo excepcional de eventos : Tabla con las acciones que ocurren en situaciones anormales o excepcionales.
• Poscondiciones: Define el estado en el que se encuentra el sistema después de la terminación exitosa del caso de uso.
Ver en la Plantilla de Requerimientos cómo se hace el detalle de casos de uso
Técnica R4: Casos de prueba para los
requerimientos funcionales
• Los casos de prueba para cada caso de uso se documentan en una tabla
• Un caso de prueba identifica las entradas al caso de uso y los
resultados esperados
• Se consideran entradas para flujos normales, alternativos y excepcionales
CASO DE USO: CONSULTAR VACANTE
Caso de Prueba 1. (flujo normal)
Entradas Resultado esperado
Selección de la opción Ver Vacantes, por parte del usuario.
Selección de una vacante y click en el botón Ver por parte del usuario.
Pantalla Todas las Vacantes con la lista desplegada de todas las vacantes guardadas. Pantalla con toda la información de la vacante seleccionada.
Caso de Prueba 2. (flujo excepcional)
Entradas Resultado esperado
La conexión con la base de datos está rota.
Selección de la opción Ver Vacantes, por parte del usuario.
Despliegue del mensaje de error que indica: “Los datos no se pueden mostrar debido a que no hay conexión con la base de datos.”
Técnica R5. Definición del prototipo de interfaz
de usuario
• Un prototipo de interfaz de usuario es una representación
inicial de las pantallas que el software mostrará al usuario
• Estas pantallas muestran la distribución de diferentes elementos que permitirán al usuario interaccionar con el sistema pero que no ofrecen ninguna funcionalidad
Prototipo de interfaz
• Para diseñar las pantallas se puede usar desde papel y lápiz, código HTML, o una herramienta que lo facilite*
• Ver la plantilla para el prototipo de interfaz humana.
Primer Curso de Ingeniería de Software
Técnica R6: Lista de requerimientos no
funcionales (1)
• Interfaz con el usuario: descripción de las características que permitan al software apoyar al usuario en sus tareas
• Interfaz externa: relación o conexión con otros sistemas
• Confiabilidad: disponibilidad, tolerancia a fallas y su recuperación
• Eficiencia: límites de tiempo de respuesta o uso racional de espacios de almacenamiento
• Seguridad: confidencialidad, integridad, sin rechazo, autenticación, información y datos protegidos contra el acceso no autorizado y disponible para los autorizados
Técnica R5: Lista de requerimientos no
funcionales (2)
• Compatibilidad: co-existencia o interoperabilidad con otros sistemas
• Mantenimiento: facilidad de comprensión y realización de modificaciones futuras
• Portabilidad: facilidad de transferencia de un ambiente de ejecución a otro
• Restricciones de diseño y construcción: las que imponga el cliente
Requerimientos no funcionales
Interfaz con usuarios
El sistema debe de ser fácil de usar, además deberá tener una interfaz gráfica agradable y con colores suaves, en tonos de azul.
Confiabilidad
El sistema deberá funcionar las 24 horas del día y los 365 días del año.
Seguridad
El sistema deberá preservar la integridad de los datos de los usuarios.
Para poder dar de alta, modificar o eliminar datos, el usuario debe de proporcionar al sistema un nombre de usuario y una contraseña.
Eficiencia
El tiempo de respuesta para mostrarle los datos al usuario no debe rebasar un segundo.
Restricciones de diseño y construcción
El sistema de software será construido para funcionar en ambiente Web.
El sistema deberá estar codificado en lenguaje de programación Java.
La base de datos del sistema de software deberá estar construida con el manejador de bases de datos MySQL.
Tarjetas de trabajo para
Requerimientos (1)
(Responsable técnico)
Entender el Planteamiento de Necesidades dentro del
alcance de la iteración
Fecha de entrada al tablero:
•Entender las funcionalidades de los
•Hacer el glosario de términos
•Diagrama general de casos de uso para la iteración
Tarjetas de trabajo para
Requerimientos (2)
(Responsable del caso de uso)
Nombre del Caso de Uso
Fecha de entrada al tablero:
•Documentar detalle del caso de uso en sus 3 flujos: normal, excepcional y alternativo
•Documentar casos de prueba para el caso de uso
•Hacer prototipo para el caso de uso
Fecha requerida :
Tarjetas de trabajo para
Requerimientos (3)
(Responsable técnico)
Especificar los requerimientos No funcionales
Fecha de entrada al tablero:•Listar los requerimientos no funcionales para la iteración
Tarjetas de trabajo para
Requerimientos (4)
Integrar todo el documento de Requerimientos
Fecha de entrada al tablero:•Integrar en un solo documento siguiendo la plantilla para Requerimientos:
•Referencia al Enunciado del problema
•Diagrama general de casos de uso restringido a primera iteración
•Glosario de términos,
•Requerimientos No-Funcionales
•Por cada caso de uso
•Detalle de casos de uso,
•Prototipo de interfaz de usuario
•Casos de prueba,
Fecha requerida:
Primer Curso de Ingeniería de Software
