Proceso Unificado Captura de Requisitos

Laboratorio de Software Segundo Semestre 2007
Prof. Angel Augusto Agudelo Z Catedrático UTP

Facultad de Ingenierías Ingeniería de Sistemas y Computación

UNIVERSIDAD TECNOLÓGICA DE PEREIRA

1

Captura de Requisitos

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–2–

Definición
 Según el estándar IEEE-STD-729, un requerimiento se define como:
1. Una condición o capacidad necesitada por un

usuario para resolver un problema o lograr un objetivo. 2. Una condición o capacidad que debe ser alcanzada, o poseída por un sistema o componente del sistema para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto. 3. Una representación documentada de una condición o capacidad como en 1 y 2.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–3–

Clasificación
 Funcionales: corresponden a los resultados que debe arrojar el sistema bajo determinadas circunstancias.  No funcionales: están relacionados con el rendimiento, seguridad, precisión, manejo de errores y capacidades para usuarios específicos. Normalmente las restricciones se traducen en requerimientos no funcionales.  Inversos: indican lo que el software "no debe hacer". Son de mucha importancia en el software de misión crítica.  Restricciones de Diseño e Implementación: corresponden a condiciones impuestas por el usuario para el diseño y la implementación de la aplicación.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–4–

Los Requerimientos deben ser
 Precisos: no deben ser ambiguos.  Consistentes técnicamente: consigo mismo y con otros.  Completos: todo lo necesario debe estar descrito.  Trazables: descritos de tal manera que tengan una única identificación y que se puedan medir.  Comparables: es decir, que se puedan probar.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–5–

Los Requerimientos no pueden
 Ruido: datos que sin aportar nueva información, sólo causan confusión.  Omisión: no describir algo que si debe contemplarse.  Contradicción: el tener dos o más requerimientos en conflicto entre ellos.  Ambigüedad: presencia de texto que se presta para dos o mas interpretaciones.  Que no sea comparable: un requisito que no se puede comprobar, debe reescribirse de forma que tenga una prueba objetiva.
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–6–

Requerimientos de Usuario
 El propósito es :
 refinar una idea sobre la tarea a realizarse con equipo

computacional,  hacia una definición de lo que se espera del sistema.

 Los responsables de esta tarea son los analistas.  Para identificar requisitos hay que entrevistar al cliente/usuario.  Se debe usar la experiencia de los ingenieros y personal clave (cliente/usuario) para ayudar a especificar y revisar los requisitos.  Se entrega el URD, el cual es crítico para el resto del proyecto porque define la base sobre la cual se aceptará el proyecto.  Esta fase termina con la aprobación formal del URD por la actividad de revisión UR/R.  El URD representa la visión del usuario acerca del problema a resolver.
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación Página –7–

Capturar Requerimientos de Usuario
 Proceso iterativo.  Se realizan entrevistas con el usuario.  Se usan cuestionarios.  Se revisan todos los formularios y sistemas involucrados.  Se establecen acuerdos con respecto a los límites del sistema.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–8–

Determinar el Ambiente Operacional
 Primer paso para definir los requisitos del software.  Debe establecerse el escenario en el que operara el software a desarrollar.  Es una narrativa que puede apoyarse de diagramas de contexto o de bloques, que permita mostrar el uso del sistema en un ambiente más grande.  Cosas a revisar en la definición del escenario:
 tipos de máquinas (hardware y software),  tipos de comunicaciones a usar (teléfono, LAN,

WAN),  interfaces con otros sistemas (en producción o en Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA desarrollo).
Ingeniería de Sistemas y Computación Página

–9–

Plantilla para Especificaciones OO
1. Introducción
1.1 1.2 1.3 1.4 1.5 Propósito Alcance del Proyecto Glosario: Definiciones, Acrónimos y Abreviaciones Referencias Contenido Contexto del Producto Funciones del Producto Características de los Usuarios Restricciones Dependencias y Supuestos Interfaces Interfaces Interfaces Interfaces de de de de Usuario Hardware Software Comunicación

2.

Descripción General
2.1 2.2 2.3 2.4 2.5

3.

Requerimientos de Interfaces Externas
3.1 3.2 3.3 3.4

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–10–

Plantilla para Especificaciones OO
1. Requerimientos Funcionales 4.1 Casos de Uso 4.1.1 Caso de Uso 1 4.1.2 Caso de Uso 2 ... 4.2 Reportes 4.2.1 Reporte 1 4.2.2 Reporte 2 4.3 Diagramas de Secuencia 4.3.1 Diagrama de Secuencia 1 4.3.2 Diagrama de Secuencia 2 ... 4.4 Modelo Conceptual 4.4.1 Descripción 4.4.2 Clase/Objeto1 4.4.3 Clase/Objeto2 ... Requerimientos de Rendimiento Restricciones de Diseño
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

2. 3.

Página

–11–

Plantilla para Especificaciones OO
1. 2. 3. Atributos del Sistema Requerimientos Adicionales Anexos  Modelo Conceptual  Diagramas Casos de Uso  Diagramas de Secuencia  Diagramas de Clase  Modelo de Datos Lógico  Diccionario de Datos  Pantallas del Prototipo  Descripción de Archivos

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–12–

Diagramas de Casos de Uso
 Descripción de un conjunto de secuencias de acciones que ejecuta un sistema produciendo un resultado de interés para un actor.  Describen el comportamiento para cada actor  Instancia de caso de uso  Se lleva a cabo mediante colaboraciones de objetos  Colaboración:
 Define las interacciones que han de producirse entre

los objetos con el fin de que estos puedan desempeñar su papel.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–13–

Diagramas de Casos de Uso
 Elementos estructurales:

 Relaciones:
 Dependencia: relación semántica donde un cambio

en el elemento independiente puede afectar a la semántica del elemento dependiente. Elemento dependiente  Elemento independiente

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–14–

Diagramas de Casos de Uso
 Relaciones
 Asociación: enlace que representa conexión entre

objetos

 Realización: relación semántica entre clasificadores,

en la cual un clasificador especifica un contrato que otro clasificador se compromete a llevar a cabo.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–15–

Captura de Requisitos
TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTO (artifact) Lista de características Modelo de negocios o de dominio Modelo de casos de uso Prototipo IU Requisitos suplementarios o casos individuales

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–16–

Captura de Requisitos
TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTO (artifact) Lista de características Modelo de negocios o de dominio Modelo de casos de uso Prototipo IU Requisitos suplementarios o casos individuales

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–17–

Captura de Requisitos
 Modelo del Dominio
 ¿Qué es?  Tipos de objetos (especificación o entrevistas)  “Cosas” y eventos
 Diagramas de clases y glosario

 Desarrollar el modelo del dominio  Técnicas de comunicación  Solo contexto  Usar el modelo del dominio  Al describir los casos de uso
 Conceptos sugieren clases de análisis y diseño

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–18–

Captura de Requisitos
 Modelo de negocio
 ¿Qué es?  Procesos de negocio  Cómo se realiza un proceso por un conjunto de

trabajadores que usan unas entidades y unidades de trabajo
 Desarrollar el modelo de negocio  Identificar casos de negocio y sus actores  Desarrollar modelo de objetos de negocio con:

trabajadores, entidades de negocio y unidades de trabajo
 Usar el modelo de negocio  Un actor por trabajador
 Identificar sus papeles en distintos casos
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–19–

Captura de Requisitos
TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTO (artifact) Lista de características Modelo de negocios o de dominio Modelo de casos de uso Prototipo IU Requisitos suplementarios o casos individuales

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–20–

Captura de Requisitos Funcionales
 Basado en casos de uso  CU para el actor: forma de utilizar el sistema  Objetivos:
 Capturar el comportamiento, sin especificar  Comprensión común  Validar arquitectura y sistema

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–21–

Captura de Requisitos Funcionales
1. 2. 3. 4. 5. Identificar actores y casos de uso Priorizar casos de uso Detallar casos de uso Prototipo de IU Estructurar el modelo

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–22–

Captura de Requisitos Funcionales
1. Identificar actores y casos de uso
 Para:  Delimitar el sistema  Actores y funcionalidad
 Glosario

 Pasos:  Descubrir los actores  Descubrir los casos de uso  Describir brevemente cada caso de uso  Describir el modelo de casos de uso

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–23–

Ejemplo: Cajero Automático
 Lista de Requisitos Candidatos
 FUNCIONES BÁSICAS
1. El usuario podrá consultar el saldo de su cuenta 2. Si el usuario intenta sacar una cantidad que supera el saldo

de su cuenta, el cajero le avisará de que no es posible sacar esa cantidad 3. Si el usuario intenta sacar una cantidad que supera el límite diario, el cajero le avisará de que no es posible y volverá a solicitar una cantidad 4. El cliente del banco podrá hacer una transferencia a otra cuenta ...
 REQUISITOS NO FUNCIONALES
1. Fácil de usar 2. Tiempo de respuesta inferior a 30 seg.

...
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–24–

Ejemplo: Cajero Automático
 Casos de Uso. Descripción Inicial
Caso de Uso: Actores: Tipo: Descripción: Sacar dinero Cliente (iniciador) ?? El caso de uso comienza con la identificación del usuario. El cliente usa el caso de uso para acceder a su cuenta. El caso de uso le devuelve el dinero solicitado, un aviso de que no tiene saldo o de que ha excedido el límite diario. Consultar saldo Cliente ?? El caso de uso comienza con la identificación del usuario. El usuario consulta el saldo de su cuenta.

Caso de Uso: Actores: Tipo: Descripción:

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–25–

Captura de Requisitos Funcionales
1. Priorizar los casos de uso
 Visión de la arquitectura  Casos de uso a desarrollar en las primeras

iteraciones  Casos de uso significativos

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–26–

Captura de Requisitos Funcionales
1. Detallar casos de uso
 Objetivo: flujo de sucesos (o eventos):  Cómo comienza y termina el caso de uso
 Cómo interactúa con los actores  Objetos que se intercambian

 Veremos:  Cómo estructurar la descripción de un CU  Qué incluir en una descripción de un CU
 Cómo formalizar la descripción del CU

 Antes...

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–27–

Diagramas de Estado
 Un diagrama de estados representa un elemento como una máquina de estados finita  Un diagrama de estado, representa la vida de un único elemento  Consta de: Estados, Transiciones, Eventos y Actividades  Permite visualizar el comportamiento (dinámico) de un elemento

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–28–

Diagramas de Estados
 Elementos
 Estado: situación en la vida de un elemento durante

la cual se satisface alguna condición, se realiza alguna actividad o se espera algún suceso
 Inicial, Intermedio, Final

 Transición: relación entre dos estados que indica

que un elemento que esté en un primer estado realizará ciertas acciones y entrará en el segundo estado cuando se produzca un suceso especificado y se satisfacen las condiciones indicadas  Suceso o evento: especificación de algún acontecimiento que ocupa espacio y tiempo. Es la aparición de un estímulo que puede disparar la transición de un estado a otro
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–29–

Diagramas de Estado

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–30–

Diagramas de Estado
 Actividad: ejecución no atómica en curso, dentro de una máquina de estados. Lo que se hace en el estado
 do: operación que toma un tiempo en el estado.

Puede interrumpirse por un suceso, externo o interno, o terminar en transición automática

 Acción: computación atómica ejecutable que produce un cambio de estado del modelo o devuelve algún valor (deben ser operaciones de la clase)
 entry: instantáneamente a la entrada del estado  exit: instantáneamente a la salida del estado  eventos
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación Página –31–

Diagramas de Estado
 La acción se considera instantánea  Ejemplos:

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–32–

Capturar Requisitos Funcionales
1. Detallar casos de uso (cont.)
 Cómo estructurar un CU  Camino básico: “normal”
 Alternativas:  El actor puede elegir diferentes caminos  Si está implicado más de un actor, las acciones de uno pueden influir el camino de otro  El sistema detecta entradas erróneas  Algunos recursos funcionan mal  Gráficamente: diagrama de transición de estados

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–33–

Capturar Requisitos Funcionales
1. Detallar casos de uso (cont.)
 Qué incluir (descripción textual)
          

Estado inicial como precondición (condiciones previas) Cómo y cuándo comienza el caso de uso Orden de acciones (flujo de sucesos) Cómo y cuándo termina el caso de uso Estados finales como postcondiciones (cond. posteriores) Caminos no permitidos Descripción caminos alternativos (incluida o no con el c. básico) Interacción del sistema con los actores y cambios que producen Uso de objetos, valores y recursos del sistema Qué hace el sistema. Separar responsabilidades. “el sistema...” Requisitos especiales

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

 Validar los casos de uso

Página

–34–

Capturar Requisitos Funcionales
1. Detallar casos de uso (cont.)
 Para casos de uso sencillos es suficiente texto  Casos de uso complejos: necesitan estructuración y

técnicas visuales  Formalismos: diagramas de
 transición de estados  actividad  interacción

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–35–

Diagramas de Estado
 Diagrama de estados para un caso de uso: modificar datos alumno

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–36–

Caso de Uso “Sacar dinero”
 Flujo de Eventos
ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando un cliente introduce una tarjeta en el cajero Introduce la clave RESPUESTA DEL SISTEMA 1. Pide la clave de identificación

1.

1. 1.

Comprueba la clave Presenta las opciones de operaciones disponibles Pide la cantidad a retirar Produce la petición y da el dinero solicitado Genera un recibo

1. 1.

Selecciona la opción de reintegro Introduce la cantidad requerida Recoge el dinero Recoge el recibo y termina el caso de uso

1. 1. 2.

1. 2.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–37–

Caso de Uso “Sacar dinero”
 Flujo de Eventos
ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando un cliente introduce una tarjeta en el cajero Introduce la clave RESPUESTA DEL SISTEMA 1. Pide la clave de identificación

1.

1. 1.

Comprueba la clave Presenta las opciones de operaciones disponibles Pide la cantidad a retirar Produce la petición y da el dinero solicitado Genera un recibo

1. 1.

Selecciona la opción de reintegro Introduce la cantidad requerida Recoge el dinero Recoge el recibo y termina el caso de uso

1. 1. 2.

1. 2.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–38–

Caso de Uso “Validar usuario”
 Flujo de Eventos
ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando un cliente introduce una tarjeta en el cajero Introduce la clave RESPUESTA DEL SISTEMA 1. Pide la clave de identificación

1.

1. 1.

Comprueba la clave Presenta las opciones de operaciones disponibles

CAMINOS ALTERNATIVOS Evento 3. El cliente cancela la transacción Evento 4. La clave no es válida y se reinicia el caso de uso. Si ocurre tres veces se cancela la transacción y se bloquea la tarjeta ¡¡HAY QUE DEFINIR ESTOS DOS FLUJOS DE EVENTOS!!
Página –39–

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Caso de Uso “Sacar dinero”
 Flujo de Eventos
ACCIÓN DEL ACTOR 1. Este caso de uso empieza cuando se han presentado las opciones de operaciones disponibles. Selecciona la opción de reintegro Introduce la cantidad requerida Recoge el dinero Recoge el recibo y termina el CU RESPUESTA DEL SISTEMA 1. Pide la cantidad a retirar

1.

1. 2.

Procesa la petición y da el dinero solicitado. Genera un recibo.

1. 2.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–40–

Caso de Uso “Sacar dinero”
 Flujo de Eventos
 CAMINOS ALTERNATIVOS
 Evento 4: La cantidad solicitada supera el saldo. Se indica el

error y se cancela la operación.  Evento 4: La cantidad solicitada supera el límite diario. Se indica el error y se vuelve a pedir otra cantidad.  Evento 4: En el cajero no hay dinero.

¡¡HAY QUE DEFINIR ESTOS TRES FLUJOS DE EVENTOS!!
 Podríamos definir diagramas de estados  Requisito no funcional asociado al caso de uso Sacar

dinero: El tiempo de respuesta para un cliente debe ser <30 sg en el 90% de los casos
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–41–

Caso de Uso “Validar usuario”
 Flujo de Eventos

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–42–

Capturar Requisitos Funcionales
1. Prototipo de IU
 A partir de las descripciones de los casos de uso.  Pasos:  Diseño lógico: qué necesita cada actor de la interfaz

para que se pueda ejecutar el caso de uso  Descripción y construcción del prototipo ejecutable pero acciones nulas (validación y depuración)

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–43–

Capturar Requisitos Funcionales
1. Estructurar el modelo de casos de uso
 Identificar funcionalidad compartida  Generalizaciones  Identificar funcionalidad adicional y opcional  extend  Identificar otras relaciones  include

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–44–

Diagramas de Casos de Uso
 Relaciones

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–45–

Diagramas de Casos de Uso
 Relaciones

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–46–

Ejemplo: Cajero Automático

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–47–

Ejemplo: Cajero Automático

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–48–

Captura de Requisitos
TAREA Enumerar requisitos candidatos Entender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales PRODUCTO (artifact) Lista de características Modelo de negocios o de dominio Modelo de casos de uso Prototipo IU Requisitos suplementarios o casos individuales

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–49–

Curso Virtual
 Un sistema que ofrece cursos virtuales permite que tanto profesores como alumnos accedan al sistema. Existen una serie de operaciones comunes que ambos pueden realizar como son asistir al foro y comunicarse a través del chat. En cualquier caso, tanto profesores como alumnos deberán loguearse en el sistema antes de poder acceder al curso.  Obligatoriamente, un alumno deberá haberse matriculado en el sistema para poder acceder a él. Así además los profesores podrán consultar los alumnos matriculados en cualquiera de los cursos. Los alumnos podrán modificar sus datos.  Los profesores podrán colgar el material docente del curso a través de la aplicación. Los alumnos de este modo, podrán acceder a consultar las lecciones. Además asociado a cada lección podrán consultar la bibliografía asociada, descargarse los apuntes y realizar los tests asociados al temario. También podrán, opcionalmente, recomendar dichas lecciones a otros alumnos matriculados. Angel Augusto Agudelo Z
UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación Página –50–

Ejemplo: Curso Virtual

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–51–

Ejemplo: Punto de Venta
 Lista de requisitos candidatos
 FUNCIONES BÁSICAS
 R1.1. Grabar la venta actual (productos comprados por el        

cliente) R1.2. Calcular el total de la venta actual incluidos los impuestos R1.3. Capturar información del producto usando el código de barras o tecleando el código del producto. R1.4. Reducir la cantidad en inventario cuando se realice la venta R1.5. Registrar ventas realizadas R1.6. El dependiente debe iniciar una sesión con identificador y clave para usar el sistema R1.7. Dar un mecanismo de almacenamiento R1.8. Dar mecanismos de comunicación con otros procesos y sistemas R1.9. Mostrar descripción y precio del producto almacenado
Página –52–

 NO FUNCIONAL 5 Angel Augusto Agudelo Z seg, color UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Ejemplo: Punto de Venta
 Lista de requisitos candidatos
 FUNCIONES DE PAGO
 R2.1. Manejar pagos en metálico, tomar cantidad ofrecida y

calcular el cambio  R2.2. Manejar pagos con tarjeta, capturar información de la tarjeta con un lector o manualmente y autorizar el pago vía modem.
 OTRAS FUNCIONES
 R3.1. Es necesario dar de alta dependientes nuevos en el

puesto de venta y dar de baja aquellos que dejan el puesto de venta.  R3.2. El puesto de venta es encendido y apagado cada día por el encargado de la sección, que comprueba que el puesto funciona correctamente y comprueba la fecha y la hora
 REQUISITOS NO FUNCIONALES
 Fácil de usar, Tiempo de respuesta corto, Plataforma, Precio al

público  Interfaz (gráfica, con colores, ventanas, facilitar navegación por teclado,…)
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación Página

–53–

Ejemplo: Punto de Venta

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–54–

Caso de Uso “Acceder al sistema”
ACCIÓN DEL ACTOR  El actor rellena los campos del DNI y clave (la clase se la dió la Universidad) en una pantalla que le ha presentado el sistema y pulsa el botón de enviar RESPUESTA DEL SISTEMA 1. El sistema comprueba que el formato de ambos campos es el adecuado; es decir, que el DNI es un string de 8 dígitos y que la clave es una secuencia de 4 dígitos El sistema verifica que la clave tecleada se corresponde con el DNI tecleado; es decir, que la clave es la correcta para ese DNI. El sistema verifica que la fecha actual es la que le corresponde al actor para matricularse. El sistema comprueba que el actor no adeuda ningún importe a la Universidad

1.

1.

1.

Caminos alternativos: Evento 1: el actor cancela la operación Evento 2: existe error en el formato del DNI y/o de la clave Evento 3: existe error en la clave Evento 4: la fecha actual no es la asignada al actor para matricularse Evento 5: el actor es moroso
Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación Página –55–

Caso de Uso “Acceder al sistema”

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–56–

CheckList
 Contenido de los Requerimientos
¿Se ha especificado el objetivo del Sistema? ¿Se han especificado todas las entradas del sistema incluyendo su fuente, precisión, rango de valores y frecuencia? 3. ¿Se han especificado todas las salidas del sistema incluyendo su destino, precisión, rango de valores y frecuencia y formato? 4. ¿Se ha construido el modelo lógico de datos? 5. ¿Se han identificado los dominios del modelo de datos? ¿Se han identificado los parámetros del sistema? 6. ¿Se ha construido el mapa de navegación? ¿Se ha descrito cada página del mapa de navegación? 7. ¿Se han especificado todos los reportes del sistema? 8. ¿Se ha definido el tipo de administración que requiere el sistema? 9. ¿Se han especificado todas las interfaces externas de hardware y software? 10. ¿Se ha especificado el tiempo de respuesta, desde el punto de vista del usuario, para todas las operaciones que lo requieren? 11. ¿Se ha especificado toda la funcionalidad que debe satisfacer el sistema?
1. 2.

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–57–

CheckList
 Contenido de los Requerimientos
1. 2. 3. 4.

5. 6.

¿Se ha especificado para cada proceso los datos utilizados y los datos entregados por el proceso? ¿Se han identificado los usuarios del sistema? ¿Los usuarios finales? ¿Se han definido los roles del sistema? ¿Se ha especificado el nivel de seguridad del sistema? ¿Se ha especificado la confiabilidad incluyendo las secuencias de una caída del software, información vital protegida, detención de errores y recuperación? ¿Se ha incluido la definición de éxito y fracaso para los procesos del sistema? ¿Se ha especificado la mantenibilidad del sistema, incluyendo la capacidad de responder a cambios en el ambiente de operación, interfaces con otros sistemas, precisión, rendimiento y otras capacidades predecibles?

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–58–

CheckList
 Completitud de los Requerimientos
1. ¿En donde la información no está disponible antes

del desarrollo, se han especificado las áreas de deficiencia? 2. ¿Están los requerimientos completos en el sentido de que si el sistema satisface los requerimientos, éste será aceptable? 3. ¿Hay disconformidad acerca de algún requerimiento? ¿Hay partes imposibles de implementar o incluidas sólo para satisfacer al cliente?

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–59–

CheckList
 Calidad de los Requerimientos
1. 2. 3. 4. 5. 6.

7.

8.

9.

¿Están los requerimientos descritos en lenguaje del usuario? ¿Los cree así el usuario? ¿Se han validado los requerimientos con el usuario? ¿Con los demás integrantes del equipo de trabajo? ¿Se han validado los prototipos con el usuario final? ¿Evitan los requerimientos conflictos entre sí? ¿Los requerimientos incorporan aspectos de diseño? ¿Están los requerimientos a un nivel de consistencia adecuado? ¿Debería especificarse en más detalle algún requerimiento? ¿Debería especificarse en menos detalle algún requerimiento? ¿Son los requerimientos lo suficientemente claros como para ser entregados a un grupo independiente para su codificación y aún ser comprendidos? ¿Es cada requerimiento relevante para el problema y su solución? ¿Puede rastrearse el origen de cada requerimiento en el ambiente del problema? ¿Se puede probar cada requerimiento? ¿Será posible para un grupo independiente de pruebas determinar si un determinado requerimiento ha sido satisfecho?

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–60–

CheckList
 Especificación de los Requerimientos
1. ¿Es la especificación modular? ¿Es posible

incorporar / modificar / eliminar información sin producir grandes transformaciones en la estructura? 2. ¿Existen referencias cruzadas en la especificación? 3. ¿Se ha revisado la ortografía y redacción del documento? 4. ¿Existe una tabla de contenidos, figuras y/o tablas?

Angel Augusto Agudelo Z UNIVERSIDAD TECNOLÓGICA DE PEREIRA Ingeniería de Sistemas y Computación

Página

–61–

Sign up to vote on this title
UsefulNot useful