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.


Planeación de la Obtención de Requerimientos.

Es necesario:

• Identificar todas las fuentes necesarias de

requerimientos.


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.


• 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:


• 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)


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.


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?


• ¿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"?


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.


• 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.


• 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


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


• 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:


• 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


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.


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".


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.


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.


• 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.


• 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.


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:


• 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.


• 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.


– 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.


• 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.


• 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


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


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.


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.


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:


• 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.


• 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.


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


• 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


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.


– 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)


• Generar el Documento de Especificaciones del Sistema (SRS)

incluyendo las seis secciones.

requerimientos

Documents