Requerimientos
-
Upload
christian-miranda -
Category
Documents
-
view
135 -
download
2
Transcript of Requerimientos
Ingeniería de Software.
Obtención de Requerimientos y
Ingeniería de Software. Obtención de los Requerimientos Página 0
Elaboración del Documento SRS.
Mapa del Proceso.
Ingeniería de Software. Obtención de los Requerimientos Página 1
Planeación de la Obtención de Requerimientos.
Es necesario:
• Identificar todas las fuentes necesarias de
requerimientos.
Ingeniería de Software. Obtención de los Requerimientos Página 2
requerimientos.
• Identificar todos los involucrados que hay que
entrevistar.
Identificación de las Fuentes de Requerimientos.
Los requerimientos de un sistema pueden provenir de
muchas fuentes. Las más importantes:
• Entrevistas con los involucrados.
• Observación de los usuarios en su trabajo.
Ingeniería de Software. Obtención de los Requerimientos Página 3
• Observación de los usuarios en su trabajo.
• Análisis de documentos de políticas y procedimientos.
• Análisis del sistema existente.
• Análisis y documentación de entradas y salidas.
Identificación de los Involucrados.
La lista inicial de los involucrados (stakeholders) proviene
del dueño del proyecto. Sin embargo, la lista se expande
cuando se empieza a entrevistar a algunos involucrados.
Los involucrados pueden ser:
Ingeniería de Software. Obtención de los Requerimientos Página 4
• Usuarios del Sistema.
• Operadores y administradores del sistema.
• Administradores de la red.
• Gerentes de los usuarios y operadores.
• Expertos en el campo ("domain experts").
• Gerentes de mercadotecnia de los productos de la empresa.
Lista de Involucrados.
Crear una lista de involucrados por rol, por ejemplo:
Rol Involucrado Primario Involucrados Secundarios
Dueño Mary Jane Parker Peter Parker
Gerente Frodric Bagend Samuel Gamgee (Santa Cruz)
Ingeniería de Software. Obtención de los Requerimientos Página 5
Gerente Frodric Bagend
(Sierra Madre)
Samuel Gamgee (Santa Cruz)
Luz Hammarstrom (Sonoma)
Recepcionista y
agente de
reservaciones.
Medoca Sansumi
(Santa Cruz)
David Hammarstrom (Sonoma)
Judith Brown (Sierra Madre)
Coordinador de
Eventos
Harold Harkening
Clientes Peter Parker
(representante)
Mary Jane Parker
(representante)
Preparación de las Entrevistas con los Involucrados.
Hacer una lista inicial de preguntas de Requerimientos
Funcionales que:
• Verifique la visión del dueño del proyecto para los casos de uso de
cada involucrado.
Ingeniería de Software. Obtención de los Requerimientos Página 6
cada involucrado.
• Descubra el siguiente nivel de detalle.
• Proporcione escenarios de los casos de uso.
• Determine, para cada involucrado, que preguntas, relativas a
requerimientos no funcionales, plantear.
Preguntas Detalladas para los FRs.
Para cada rol, hacer este tipo de preguntas:
• ¿El caso de uso "xyz" es necesario en su trabajo?
• Explique los pasos que hace para realizar "xyz".
• ¿Qué información se usa en cada paso?
Ingeniería de Software. Obtención de los Requerimientos Página 7
• ¿Qué información se usa en cada paso?
• ¿Qué información es obligatoria y cuál es opcional?
• Si actualmente usa software para soportar "xyz", ¿puede
proporcionarnos imágenes de las pantallas?
• ¿Puede darnos uno o algunos escenarios concretos de "xyz"?
Preguntas Detalladas para los FRs (2).
• Lo que hace para “xyz”, ¿incluye generación de reportes?
• ¿Su trabajo requiere interactuar con otros sistemas externos para el
caso de uso "xyz"?
• ¿Su trabajo usa información externa para hacer el caso de uso
"xyz"?
Ingeniería de Software. Obtención de los Requerimientos Página 8
Tomar notas adicionales acerca de:
• Diferencias en terminología entre los actores.
• Diferencias en las explicaciones del propósito y flujo de los casos
de uso entre actores.
Consideraciones de la Obtención de Requerimientos.
Los modelos mentales de los involucrados son inexactos
muchas veces. Hay tres problemas fundamentales:
• Desaparición – Información que se pierde.
Ingeniería de Software. Obtención de los Requerimientos Página 9
• Distorsión – Información que se modifica por creación
o cambio.
• Generalización – Se crean nuevas reglas.
Desaparición de Información.
Información que se pierde. Ejemplo:
• Agente de Reservaciones: "Cuando hago una reservación, registro
el tipo de cuarto que se reserva".
• Problema: El agente no dijo que se pueden reservar varios cuartos.
Ingeniería de Software. Obtención de los Requerimientos Página 10
• Problema: El agente no dijo que se pueden reservar varios cuartos.
• Solución: Pedir clarificación.
• ACME: "¿es posible reservar más de un cuarto?"
• Agente: "Ah sí, se me olvidaba, no es muy frecuente pero sí sucede.
Hace unos meses una pareja que se casó en el hotel, reservó
cuatro cuartos para familares."
Distorsión.
Información que se modifica por creación o cambio.
Ejemplo:
• Agente: "Se puede mantener una reservación sin confirmar con
tarjeta de crédito, pero se cancela si el cliente no confirma en dos
Ingeniería de Software. Obtención de los Requerimientos Página 11
tarjeta de crédito, pero se cancela si el cliente no confirma en dos
semanas".
• Problema: El agente da al analista información incorrecta acerca de
la política de cancelación.
• Solución: preguntar a otros involucrados por validación y
clarificación.
Generalización.
Se crean reglas generales inapropiadamente. Se presentan cuando se
usan cuantificadores universales como siempre, nunca, todos nadie,
etc. Ejemplo:
• Recepcionista: "Yo siempre escaneo la tarjeta de crédito del cliente cuando hacen el check-in".
• Problema: La recepcionista está implicando que siempre hay que escanear
Ingeniería de Software. Obtención de los Requerimientos Página 12
• Problema: La recepcionista está implicando que siempre hay que escanear la tarjeta de crédito del cliente, es decir que es parte del procedimiento establecido de check-in.
• Solución: Clarificar.
• ACME: "¿no hay algunos casos en que no se necesita escanear la tarjeta de crédito?"
• Recepcionista: "Ah sí, se me olvidaba, cuando son clientes conocidos o si su reservación fue hecha directamente por su compañía, no escaneamos la tarjeta."
Preguntas Detalladas para NFRs.
Las cuestiones de NFRs tienden a ser ambiguas. Es difícil
encontrar la persona adecuada para contestarlas. Algunos
puntos de partida:
Ingeniería de Software. Obtención de los Requerimientos Página 13
• Averiguar que cualidades del sistema son importantes.
• Averiguar a quien preguntar acerca de estas cualidades.
• Encontrar las palabras (o frases) clave que hay que escuchar para
determinar los NFRs para determinada cualidad del sistema.
Cualidades del Sistema.
Los NFRs determinan las cualidades del sistema de software, es
decir, que tan bien se comporta el sistema en las interacciones
actor-sistema.
Generales Operacionales De desarrollo De evolución
Rendimiento "Throughput" Realizabilidad Escalabilidad
Ingeniería de Software. Obtención de los Requerimientos Página 14
Disponibilidad Manejabilidad Planeabilidad Mantenibilidad
Usabilidad Fácil de
modificar
Flexibilidad
Fácil de probar Reusabilidad
Confiabilidad Portablilidad
Seguridad
Rendimiento.
Frecuentemente aparecen cuestiones de rendimiento en
las entrevistas de requerimientos. Consideraciones:
• A veces, los usuarios hablan de que tan rápido deben ocurrir
algunas operaciones.
Ingeniería de Software. Obtención de los Requerimientos Página 15
algunas operaciones.
• Los gerentes de los usuarios suelen tener expectativas predefinidas
acerca de la velocidad de operaciones individuales y del tiempo
total necesario para concluir un caso de uso.
• Los administradores del sistema a menudo saben el "throughput"
del sistema y la capacidad de los recursos del sistema (número de
usuarios, tamaños de archivos, número de registros en las bases de
datos, número de transacciones, etc.)
Rendimiento (2).
Los usuarios hacen comentarios relacionados con el
rendimiento, por ejemplo:
• "Cuando hago click en este botón, el sistema actual se tarda mucho en contestar. Yo necesito que conteste en menos de 5 segundos".
• "Este reporte se tarda mucho en imprimir, pero no importa porque lo mando a imprimir en la noche".
Ingeniería de Software. Obtención de los Requerimientos Página 16
mando a imprimir en la noche".
Se pueden hacer preguntas relacionadas con el
rendimiento como:
• ¿Qué tan rápida tiene que ser esta operación?
• En las horas pico y no pico, ¿cuántas transacciones ocurren en la base de datos?
• ¿Cuántos usuarios tendrá el sistema?
Escalabilidad.
• Está relacionada con el rendimiento, se define como la
habilidad de incrementar el "throughput" en el tiempo.
• Por ejemplo, una aplicación Web podría soportar 20
usuarios simultáneos este año, pero se incrementará a
100 en 5 años.
Ingeniería de Software. Obtención de los Requerimientos Página 17
Escalabilidad (2).
• Determinar la escabilidad del sistema es muy aproximado, depende
fuertemente del crecimiento esperado del negocio.
• Los dueños del proyecto y los gerentes suelen tener la mejor
perspectiva en estos asuntos.
Ingeniería de Software. Obtención de los Requerimientos Página 18
• Sin embargo, los administradores del sistema y de la red, muchas
veces tienen estadísticas de tendencias en las siguientes áreas:
– Carga del sistema en horas normales y en horas pico.
– Utilización de la red en horas normales y en horas pico.
– Crecimiento promedio de las tablas de la base de datos.
– Actualizaciones de hardware planeada
Usabilidad.
Esta cualidad del sistema es difícil de cuantificar, pero el
objetivo es determinar que tan fácil de utilizar es el
sistema.
Ingeniería de Software. Obtención de los Requerimientos Página 19
• Lo primero que hay que hacer es analizar las capacidades de los
actores.
• Este análisis se puede hacer observando al actor durante las
entrevistas y también durante su trabajo.
• También se puede preguntar a sus gerentes.
• Con esta información, se pueden determinar las características de
usabilidad del sistema, basándose en las capacidades del actor.
Consideraciones de Usabilidad.
• Consistencia del sistema propuesto con sistemas similares existentes.
• "Look and Feel": posicionamiento de los botones, espaciado, tamaño y tipo de ventanas, etc.
Ingeniería de Software. Obtención de los Requerimientos Página 20
espaciado, tamaño y tipo de ventanas, etc.
• Convenciones locales e internacionalización.
• Facilidades de navegación y flujo de pantallas.
• Accesabilidad.
Seguridad.
• La mayoría de las aplicaciones actuales requieren un
control estricto del acceso al sistema.
• Los roles de los actores generalmente definen los roles
de seguridad iniciales.
• Sin embargo, considerar lo siguiente:
Ingeniería de Software. Obtención de los Requerimientos Página 21
• Sin embargo, considerar lo siguiente:
– ¿Dónde y cómo se guardará la información de usuarios y
passwords?
– ¿Qué amenzas internas y externas puede haber?
– Si es una aplicación distribuida, ¿qué datos críticos (passwords,
números de tarjetas de crédito) viajarán a través de la red.
Información de los Actores.
Obtenga la siguiente información para cada actor en el
sistema:
• Rol dentro de la empresa.
• Descripción del puesto.
• Uso primario del sistema.
Ingeniería de Software. Obtención de los Requerimientos Página 22
• Uso primario del sistema.
• Tiempo de uso promedio del sistema cada vez.
• Frecuencia de uso del sistema.
• Educación.
• Conocimiento de la industria.
• Experiencia en computadoras, hardware y software.
• Entrenamiento esperado.
• Compromiso.
Creación del Documento SRS.
• El documento de Especficaciones de Requerimientos
del Sistema SRS registra el conjunto de todos los
requerimientos de un sistema de software.
• Contiene típicamente 6 secciones:
– Introducción.
Ingeniería de Software. Obtención de los Requerimientos Página 23
– Introducción.
– Restricciones y suposiciones.
– Riesgos.
– Requerimientos funcionales.
– Requerimientos no-funcionales.
– Glosario del proyecto.
• El SRS debe ser detallado, sin perder claridad o foco.
Introducción del SRS.
La introducción del documento SRS debe incluir:
• Propósito.
• Alcance
• Contexto del Sistema.
Ingeniería de Software. Obtención de los Requerimientos Página 24
• Contexto del Sistema.
• Involucrados (Stakeholders).
• Acrónimos y abreviaturas.
• Organización del documento.
• Referencias.
Sección de FRs del SRS.
La sección de requerimientos funcionales del SRS incluye
las siguientes subsecciones.
• Características principales del Sistema.
• Descripción de los Actores.
Ingeniería de Software. Obtención de los Requerimientos Página 25
• Descripción de los Actores.
• Casos de Uso.
• Aplicaciones.
• Requerimientos funcionales (detallados) para cada caso
de uso.
Descripción de los Actores.
Proporcionar un sumario de las funciones de los actores.
Por ejemplo:
Esta persona maneja las reservaciones vía telefónica de los
clientes. Por lo tanto, generalmente representa el primer
Ingeniería de Software. Obtención de los Requerimientos Página 26
clientes. Por lo tanto, generalmente representa el primer
contacto del cliente con Bay View Property Management. Es
empleado permanente de la compañía. Se requiere que tenga
secundaria terminada, que tenga habilidades para usar el
teclado y conocimientos básicos de Windows. Se le
proporcionará entrenamiento en el sistema internamente.
Descripción de los Actores (2).
Este rol trabaja en dos turnos de ocho horas (6 a.m a 2 p.m. y 2 p.m. a
10 p.m.) durante los cuales utiliza el sistema continuamente. Hay una
alta rotación en este puesto (en promedio, cada empleado renuncia
cada 6 meses). No se sospecha que este actor pudiera usar
indebidamente el sistema, pero sí podrían ocurrir problemas por falta
de preparación y experiencia. Por lo anterior hay que poner atención
Ingeniería de Software. Obtención de los Requerimientos Página 27
de preparación y experiencia. Por lo anterior hay que poner atención
extra en el flujo de la GUI para estos actores.
Sección de Casos de Uso.
Esta sección del documento SRS consiste de una tabla de todos los
casos de uso, con prioridad, número asignado y descripción breve.
Por ejemplo:
Caso de Uso Prioridad Num Descripción
Manejar
reservación
Esencial 1 Permite al agente de reservaciones crear,
consultar, actualizar y borrar
reservaciones de clientes.
Ingeniería de Software. Obtención de los Requerimientos Página 28
reservaciones de clientes.
Check-in Esencial 2 Permite al recepcionista hacer el check-in
de los clientes.
Crear
promociones
Alta 7 Permite al gerente crear promociones y
descuentos.
Manejar
eventos.
Alta 8 Permite al coordinador de eventos crear,
consultar, actualizar y borrar eventos y
conferencias.
Enviar
encuestas
Baja 12 Permite enviar encuestas de clientes.
Sección de Aplicaciones.
Esta sección del documento SRS consiste de una tabla de las
aplicaciones o subsistemas que conforman el Sistema.
Por ejemplo:
Subsistema Descripción / Casos de Uso
HotelApp Este subsistema automatiza las funciones de manejo del
hotel y de los eventos.
Ingeniería de Software. Obtención de los Requerimientos Página 29
hotel y de los eventos.
Soporta FRs: E1, E2, E3, E6, A7, A8, B9, B10
WebPresenceApp Este sitio Web permite al cliente ver las facilidades de
los hoteles y hacer reservaciones.
Soporta FRs: E4, E5.
KioskApp Esta aplicación stand-alone reside en un kiosko tipo Web
en los lobbies de los hoteles.
Soporta FRs: A13
Sección de Requerimientos Funcionales.
• Esta sección del SRS es una lista completa detallada de los requerimientos funcionales que comprende cada caso de uso.
• A cada FR se le asigna un identificador consistente del código de prioridad y el identificador del caso de uso
• Se especifica la descripción del FR.
• Por ejemplo:
Ingeniería de Software. Obtención de los Requerimientos Página 30
• Por ejemplo:
FR Descripción
E1-1 El Sistema permitirá al Agente de Reservaciones crear,
consultar, actualizar y borrar una reservación.
E1-2 Una reservación permitirá reservar uno o más cuartos
por un período de tiempo.
Detalle de los Requerimientos.
• Un elemento importante de la descripción de un FR es la palabra "permitirá" o "hará". Por ejemplo:
El Sistema permitirá al Agente de Reservaciones crear, consultar, actualizar pero NO borrar una reservación.
Ingeniería de Software. Obtención de los Requerimientos Página 31
• Hay que detallar el requerimiento lo más posible. Algunas consideraciones:
– Especificar los datos necesarios o utilizados para el caso de uso.
– Especificar las relaciones entre objetos y actividades.
– Especificar las estrategias para llevar a cabo una actividad.
– Especificar las restricciones de un objeto o actividad.
La Importancia de la "Rastreabilidad".
• Los FRs detallados definen las actividades que realizará el Sistema.
En las siguientes disciplinas (análisis, diseño, implementación y
pruebas) es importante verificar repetidamente que el sistema
satisfaga sus requerimientos.
• Se usan los códigos de los FRs en anotaciones de UML para
indicar que un componente satisface un requerimiento.
Ingeniería de Software. Obtención de los Requerimientos Página 32
indicar que un componente satisface un requerimiento.
• Se utilizan los códigos de los FRs en comentarios en el código
fuente para indicar que un componente de código satisface un
requerimiento.
• También se usan los códigos de los FRs en los planes de prueba
para mostrar que las pruebas verifican que un FR se satisfaga.
Sección de Requerimientos No-funcionales.
• Esta sección del SRS es una lista completa detallada de los
requerimientos no-funcionales agrupados por cualidades del
sistema.
• A cada NFR se le asigna un identificador basado en el del
Ingeniería de Software. Obtención de los Requerimientos Página 33
• A cada NFR se le asigna un identificador basado en el del
caso de uso
• Se especifica la descripción del NFR.
Sección de Requerimientos No-funcionales (2).
• Por ejemplo:
NFR Descripción
E1-101 Basados en evidencia histórica sabemos que hay
aproximadamente 150 reservaciones por mes en cada uno de
los hoteles y 100 reservaciones en el de vacaciones de la
Sierra. Por tanto, el Sistema debe soportar un mínimo de 1300
Ingeniería de Software. Obtención de los Requerimientos Página 34
Sierra. Por tanto, el Sistema debe soportar un mínimo de 1300
registros de reservaciones por mes.
E1-102 La GUI de HotelApp debe tener un tiempo de respuesta menor
a 5 segundos para cualquier entrada del usuario, medida en el
Application Server para eliminar variabilidad de la red.
E1-103 HotelApp debe soportar al menos 5 usuarios simultáneamente
en cada hotel.
El Glosario del Proyecto.
• El glosario en el SRS debe incluir:
– Términos de la Industria.
– Sinónimos.
Ingeniería de Software. Obtención de los Requerimientos Página 35
– Sinónimos.
– Términos de tecnología.
– Términos de desarrollo de Software.
Ejercicio:Desarrollo del SRS del Torneo de Futbol.
• Llevar a cabo entrevistas simuladas con algunos de los
involucrados en el Torneo de Futbol, por ejemplo, jugadores,
árbitros, expertos en el campo, etc.
• Generar el Documento de Especificaciones del Sistema (SRS)
Ingeniería de Software. Obtención de los Requerimientos Página 36
• Generar el Documento de Especificaciones del Sistema (SRS)
incluyendo las seis secciones.