Manual 2011-II 04 Análisis y Diseño de Sistemas II (Adm Sist) Teoría (0654)

106

the Requirements Process”, Addison-Wesley, 1999) que puede ser útil en proyectos reales. Varias de estas tarjetas, se pueden utilizar para recoger información relevante durante las primeras fases del proceso.

Tabla 8.2. Tarjeta de Requisitos La explicación de cada sección es como siguiente: Requisito #: Número que identifica a cada requisito Clasificación: Indica a qué parte del sistema afecta. Por ejemplo: pedidos, contabilidad, ventas, etc. Tipo: Funcional, no funcional Descripción: Una frase que describe el requisito y tipo “característica (feature). Razón: ¿Por qué es importante este requisito? Origen: ¿quién lo pide? Prioridad: Importancia del requisito. Puede valorarse de 0 a 3, por ejemplo. Dependencias: Otros requisitos de los que depende. Conflictos: Requisitos que, de alguna forma, lo contradicen. Referencias: Especificar qué otros documentos son necesarios para comprender el requisito. Historia: Historia de los cambios al requisito.

• •

• •

• • •

• • •

•

2.3. Especificación de requisitos En esta etapa se debe obtener un documento de especificación de requisitos (ERS, Especificación de Requisitos del Software ), en el cual se llega a definir de una forma completa, precisa y verificable cada uno de los requisitos o necesidades que debe satisfacer el sistema a desarrollar, además de sus respectivas restricciones (software, hardware). La diversidad de personas que forman parte de un proyecto software hace que sea necesario establecer un marco de terminología común. Por esta razón, son muchas las propuestas que abogan por desarrollar un glosario de términos en el que se recogen y definen los conceptos más relevantes y críticos para el sistema.

2.4. Validación de requisitos Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos define el sistema o proyecto. En esta etapa, solamente entran aquellos

CARRERAS PROFESIONALES

CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS II (TEORÍA)

107

requisitos que se mencionaron en la especificación de requerimientos de software. Pueden utilizarse, en conjunto o de forma individual, varias técnicas de validación de requisitos: 1. Revisiones de requisitos. requisitos. Los requisitos son analizados analizados sistemáticamente sistemáticamente por un equipo de revisores. 2. Construcción de prototipos. prototipos. Esta técnica muestra un modelo ejecutable del sistema a los usuarios. Éstos pueden experimentar con este modelo para ver si cumple sus necesidades reales. 3. Generación de casos de prueba. Los requisitos deben probarse, a menudo revela los problemas en los requisitos. Si una prueba es difícil o imposible de diseñar, significa que los requisitos serán difíciles de implementar y deberían ser considerados considerados nuevamente. 4. Matrices de trazabilidad. trazabilidad. Esta técnica técnica consiste en marcar marcar los objetivos del del sistema y chequearlos contra los requisitos del mismo. Es necesario ir viendo qué objetivos cubre cada requisito, de esta forma se podrán detectar inconsistencias u objetivos no cubiertos. En definitiva, la validación de requisitos realmente significa asegurarse de que el documento de requisitos represente una descripción clara del sistema, y es una verificación final de que los requisitos cubren las necesidades de los usuarios. La diferencia con el análisis es clara, pues mientras que en el análisis se trabaja sobre el boceto del documento de requisitos, en la validación se utiliza el documento final, lo que equivale a decir, los requisitos "depurados".

3. Gestión de los requisitos

Los requisitos cambian y esto persiste durante el proyecto. Estos son los siguientes cambios ocurren: • • • •

• • • •

Cambios tecnológicos Cambios en las estrategias estrateg ias o prioridades del negocio Modificaciones Modificaciones en leyes y/o regulaciones regulaciones Porque al analizar el el problema, no no se hacen las preguntas preguntas correctas a las personas correctas Porque cambió el problema que se estaba resolviendo Porque los usuarios cambiaron su forma de pensar o sus percepciones Porque cambió el ambiente de negocios Porque cambió el mercado en el cual se desenvuelve el negocio.

Los cambios deben controlarse y documentarse. Hay que convivir con el cambio. Por lo tanto, es esencial planear posibles cambios a los requisitos cuando el sistema sea desarrollado y utilizado y este proceso se hace indispensable, más aún, cuando se trata de sistemas grandes. La gestión de requisitos es el conjunto de actividades que ayudan a identificar, controlar y seguir los requisitos y sus cambios en cualquier momento. Básicamente, consiste en planificar la gestión de requisitos y gestionar sus cambios. cambios. De este modo, se asegura la consistencia entre los requisitos y el sistema.


CIBERTEC

108

3.1. Planificación de la gestión de requisitos Esta primera etapa es esencial en el proceso de gestión de requisitos, pues como se mencionó anteriormente, la gestión de requisitos tiene un costo elevado. Para cada proyecto, la etapa de planificación establece el nivel de detalle necesario en la gestión de requisitos. Durante la etapa de gestión de requisitos, habrá que decidir sobre los siguientes aspectos: •

La identificación identificación de requisitos

•

Un proceso de gestión del cambio

Políticas de de rastreo o trazabilidad: trazabilidad: Definen la relación entre requisitos requisitos y la de éstos y el diseño del sistema. 3.2. Gestión del cambio de los requisitos La gestión del cambio se debe aplicar a todos los cambios propuestos. La ventaja de ello es que se asegura que todos los cambios propuestos son tratados de forma consistente y todos los cambios en el documento de requisitos se hacen de forma controlada. •

ACTIVIDADES PROPUESTAS 1. Indique cuáles cuáles son los los factores que causan problemas a los proyectos proyectos de software (Project challenged) según challenged) según el reporte CHAOS del grupo Standish. 2. Investigue cómo la la herramienta Rational Rational Requisite Pro apoya apoya en la gestión de Ingeniería de requerimientos. requerimientos. a) ¿Cómo se administran los proyectos? b) ¿Qué paquetes contiene el proyecto? c) ¿Qué documentos se pueden gestionar en la herramienta y con que editor editor de texto? d) ¿Qué tipos de requisitos requisitos podemos crear y efectuar su trazabilida trazabilidadd durante la gestión?


CIBERTEC


109

Resumen



La ingeniería de requisitos requisitos nace como respuesta a la crisis crisis del software, debido a que de todos los problemas que se presentan en los proyectos de software indudablemente el principal motivo para esos costos y tiempos elevados es la falta de un adecuado manejo o gestión de requisitos.



El proceso de ingeniería ingeniería de requisitos incluye un estudio de viabilidad, viabilidad, así como la obtención, análisis, especificación, validación validación y gestión de requisitos.



Los cambios en los negocios, organizacionales y técnicos inevitablemente conducen a cambios en los requisitos de un sistema software . La gestión de requisitos es el proceso de gestionar y controlar estos cambios.



El proceso de gestión de requisitos incluye incluye la gestión de la planificación, en la cual se diseñan las políticas y procedimientos para la gestión de requisitos; y del cambio, en la que se analiza los cambios propuestos en los requisitos y se evalúa su impacto.



Si desea saber más acerca de estos temas, temas, puede consultar los siguientes siguientes libros:  “INGENIERÍA

DEL SOFTWARE” de Ian Sommerville, 7ª edición. El capítulo 7 trata el proceso de la ingeniería de requisitos. requisitos.



Además, puede consultar consultar las siguientes siguientes páginas: páginas: 

http://www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf http://www.csus.edu/indiv/v/velianitis/161/Cha osReport.pdf Aquí se expone los resultados del reporte CHAOS de 1994.



http://www.materiabiz.com/mbz/ityoperaciones/nota.vsp?ni http://www.materiabiz.com/mbz/ityoperacio nes/nota.vsp?nid=29672 d=29672 Aquí encontrará el artículo “El 71 por ciento de los proyectos de sistemas fracasan. ¿Por qué?”. Escrito por Silvio Szostak, Profesor del Programa de Negocios y Tecnología de la Universidad Torcuato Di Tella, Buenos Aires. Este artículo describe los resultados del reporte CHAOS del 2004.



http://www.standishgroup.com/newsroom/chaos_2009.php http://www.standishgroup.com/newsroom/cha os_2009.php En este link el grupo Standish expone un resumen del reporte CHAOS 2009.


CIBERTEC

110

ESQUEMA DEL TEMA 6: INGENIERÍA DE REQUISITOS 1. Ingeniería de requisitos La meta de la ingeniería de requisitos es crear y mantener los tipos de requisitos y documentos del sistema. El proceso se divide en las siguientes actividades: Estudio de viabilidad Obtención y análisis de requisitos Especificación de requisitos Validación de requisitos • • • •

2. Gestión de los l os requisitos Las actividades de la gestión de requisitos son las siguientes: Planificación de la gestión de requisitos Gestión del cambio de los requisitos. requisito s. • •


CIBERTEC


111

UNIDAD DE APRENDIZAJE

2 TEMA

7 PIRÁMIDE DE REQUISITOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO 1. Pirámide de requisitos 2. Características de un buen requisito.

ACTIVIDADES PROPUESTAS 1. Los alumnos clasifican los requisitos de una lista propuesta según las categorías descritas en la pirámide de requisitos. 2. Los alumnos investigarán a cerca de los atributos de calidad, respecto a FURPS+. Luego, expondrán sus atributos FURPS+ respecto a su proyecto.


CIBERTEC

112

1. PIRÁMIDE DE REQUISITOS

Un requisito se define como una condición o capacidad a la que debe ajustarse el sistema que se construye para satisfacer un contrato, norma, especificación u otro documento formalmente impuesto. Dependiendo del formato, fuente y características comunes, los requisitos pueden dividirse en diferentes tipos. A continuación se indican los tipos de requisitos que son usados en los proyectos: Necesidades del stakeholder Características Casos de uso Requisitos suplementarios Casos de prueba Escenarios. • • • • • •

Estos tipos de requisitos pueden ser presentados en la forma de una pirámide, tal como se muestra en la Figura 9.1.

Figura 9.1 - Pirámide de Requisitos En el nivel superior están las necesidades de stakeholders. En los niveles inferiores, las características, casos de uso y requisitos suplementarios. Los diferentes niveles marcan el nivel de detalle, pues cuanto menor sea el nivel, la exigencia de detalle de un requisito será mayor. Por ejemplo, una necesidad de stakeholder podría ser: "Los datos deben ser persistentes." La característica puede refinar este requisito así: "El sistema debe utilizar una base de datos relacional." Y, en el nivel de requisito suplementario, es aún más específico: "El sistema debe usar el motor de base de datos Oracle 9i." Esto pone de manifiesto que cuanto más se avance a los niveles inferiores de la pirámide, más detallado será el requisito. Una de las mejores prácticas de gestión de requisitos es tener por lo menos dos niveles de abstracción de requisitos.


CIBERTEC


113

1.1. Necesidad del stakeholder Describe lo que el sistema debería hacer para mejorar o reducir el costo de un proceso de negocio, incrementar ganancias o alcanzar regulaciones y otras obligaciones. Es proporcionado por un stakeholder. Ejemplo: ID

Necesidad “Necesito notificar al jefe de soporte cuando una solicitud de soporte es iniciada” “Necesito asignar solicitudes de soporte a un ingeniero de soporte específico” “Necesito mantener informado al cliente del progreso de una solicitud de soporte”

STRQ1 STRQ2 STRQ3

Stakeholder Jefe de soporte Jefe de soporte Cliente

Tabla 9.1 - Ejemplo de Necesidades de stakeholders

1.2. Característica del sistema Es un servicio que el sistema provee para satisfacer una o más necesidades del afectado. Formulada por el analista del negocio. Están descritas en el documento Visión. Estos son algunos ejemplos: Descripción La solicitud de soporte El sistema funcionará FEAT1 pasará por una serie de orientado al trabajo en flujo etapas y asignaciones Un sistema de notificación Capacidad de notificación por de correo centralizado será FEAT2 e-mail utilizado por el flujo de trabajo Tabla 9.2 - Ejemplo de Características del sistema ID

Característica

1.3. Caso de uso Es la descripción del comportamiento del sistema en términos de secuencia de acciones entre el actor y el sistema. El formato de un caso de uso creado por el analista de sistemas y puede ser revisado por el usuario ó stakeholder. El propósito de un caso de uso es facilitar los acuerdos (contrato) entre los desarrolladores, clientes y usuarios acerca de lo que el sistema debe hacer. También es la base para las realizaciones de casos de uso , las cuales juegan un papel importante en las disciplinas de análisis y diseño. Los casos de uso son un buen camino para expresar los requisitos funcionales del sistema; por ello, son utilizados para representar las funcionalidades del sistema mediante un diagrama conocido como Diagrama de casos de uso , en el cual contiene actores (roles de usuarios), casos de uso (funcionalidades) y las relaciones entre ellos. Este diagrama se crea en la disciplina Captura de Requisitos. A continuación se muestra algunos ejemplos de casos de uso para un sistema de control de reservaciones y hospedaje de un hotel:


CIBERTEC

114

ID UC1

UC2

UC3

UC4

T

Descripción Este caso de uso permite Generar reserva de registrar la reserva de uno o habitaciones más habitaciones disponibles para un cliente que lo solicita. El caso de uso permite la disponibilidad de Consultar disponibilidad de consultar una habitación por algún habitaciones criterio de búsqueda: categoría, tipo y/o rango de precios. El caso de uso permite realizar la búsqueda de un cliente por Buscar clientes algún criterio de búsqueda: nombres, apellido paterno y/o apellido materno. El caso de uso permite mantener actualizado el registro de los clientes del hotel. De acuerdo a su Mantener clientes necesidad, el recepcionista puede agregar, actualizar y desactivar el registro de un cliente. Caso de Uso

abla 9.3 - Ejemplo de Casos de uso del sistema

1.4. Requisito suplementario También conocido como requisito de arquitectura e implementación o factores de calidad en el contexto de desarrollo de software. Son todos los requisitos no funcionales que no pueden ser expresados con casos de uso. Para capturar requisitos suplementarios se debe usar el enfoque sugerido por Peter Eeles7: •

• • • •

Crear una lista de categorías de los requisitos suplementarios (según FURPS+, por ejemplo). Crear preguntas para cada categoría. Explicar al cliente el impacto y costo de cada decisión. Capturar la respuesta del cliente a cada pregunta. Asignar prioridad y peso a cada requisito.

Por otro lado, estos tipos de requisitos también se obtienen a partir de las características (features ) del sistema identificado en un nivel anterior de la pirámide de requisitos. Cabe aclarar que existen varios tipos de clasificaciones para los requisitos suplementarios, como McCall and Matsumoto (1984), la clasificación utilizada por ISO (1991), FURSP+ (1992 – adoptado por Rational Software). Nuestro curso sigue las categorías FURSP+, que se muestran en la siguiente tabla. Se consideran los requisitos Funcionalidad (Funcionality), Usabilidad 7

Arquitecto Ejecutivo de TI, trabajando en IBM Rational Software.


CIBERTEC


115

(Usability) Confiabilidad (Reliability), Rendimiento (Performance) y Soportabilidad (Supportability) en categorías. Además de requisitos Plus (+) (requerimientos de diseño, implementación, interfaz, operaciones, empaquetamiento y legales). Categoría Funcionalidad

Facilidad de uso

Confiabilidad

Rendimiento

Rendimiento

Sub categoría Accesibilidad Estética Consistencia de Interfaz usuario Ergonomía Fácil de usar Disponibilidad Robustez Precisión Recuperación Tolerancia a fallos Seguro Seguridad Corrección Rendimiento Tiempo de respuesta Tiempo de recuperación Tiempo de Inicio/Apagado Capacidad Utilización de recursos Comprobabilidad Adaptabilidad Mantenibilidad Configurabilidad Actualización Fácil de instalar Escalabilidad Portabilidad Reutilización Interoperabilidad Conformidad Fácil de reemplazar Mutabilidad Fácil de analizar Fácil de localizar

de

Restricciones de diseño Requisitos de Interfaz Documentación de usuario en línea y sistema de ayuda Requisitos legales, copyright y otros Tabla 9.4 - Clasificación de Requisitos Suplementarios – FURPS+


CIBERTEC

116

1.5. Caso de prueba Consiste en una especificación de entradas de pruebas, ejecución de condiciones y resultados esperados. Los casos de prueba pueden ir anexos a un Plan de Pruebas Integral. Los casos de prueba son creados para determinar si el requisito de un sistema, funcional o no funcional, es parcial o completamente satisfactorio. Algunos casos de prueba los puede crear el analista (desarrollador), otros los testers (encargados de las pruebas en calidad) y otros los clientes o usuarios (expertos del negocio). Los casos de prueba que se crean pueden ser utilizados para las pruebas manuales, así como para pruebas automatizadas utilizando herramientas, tales como IBM Rational Robot e IBM Rational Functional Tester.

1.6. Escenario Un escenario es una instancia de un caso de uso. Es una secuencia específica de acciones obtenidas del flujo de eventos de un caso de uso (flujo básico – subflujos – flujos alternativos). Por ejemplo, a continuación se muestra los posibles escenarios de un caso de uso que tiene cuatro flujos alternativos A1, A2, A3 y A4. Para encontrar un escenario, se necesita dibujar las posibles líneas que siguen un camino desde el flujo básico B.

Figura 9.2 - Escenarios de un caso de uso


CIBERTEC


117

2. CARACTERÍSTICAS DE UN BUEN REQUISITO

Un requisito debe cumplir varios criterios para ser considerado un "buen requisito". Las características que deben tener los requisitos son: •

• • • •

No ambiguo Verificable Claro Correcto Comprensible

• • • • •

Factible Independiente Atómico Necesario Abstracto.

Además de estos criterios para los requisitos individuales, tres criterios se aplican al conjunto de requisitos. El conjunto debe reunir las siguientes condiciones: Consistente No redundante Completo. • • •

A continuación, se muestran ejemplos de cada uno de las características de un buen requisito.

2.1. No ambiguo Un requisito no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición no debe causar confusiones al lector. A veces la ambigüedad se introduce por utilizar acrónimos o siglas sin definir: REQ1: El sistema será implementado utilizando ASP.

En este ejemplo ¿ASP se refiere a Active Server Pages o Application Service Provider? Para solucionar este problema, es mejor indicar el nombre completo y especificar el acrónimo entre paréntesis: REQ1: El sistema será implementado utilizando Active Server Pages (ASP).

A continuación otro ejemplo: REQ2: El sistema no aceptará contraseñas con más de 15 caracteres.

No está claro lo que el sistema se supone debe hacer: ¿El sistema no permitirá al usuario ingresar más de 15 caracteres? ¿El sistema truncará la cadena ingresada a 15 caracteres? ¿El sistema mostrará un mensaje de error si el usuario ingresa más de 15 caracteres? • • •

El enunciado correcto para este requisito debe ser así: REQ2: El sistema no aceptará las contraseñas de más de 15 caracteres. Si el usuario ingresa más de 15 caracteres, al digitar su contraseña, un mensaje de error le pedirá al usuario que debe corregirlo.

Una cierta ambigüedad puede ocurrir a través de la colocación de una palabra: REQ3: En la pantalla "Vuelos ", el usuario solo puede ver un registro.


CIBERTEC

118

¿Esto significa que el usuario puede "ver solamente" y no eliminar o actualizar, o significa que el usuario puede “ver solo un registro”, no dos o tres? Una forma de solucionar el problema es volver a escribir el requisito desde el punto de vista del sistema: REQ3: En la pantalla "Vuelos ", el sistema mostrará un solo vuelo.

2.2. Verificable Un requisito es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas. Para que un requisito sea verificable, éste debe ser claro, preciso y no ambiguo. Algunas de estas palabras pueden hacer que un requisito no sea verificable: Algunos adjetivos: robusto, seguro, preciso, eficaz, eficiente, ampliable, flexible, fácil de mantener, confiable, amigable y adecuada. Algunos adverbios y frases adverbiales: rápido, seguro o de manera oportuna. Palabras o acrónimos no específicos: etc., y/o, TBD. Pronombres indefinidos: algunos, muchos, más, mucho, varios, cualquier, cualquiera, cualquier cosa, algunos, alguien, etc. Algunos verbos en infinitivo: gestionar, controlar´… Voz pasiva: el sujeto de la oración recibe la acción del verbo en lugar de su realización.

•

•

• •

• •

El requisito que se enuncia a continuación presenta un pronombre indefinido: REQ4: El sistema deberá resistir el uso concurrente por muchos usuarios.

La pregunta es ¿qué número debe ser considerado "muchos" -10, 100, 1000? Una mejor alternativa de enunciarlo: REQ4: El sistema deberá resistir el uso concurrente de a lo más 500 usuarios.

Otros ejemplos: REQ5: “La facilidad de búsqueda debería permitir al usuario encontrar una reserva basada en el apellido, día, etc.”

En este ejemplo, todos los criterios de búsqueda deberían ser listados explícitamente. El desarrollador no puede adivinar lo que significa “etc”. REQ6: “El código del aeropuerto debe ser ingresado.”

¿Quién ingresa el código, el sistema o el usuario? Forma correcta: REQ6: “El código del aeropuerto debe ser ingresado por el usuario“.


CIBERTEC


119

2.3. Claro Un requisito es claro si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Por ejemplo esta es una frase compleja para un requisito: REQ7: A veces el usuario introducirá Código del aeropuerto, que el sistema comprenderá, pero, a veces, será sustituida por el nombre de la ciudad más cercana, por lo que el usuario no necesita saber cuál es el código del aeropuerto, y seguirá siendo entendido por el sistema.

Esta frase puede ser sustituida por una más sencilla: REQ7: El sistema deberá identificar el aeropuerto por el Código de Aeropuerto o el Nombre de Ciudad.

2.4. Correcto Si un requisito contiene hechos, éstos deben ser ciertos. Por ejemplo, este requisito no está escrito correctamente: REQ8: El sistema deberá aplicar descuentos en las planillas de los trabajadores (incluyendo el 18% de los aportes del sistema de pensiones).

El porcentaje de aportación depende de la entidad administradora de fondos de pensiones, por lo que la cifra indicada del 18% es incorrecta.

2.5. Comprensible Los requisitos deberían ser gramaticalmente correctos y escritos en un estilo consistente. Un estándar de convenciones debe ser utilizada. Tal es así que la palabra "deberá" se debe utilizar en lugar de "podrá", "debe", o "puede".

2.6. Factible El requisito debería ser factible dentro de las limitaciones existentes, tales como tiempo, dinero y recursos disponibles: REQ9: El sistema tendrá una interfaz de lenguaje natural que comprenderá comandos dados en el idioma Inglés.

Este requisito puede no ser factible en un corto lapso de tiempo de desarrollo (traducir un comando).

2.7. Independiente Para entender un requisito, no debería haber necesidad de conocer a ningún otro requisito: REQ10: La lista de vuelos disponibles incluirá el números de vuelo, hora de salida y tiempo de llegada del vuelo. REQ11: Esta debería ser ordenado por precio.

La palabra "Esta" en la segunda frase se refiere al requisito anterior. Sin embargo, si se cambia el orden de los requisitos, el REQ11no será comprensible.

CIBERTEC


120

2.8. Atómico El requisito debe contener un elemento de trazabilidad individual: REQ12: El sistema deberá proporcionar la posibilidad de reservar el vuelo, comprar un ticket, reservar una habitación de hotel, reservar un auto, y proporcionar información sobre lugares de interés.

Este requisito se compone de cinco requisitos atómicos, lo que hace muy difícil la trazabilidad. Las oraciones que incluyen las palabras "y" o "pero" debería revisarse para ver si se puede romper en varios requisitos atómicos. Lo correcto sería:

REQ12: El sistema deberá proporcionar la posibilidad de reservar el vuelo. REQ13: El sistema deberá permitir comprar un ticket. REQ14: El sistema deberá proporcionar la opción de reservar una habitación de hotel. REQ15: El sistema deberá permitir reservar un auto. REQ16: El sistema deberá proporcionar información sobre lugares de interés.

2.9. Necesario Un requisito es necesario si su omisión provoca una deficiencia en el sistema a construir, y, además, su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Por ejemplo, el siguiente requisito debe ser removido porque no proporciona ninguna información adicional de lo que el sistema debe hacer: REQ17: Todos los requisitos especificados en el documento Visión deberían ser implementados y probados.

2.10. Abstracto Los requisitos no deben contener información innecesaria de diseño e implementación: REQ18: La información del sistema deberá ser almacenada en un archivo de texto.

En el ejemplo, cómo se almacena la información, es transparente para el usuario y debe ser decisión del diseñador o del arquitecto.

2.11. Consistente Un requisito es consistente si no es contradictorio con otro requisito. Por ejemplo puede darse el caso en que dos requisitos utilicen términos diferentes para un mismo concepto: REQ19: El sistema deberá permitir reservar una habitación. REQ20: El sistema deberá permitir registrar el hospedaje a partir de una separación de habitación registrada.


CIBERTEC


121

Para evitar esta situación conviene estandarizar términos. Entonces, los requisitos anteriores se escriben mejor así: REQ19: El sistema deberá permitir reservar una habitación. REQ20: El sistema deberá permitir registrar el hospedaje a partir de una reserva de habitación registrada.

Los enunciados siguientes muestran conflictos que pueden resolverse mediante el análisis de las condiciones en las que el requisito se lleva a cabo: REQ21: Las fechas deberán ser mostradas en el formato mm/dd/aaaa. REQ22: Las fechas deberán ser mostradas en el formato dd/mm/aaaa.

Aquí, si el REQ19 fue presentado por un usuario americano y el REQ20 por un usuario francés, los requisitos anteriores podrán ser escritos así: REQ21: Para los usuarios en los EE.UU., las fechas se muestran en el formato mm/dd/aaaa. REQ22: Para los usuarios en Francia, las fechas se muestran en el formato dd/mm/aaaa.

2.12. No redundante Cada requisito debe ser expresado una sola vez y no debe solaparse con otro requisito: REQ23: Un calendario estará disponible para ayudar a la entrada de la fecha de vuelo. REQ24: El sistema deberá mostrar un calendario pop-up para ingresar cualquier fecha.

En estos ejemplos es fácil darse cuenta que el primer requisito (en relación con la fecha, sólo del vuelo) es un subconjunto del segundo (en relación con cualquier fecha introducida por el usuario).

2.13. Completo Un requisito está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión sin necesidad de agregar otro requisito para su entendimiento.

CIBERTEC


122

ACTIVIDADES PROPUESTAS De acuerdo a la pirámide de requisitos, a qué tipo de requisito corresponde cada uno de los siguientes enunciados: NOTA: Utilice STRQ, FEAT, UC o SUPL para indicar si se trata de una necesidad de stakeholder, característica del sistema, caso de uso o requisito suplementario respectivamente. R01. El sistema deberá garantizar que su despliegue se pueda realizar, ya sea en el lado del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bits sin que esto afecte el rendimiento del mismo. R02. El sistema deberá contar con un Manual Técnico de Referencia para la Aplicación, el cual estará orientado a profesionales capacitados en aspectos técnicos del área de sistemas. R03. La clave de los usuarios considerará las siguientes políticas: - Expirar según parametrización del sistema - Tener mínimo una longitud de 8 caracteres - Contener letras y números - No puede contener espacios - No pueden repetirse las 3 últimas contraseñas - No contendrá el nombre o apellido de la persona dueña del usuario R04. El código fuente del sistema deberá cumplir con el estándar de codificación definido en el documento “Estándares y Nomenclaturas de Código Fuente”. R05. El sistema utilizará el idioma castellano para los mensajes y textos en la pantalla. R06. El sistema será utilizado por clientes de todo el mundo. Adicionalmente, la Organización Pro-Turismo exige que para anunciar servicios en su portal, éstos deben estar provistos en español, inglés y portugués. Estos tres idiomas deben ser soportados por el producto desarrollado. R07. El sistema deberá permitir la creación, modificación, activación, desactivación y autorización de los roles de usuarios definidos. R08. El sistema deberá prever contingencias que pueden afectar la prestación estable y permanente del servicio. La siguiente es la lista de las contingencias que se deben tener en cuenta y se pueden considerar críticas: Sobrecarga del sistema por volumen de usuarios. Caída del sistema por sobrecarga de procesos. Caída del sistema por sobrecarga de transacciones. Caída del sistema por volumen de datos excedido en la base de datos. • • • •

R09. El sistema deberá contar con el manual de FAQ (Frequent Asked Questions), en línea e impreso, que es un resumen con las respuestas a las preguntas más frecuentes que se hacen los usuarios. R10. El sistema deberá utilizar una base de datos relacional Oracle.


CIBERTEC


123

Resumen 

La pirámide de requisitos muestra una jerarquía de requisitos de acuerdo al nivel de detalle en que se expresan. En los niveles inferiores de la pirámide se encuentran los requisitos con mayor nivel de detalle.



Los requisitos suplementarios son todos los requisitos que no pueden ser expresados con casos de uso.



Un requisito debe presentar las características de un "buen requisito".



Si desea saber más acerca de estos temas, puede consultar el siguiente libro:  “REQUIREMENTS

MANAGEMENT USING IBM RATIONAL REQUISITE PRO” de Peter Zielczynski. El primer capítulo trata la gestión de requisitos, el cual empieza con la descripción de la pirámide de requisitos y características de un buen requisito y termina con una descripción breve del proceso de gestión de requisitos.



Además, puede consultar las siguientes páginas. 

http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html Este artículo ilustra un método formal de derivación de casos de prueba funcional de casos de uso, incluyendo cómo crear un caso de uso, derivar todos los escenarios, y crear casos de prueba razonable, así como el uso de IBM Rational Requisite Pro para la trazabilidad de los casos de uso con escenarios y casos de prueba.

CIBERTEC


124

ESQUEMA DEL TEMA 7: PIRÁMIDE DE REQUISITOS 1. Pirámide de requisitos La pirámide muestra los niveles de los tipos de requisitos que se administran en la ingeniería de requisitos. Los tipos de requisitos son los siguientes: Necesidades del stakeholder Características del sistema Casos de uso Requisitos suplementarios Casos de prueba Escenarios. 2. Características de un buen requisito Un requisito se define como una condición o capacidad a la que debe ajustarse el sistema. Un requisito debe cumplir varios criterios para ser considerado un "buen requisito". Las características que deben tener los requisitos son: No ambiguo Verificable Claro Correcto Comprensible Factible Independiente Atómico Necesario Abstracto Consistente No redundante Completo. • • • • • •

• • • • • • • • • • • • •


CIBERTEC


125


2 TEMA

8 GESTIÓN DE REQUISITOS EN RUP LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO 1. Visión General de la Gestión de Requisitos en RUP.

ACTIVIDADES PROPUESTAS 1. Los alumnos, a partir de una lista de necesidades de stakeholder (NEEDS), crean las características del sistema (FEATURES ) indicando las estrategias de transformación utilizadas. 2. Los alumnos crearán una entrevista o cuestionario para capturar los requisitos, por parte de los stakeholders o usuarios. 3. Los alumnos, a partir de una especificación de caso de uso de su proyecto crean los casos de prueba.

CIBERTEC


126

1. VISIÓN GENERAL DE LA GESTIÓN DE REQUISITOS EN RUP

En RUP, una descripción simplificada del proceso de gestión de requisitos contiene los siguientes pasos: • • • • • • • •

Establecimiento de un plan de gestión de requisitos Captura de requisitos Desarrollo del documento Visión Creación de casos de uso Especificación suplementaria Creación de casos de prueba de casos de uso Creación de casos de prueba de la especificación suplementaria Diseño del sistema.

Los siguientes tipos de documentos se utilizan comúnmente en la gestión de requisitos: •

•

•

•

•

•

•

•

Plan de Gestión de Requisitos. Este documento establece los lineamientos para el establecimiento de los documentos de requisitos, tipos, características, y la trazabilidad con el fin de gestionar los requisitos del proyecto. Peticiones de los stakeholders. En este documento se especifican las necesidades de los stakeholders. Visión. Este documento da la visión total del sistema: principales características, necesidades de los stakeholders y servicios esenciales proporcionados. Glosario. Es importante que todos los stakeholders utilicen términos consistentes para expresar sus necesidades. El glosario es una herramienta para capturar y definir los términos utilizados en el proyecto. Especificación de casos de uso. Las especificaciones de casos de uso sirven como un formato para expresar el flujo de eventos de los requisitos funcionales. Un caso de uso es una secuencia de acciones llevadas a cabo por un sistema que produce un resultado observable (una salida de trabajo) de valor a un actor en particular. Especificación de requisitos suplementarios. Este documento captura los requisitos que no pueden vincularse directamente a cualquier caso de uso específico y, sobre todo si se trata de los requisitos no funcionales y restricciones de diseño. Especificación de requisitos de software. Este documento captura todos los requisitos del sistema software , es decir, contiene la lista de los requisitos funcionales y no funcionales. Plan de pruebas. Este documento describe el objetivo de las pruebas

(componentes, aplicaciones, sistemas), las etapas de la prueba, y los tipos de pruebas que serán abordados por este plan.

El primer paso, el plan de gestión de los requisitos, define los requisitos de la pirámide. En cada uno de los siguientes siete pasos, uno de los elementos de la pirámide es construido. En la tabla 10.1 se describe que tipos de requisitos y qué documentos se crean en cada paso. Como puede apreciar, el proceso, a partir del segundo paso, navega a través de la pirámide de arriba hacia abajo y de izquierda a derecha.


CIBERTEC


Paso 1

Descripción

Tipo de requisito

Documentos

Establecimiento de un plan de _______________ gestión de requisitos

2 3

127

Plan de gestión de requisitos

Captura de requisitos

Necesidades de stakeholders

Peticiones de stakeholders

Desarrollo del documento Visión

Características

Visión, Glosario

Creación de casos de uso

Casos de uso, escenarios

Especificación de caso de uso

Especificación suplementaria

Requisitos suplementarios


Creación de casos de prueba de casos de uso

Casos de prueba

Plan de casos de prueba

Creación de casos de prueba de la especificación suplementaria

Casos de prueba

Plan de casos de prueba

Diseño del sistema

Diagrama de clases, diagramas de interacción

Diagramas UML

4 5

6

7 8

Tabla 10.1 - Requisitos y documentos creados en el proceso de gestión de requisitos según RUP La gestión de requisitos es un proceso iterativo. En una iteración típica, se pasa por todos los niveles de la pirámide. Incluso en la misma iteración, podemos retornar a pasos anteriores y repetir la actividad. Por ejemplo, durante la creación de un caso de prueba, podemos descubrir que aún nos falta información, y necesitamos más información de los stakeholders , por lo tanto retrocedemos un paso a la “captura de requisitos". Para mantener la integridad del modelo, es importante actualizar todos los requisitos afectados. En las iteraciones iniciales se da énfasis en los primeros pasos (nivel superior de la pirámide), y en las últimas iteraciones se pasa más tiempo en el nivel inferior de la pirámide. A continuación se describe brevemente estos pasos.

1.1. Establecimiento de un plan de gestión de requisitos Una de las primeras tareas en el proyecto es el desarrollo de un “Plan de Gestión de Requisitos” 1. Este plan describe el enfoque global de la gestión de requisitos en el proyecto. El documento da detalles de cómo los requisitos son creados, organizados, modificados y rastreados durante el ciclo de vida del proyecto. También se describen todos los tipos de requisitos y sus atributos utilizados en el proyecto. 1

En inglés es conocido como Requirements Management Plan (RMP).

CIBERTEC


128

¿Cuándo se crea el PGR (Plan de Gestión de Requisitos)? La PGR se puede crear a partir de una plantilla incluida en RequisitePro. Sin embargo para crear un proyecto en RequisitePro tenemos que tomar decisiones documentadas en el PGR. Tomar en cuenta los siguientes aspectos: 1. Todas las decisiones sobre el plan se documentan. 2. Un proyecto de RequisitePro se crea sobre la base al PGR. 3. El PGR es creado a partir de una plantilla de RequisitePro. 4. El documento de Microsoft Word con el PGR se importa en RequisitePro. Aquí hay algunas preguntas que pueden ser contestadas en el plan: ¿Se utilizará alguna herramienta de gestión de requisitos? ¿Qué tipos de requisitos serán rastreados en el proyecto? ¿Cuáles son los atributos de estos requisitos? ¿Dónde se crearán los requisitos, únicamente en una base de datos o en documentos? ¿Entre qué requisitos necesitamos aplicar la trazabilidad? ¿Qué documentos se requieren? ¿Qué requisitos y documentos se utilizarán como un contrato con los clientes? Si una parte del proyecto se subcontrata, ¿qué requisitos y documentos serán utilizados como un contrato con un vendedor? ¿Vamos a seguir la metodología RUP o alguna otra? ¿El cliente necesita documentos específicos para cumplir con su proceso de desarrollo? ¿Cómo la gestión de cambios se llevará a cabo? Suponiendo que se utiliza RequisitePro, ¿todo el sistema se almacenará en un Proyecto RequisitePro o se crearán varios proyectos? ¿Qué proceso garantizará que todos los requisitos serán implementados y verificados? ¿Para qué requisitos o vistas tenemos que generar informes? • • • •

• • •

•

• •

• •

•

•

1.2. Captura de requisitos Este paso se concentra en capturar todas las necesidades de los stakeholders, utilizando una o más técnicas para recolectar requerimientos que se citan a continuación: •

•

•

•

Entrevistas: Son utilizadas para recopilar información de los interesados (stakeholders). Es conveniente la utilización de preguntas abiertas que no sugieran una determinada respuesta. Cuestionarios: Un conjunto de preguntas preparadas para un gran grupo de stakeholders. Workshops (talleres): Reunión de stakeholders por un periodo intensivo. Son coordinados por un experto y a menudo se consigue alentar el compromiso de los participantes, fomentando el espíritu de grupo. Storyboards (guiones gráficos): Uso de una herramienta visual gráfica para mostrar el comportamiento del sistema. Son un conjunto de dibujos que representan las actividades del usuario. Son una especie de prototipos a papel.


CIBERTEC


•

•

•

•

•

129

Role-playing (Juego de roles): A cada miembro del grupo se le asigna un rol, usualmente uno de los usuarios. Sesiones de lluvias de ideas (brainstorming): Presentación de ideas durante una sesión breve e intensiva. Es eficaz porque las ideas más creativas y efectivas son el resultado de la combinación de ideas. Prototipos: Desarrollo de un prototipo para obtener retroalimentación. Consiste de una versión rápida del sistema o parte del mismo. Casos de uso: Descripción de la interacción del usuario con el sistema presentado como una secuencia de pasos. Análisis de documentos: Implica un estudio de documentos que definen la razón de ser del proyecto, tales como planes de negocio, estudio de mercado, contratos, etc.

La técnica a usar dependerá de la naturaleza de los requisitos y el tipo de stakeholder. Es buena práctica especificar el resultado de esta tarea en el documento Peticiones de stakeholder 2 y almacenar cada uno de los requisitos en una base de datos. Esto permitirá asignarles varios atributos, como la prioridad o dificultad. También permite realizar el seguimiento de los requisitos y derivarlos a otros tipos de requisitos. Un punto importante que resaltar es que se debe tener cuidado de no perder o mal interpretar un requisito en este nivel, de lo contrario este problema se propagará durante todo el ciclo de desarrollo. Las necesidades de stakeholders no necesariamente tienen los atributos de un buen requisito mencionados en la sesión anterior; pero los requisitos que se encuentran en niveles inferiores a estas, sí los presentan. Este tipo de requisito se encuentra en el nivel superior de la pirámide, tal como se ilustra en la figura 10.1.

Figura 10.1 - Necesidades de stakeholders en la pirámide

1.3. Desarrollo del documento Visión El documento Visión es uno de documentos más importantes creados en la gestión de requisitos con RUP y el cual puede ser utilizado como un contrato entre los desarrolladores y clientes para los requisitos técnicos. 2

En inglés Stakeholder Requests

CIBERTEC


130

Los propósitos del documento Visión son los siguientes: Definir los límites del sistema Identificar restricciones impuestas en el sistema Conseguir acuerdos con los clientes sobre el alcance del proyecto Crear una base sobre la cual se definen los documentos: especificaciones de casos de uso y especificaciones de requisitos suplementarios. • • • •

La Visión es un repositorio de los requisititos del tipo “Característica” ( Feature ) y son listados en la sección “Características del Producto” del documento. Este tipo de requisitos se muestra en la pirámide en la figura 10.2.

Figura 10.2 - Características del sistema en la pirámide Las características se derivan de las necesidades de los stakeholders. Es importante no perder de vista qué característica fue derivada de las necesidades de stakeholders. Para crear uno o varios requisitos FEAT ( Features ) a partir de los requisitos STRQ (Stakeholders request ) se aplica alguna de las siguientes estrategias de transformación: •

•

•

•

•

•

Copiar: Si no se requieren cambios, el STRQ puede ser copiado a FEAT exactamente como está. Dividir: Si el requisito no es atómico, podemos dividirlo en dos o más requisitos. Aclaración: Aclaración o explicación, se puede aplicar cuando el requisito inicial es poco claro o ambiguo. Cualificación: Logramos cualificar (cuantificar) mediante la adición de restricciones o condiciones al requisito. Puede ayudar a resolver las necesidades contradictorias. Combinación: Si los requisitos son redundantes o se superponen se pueden combinar en un solo requisito. Generalización: Si la necesidad no es abstracta, e incluye algunos detalles innecesarios, podemos aplicar la generalización.


CIBERTEC


•

•

•

•

•

131

Cancelación: A veces un requisito debe ser eliminado. Esto puede suceder cuando el requisito es no viable, innecesario, o incompatible con otro requisito. Completar: Si el conjunto de requisitos es incompleto, puede ser necesario añadir requisitos en esta etapa. Corrección: Corrección puede significar una nueva redacción del requisito para corregir la gramática, ortografía o puntuación; o cambiar una parte de la necesidad que no es cierta. Unificación: Los requisitos que usan un vocabulario inconsistente pueden ser unificados (estandarizados). Adición de detalles: Si el requisito no es lo suficientemente preciso, podemos añadir más detalles. Esta técnica se utiliza a menudo para obtener requisitos verificables de los que no han sido especificados como tal. Una vez creados los requisitos del tipo características (FEAT), se debe especificar sus atributos. Los atributos son las propiedades de un requisito: Ayudan a organizar y analizar los requisitos del proyecto. Se pueden crear reglas para decidir, en base a los atributos, cuáles de los requisitos se implementarán en la siguiente iteración, fase o lanzamiento ( release ). A continuación, se indican los atributos que usualmente se asignan a los tipos de requisitos FEAT: •

•

•

•

•

•

• • •

• • • •

Prioridad: generalmente se usa para determinar el orden de implementación. Estado: seguimiento del progreso del desarrollo del requisito: propuesto, aprobado, incorporado y validado. Dificultad: lo difícil que puede ser la implementación de este requisito, los valores por defecto son de alta, media y baja. Estabilidad: la probabilidad de que el requisito no va a cambiar durante el proyecto. Riesgo: la probabilidad de resultados relacionados con este requisito: problemas con su implementación, incumplimiento de los plazos, etc. Planificación de la iteración: por ejemplo, E1-la primera iteración en la fase de elaboración. Iteración actual. Origen: fuente del requisito. Nombre del contacto: normalmente la persona responsable de este requisito. Mejora de Requisito. Defecto. Autor. Localización: documento en el que el que se encuentra.

Aparte de los atributos enunciados en la lista anterior, el equipo de desarrollo puede agregar otros atributos si así lo prefiere. Por ejemplo, el atributo Importancia, el cual incluye los valores: obligatorio y deseable. En situaciones extremas, múltiples atributos pueden almacenar estos valores de importancia, los cuales no son los mismos que prioridad, porque la importancia según el usuario puede no ser la misma importancia según el gerente del proyecto.

CIBERTEC


132

1.4. Creación de casos de uso Los requisitos funcionales son mejor descritos en forma de casos de uso. Ellos son derivados de características del sistema y a partir de los casos de uso se derivan sus escenarios, tal como se ilustra en la figura 10.3.

Figura 10.3 - Casos de uso y sus escenarios en la pirámide El propósito de los casos de uso es facilitar acuerdos entre desarrolladores, clientes y usuarios acerca de lo que el sistema debe hacer. De este modo, un caso de uso puede ser usado como un contrato entre los desarrolladores y clientes. Este también es la base para las realizaciones de casos de uso, los cuales juegan un papel importante en análisis y diseño; implementación y casos de prueba. Las características de casos de uso son las siguientes: • • • • • •

Son iniciados por un actor. Modelan una interacción entre el actor y el sistema. Describen una secuencia de acciones. Capturan requisitos funcionales. Proporcionan algún valor a un actor. Representan un completo y significativo flujo de eventos.

La creación de casos de uso incluye las siguientes actividades: 1. Encontrar actores 2. Encontrar casos de uso y detallarlos 3. Estructurar el modelo de casos de uso. 1.4.1. Encontrar actores En esta actividad se identifican a los actores a partir de los stakeholders. Un actor puede ser un rol de usuario o un sistema externo que recibe o entrega información. En algunos casos, representaremos al tiempo como actor para indicar que el caso de uso se inicia en un momento específico (Timer).


CIBERTEC


133

1.4.2. Encontrar casos de uso Los casos de uso se identifican a partir de las características especificadas en el paso anterior (desarrollo del documento Visión) y para cada actor identificado hasta el momento. Más casos de uso se pueden obtener, aparte de los derivados de las características, utilizando la técnica workshop con stakeholders. Una vez identificado los casos de uso se procede a describirlos mediante el documento Especificación de Caso de Uso. Por último, se crean diagramas de casos de uso para representar a los actores, casos de uso y las relaciones entre ellos. Estos diagramas se crean en un paquete denominado “Modelo de casos de uso”. Para pequeños sistemas, el modelo de casos de uso puede contener solo un diagrama de casos de uso; mientras que para grandes sistemas, se necesitará dividir el sistema en varios diagramas. No existen reglas estrictas acerca de cómo el modelo debería dividirse. A continuación se indican algunas opciones de agrupación: Todos los casos de uso iniciado por el mismo actor o grupo de actores. Los casos de uso relacionados con el mismo tipo de tareas. Los casos de uso relacionados para dar soporte a un proceso de negocio.

• • •

1.4.3. Estructurar el modelo de casos de uso Después de crear el modelo de casos de uso inicial, se procede a estructurarlo. El objetivo principal de la estructuración del modelo es eliminar redundancias, hacer que los casos de uso sean más fáciles de entender y mantener. En primer lugar, hay que analizar los casos de uso y encontrar las partes de los flujos que contengan pasos similares. Luego podemos aplicar algunos de los tres tipos de relaciones entre casos de uso: •

•

•

CIBERTEC

Incluye / Inclusión: Para representar que un caso de uso incluye el comportamiento de otro. Extend / Ampliar: Para representar que un caso de uso extiende a otro caso de uso, el cual se activa cuando se da una condición. Generalización: Este tipo de relación se da tanto entre casos de uso como entre actores.


134

1.5. Especificación suplementaria La especificación suplementaria captura todos los requisitos que no pueden ser expresados en casos de uso. Sin embargo, esto no significa que todos los requisitos funcionales están en los casos de uso y que todos los requisitos no funcionales están en la Especificación suplementaria. La Especificación de casos de uso también contiene los requisitos no funcionales, si se aplican a un solo caso de uso. La Especificación suplementaria contiene todos los requisitos funcionales genéricos que no están asociadas con ningún caso de uso específico. La tabla 10.2 ilustra qué tipo de requisito se encuentra en un documento. Tipo de requisito Funcional

No Funcional

Especificación de caso de uso Flujo básico y flujos alternativos relacionados a un caso de uso específico. Especificación no funcional relacionada a un solo caso de uso.

Especificación suplementaria Requisitos funcionales relacionados a más de un caso de uso. Requisitos no funcionales relacionados a muchos casos de uso.

Tabla 10.2 - Requisitos en documentos de Especificación Recientemente, el nombre del artefacto fue cambiado en Rational Unified Process (RUP) de "Especificación Complementaria" al plural "Especificaciones suplementarias" para reflejar el hecho de que podemos usar más de un documento para capturar requisitos suplementarios. En la pirámide, los requisitos suplementarios están en el mismo nivel que los casos uso, como se muestra en la figura 10.4.

Figura 10.4 - Requisitos suplementarios en la pirámide


CIBERTEC


135

Muchas características que se definen en el documento Visión se convierten en requisitos suplementarios. Su inclusión en la Especificación Suplementaria proporciona una oportunidad para añadir más detalles y organizar los requisitos en la sección apropiada del documento, de acuerdo a la categoría FURPS+ a la que pertenecen. Un método consiste en ir a través de todas las características, identificar cuáles no se abordaron en los casos de uso, y traducirlos a requisitos suplementarios, los cuales son descritos con más detalle y más específicos. Muy a menudo no se necesitan cambios, y podemos usar la misma formulación como en las características.

1.6. Creación de casos de prueba de casos de uso En muchos proyectos la importancia de este paso no es reconocido. A menudo, a los testers se les da una impresión de Especificación de caso de uso y, a continuación, ellos realizan las pruebas manuales. Sin embargo, si descuidamos la creación formal de los casos de prueba, se puede terminar con una cobertura pobre de un universo de pruebas ejecutando muchas pruebas duplicadas.

Figura 10.5 - Casos de prueba para verificar casos de uso Cuando tengamos todos los escenarios derivados de un caso de uso, se crean los casos de prueba. Para ello, se sigue cuatro pasos: 1. Identificar las variables para cada paso del caso de uso. 2. Identificar opciones significativamente diferentes para cada variable. 3. Combinar opciones en estudio en los casos de prueba. 4. Asignar valores a las variables. Para esta parte analizaremos el Especificación de caso de uso “Reservar Habitación”.

CIBERTEC


136

Especificación de caso de uso: Reservar Habitación 1. Breve Descripción El caso de uso permite a la recepcionista de un hotel generar una reserva de habitación(es). Además de saber en qué estado se encuentra: reservado, ocupado o disponible. 2. Actor(es) Recepcionista 3. Flujo de Eventos 3.1. Flujo Básico 1. El Caso de uso se inicia cuando la Recepcionista selecciona la opción “Reservar Habitación” en la interfaz del menú principal. 2. El sistema muestra la interfaz RESERVA con los siguientes datos: Datos del cliente: Código, nombres y apellidos. Datos de la Reserva: Fecha de llegada, fecha de salida y cantidad de días a hospedarse. Datos de las habitaciones: Número de habitación, Tipo, Costo por día, Nombre del huésped de la Habitación y una opción para Agregar Habitación. Además incluye una cuadrícula que contiene la lista de todas las habitaciones reservadas y las opciones: Buscar Cliente, Agregar Cliente, Buscar Habitación, Eliminar Habitación, Grabar Reserva y Salir. 3. La Recepcionista selecciona “Buscar Cliente”. 4. El sistema Incluye el Caso de Uso Buscar Cliente. 5. El sistema muestra los datos del cliente. 6. La recepcionista ingresa la fecha de llegada y la fecha de salida. 7. El sistema calcula la cantidad de días. 8. La recepcionista solicita “Buscar Habitación” disponible. 9. El sistema Incluye el Caso de Uso Buscar Habitación. 10. El sistema muestra la habitación seleccionada. 11. La Recepcionista ingresa el nombre de la persona para la habitación seleccionada. 12. La Recepcionista selecciona agregar Habitación 13. El sistema calcula el pago de la habitación, el subtotal, el monto total y lo agrega a la cuadricula del detalle de la reserva. 14. Si la Recepcionista quiere seleccionar otra habitación, se repite del paso 7 al 12. 15. La Recepcionista selecciona “Grabar Reserva”. 16. El sistema autogenera un número de reserva. 17. El sistema graba la reserva con su detalle y actualiza la(s) disponibilidad(es) de la(s) habitación(es) en estado “Reservado”. 18. El sistema muestra el número de reserva y el MSG “Reserva generada” con el Nro. 99999”. 19. La recepcionista cierra la interfaz RESERVA y regresa a la interfaz del menú principal del sistema y finaliza el caso de uso. 3.2. Flujos Alternativos 5.1. Cliente no existe El sistema muestra el MSG: “Cliente no existe muestra” y ofrecerá la posibilidad de registrar al nuevo cliente. 6.1. Fechas incorrectas El sistema muestra el MSG: “Fechas incorrectas” y el caso de uso continúa en el paso 5. • •

•


CIBERTEC


137

9.1. Habitaciones no disponibles El sistema muestra el MSG: “No hay habitaciones disponibles” y finaliza el caso de uso. Eliminar Habitación de Cuadrícula La recepcionista selecciona una habitación y opta por la opción eliminar, luego, el sistema elimina de la cuadrícula la habitación selecciona y el caso de uso continúa. 4. Precondiciones 1. El Recepcionista está logeado en el sistema. 2. Lista de Clientes disponibles. 3. Lista de habitaciones disponibles. 5. Poscondiciones 1. En el sistema queda registrado la reserva. 2. Las disponibilidades de las habitaciones seleccionadas se actualizan en estado “Reservadas”. 6. Puntos de Extensión 1. En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo básico “Agregar Cliente”. 7. Prototipos 7.1. Interfaz RESERVA

CIBERTEC


138

A continuación, se describe con más detalle cada paso. 1.6.1. Identificar variables para cada paso del caso de uso En primer lugar, tenemos que identificar todas las variables de entrada en los pasos que lo requieran del escenario dado. Por ejemplo, si en algún paso, el usuario introduce un ID de usuario y contraseña, hay dos variables. Una variable es el ID de usuario, y el segundo es la contraseña. La variable puede ser también una selección que el usuario puede hacer (como la selección de un vuelo procedente de una lista). A continuación, se muestra las variables que se utilizan en los pasos del flujo básico del caso de uso “Reservar Habitación”: B5. La recepcionista ingresa la fecha de llegada y la fecha de salida (paso 5). Fecha de llegada de reserva • Fecha de salida de reserva • B10. La Recepcionista ingresa el nombre de la persona para la habitación seleccionada (paso 10). Nombre del huésped de la Habitación •

1.6.2. Identificar opciones significativamente diferentes para cada variable Las opciones son "significativamente diferentes" si se pueden activar diferentes comportamientos del sistema. Las siguientes directrices describen algunos casos específicos: •

Una opción puede ser considerada significativamente diferentes si:  Se activa un flujo de procesos diferentes (por lo general un flujo alternativo). Ejemplo: Ingreso de una contraseña no válida activará el Flujo Alternativo 2. 

Se activa un mensaje de error diferente. Ejemplo 1: Si un e-mail es demasiado largo, el mensaje será "Email no debe tener más de 50 caracteres." Ejemplo 2: Si un e-mail no contiene el @ (arroba), el mensaje será “E-mail no válido."



Se produce un aspecto diferente en la interfaz de usuario. Ejemplo: Si el método de pago es una tarjeta de crédito, la pantalla deberá mostrar los campos donde el usuario puede introducir el número de tarjeta de crédito, fecha de expiración y nombre del titular.



Se produce diferentes selecciones disponibles en las listas desplegables. Ejemplo: La pantalla de registro de cliente deberá contener listas desplegables para el País y Estado/Provincia. Provincia/Estado se rellena en función del país seleccionado: para EE.UU. deberá mostrar todos los estados, para Canadá todas las provincias, y para otros países sucederá lo mismo, es decir, dependiendo del país se cargarán o provincias o estados.




Es una entrada para una regla de negocio.

CIBERTEC


139

Ejemplo: Si el pedido se realiza después de las 6 p.m., y el usuario selecciona Envío Nocturno, un mensaje deberá informar al usuario de que el libro llegará pasado mañana.

Esta regla de negocio plantea dos opciones distintas:  Envío nocturno con pedidos antes de las 6 p.m.  Envío nocturno con pedidos después de las 6 p.m.



Es una condición límite. Ejemplo: La contraseña debe tener por lo menos seis caracteres.

En este caso se debe comprobar lo siguiente:  Contraseña con cinco caracteres.  Contraseña con seis caracteres.



Si está probando números, usted puede considerar las siguientes opciones significativamente diferentes:  Número regular, razonable desde el punto de vista de la aplicación.  Cero.  Número negativo.  Un número con dos decimales.  El mayor número que se puede escribir (por ejemplo, 99999999999999 – tantos nueves como puede ingresarse en el campo de texto).

A continuación se muestra algunas opciones de valor de prueba para todas las variables del flujo básico del caso de uso “Reservar Habitación”: B5. La recepcionista ingresa la fecha de llegada y la fecha de salida. Fecha de llegada de reserva •        •

Fecha futura válida ingresada manualmente Fecha futura válida ingresada de un calendario Fecha pasada Fecha actual 30 ó 31 de Febrero Ninguna fecha Válida con una año después de la actual.

Fecha de salida de reserva     



Fecha razonable ingresada manualmente Fecha razonable ingresada de un calendario Fecha pasada Fecha igual a la de llegada 30 ó 31 de Febrero Fecha anterior a la de llegada.

B10. La recepcionista ingresa el nombre de la persona para la habitación seleccionada. Nombre del huésped de la habitación •    

CIBERTEC

Nombre regular Nombre largo (máximo número de caracteres permitido) Nombre conteniendo un apóstrofe (tal como D’ Natali) Nombre con un carácter más del permitido


140

  

Un carácter En blanco Dos palabras con un espacio entre ellos

1.6.3. Combinar opciones en estudio en los casos de prueba El paso anterior se identificaron todas las opciones significativamente diferentes para las pruebas. Ahora tenemos que combinarlas en la secuencia de pasos del caso de prueba. Una forma de hacerlo es crear una Matriz de Asignación de Casos de Prueba, tal como se ilustra en la tabla 10.3. Paso

Variable

T1

T2

T3

T4

T5

T6

Tabla 10.3 - Matriz de Asignación de Casos de Prueba Las filas de esta matriz contendrán todas las variables para todos los valores que requieran la entrada del usuario. En la primera columna se especificará el número del paso del flujo básico del caso de uso (obtenido de la Especificación de Caso de Uso), en la segunda columna se indicará el nombre de la variable, y las columnas restantes contendrán las pruebas (o tests en inglés) de los casos. Las pruebas pueden ser etiquetadas con T1 o T2 y así sucesivamente. Es necesario estimar cuántos casos de prueba cubrirá un escenario. Una estimación aproximada puede ser el mayor número de opciones significativamente diferentes para una variable. Si calcula de forma incorrecta, no hay problema porque se puede añadir o eliminar una columna, mientras se va llenando la matriz. Por lo general, de cinco a siete casos de prueba cubren escenarios típicos. Sin embargo, algunos casos específicos de aplicación requieren más casos de prueba. Tenemos que crear una matriz por escenario elegido para la prueba. La tabla 10.4 que se muestra, corresponde a la Matriz de Asignación de Casos de Prueba para el flujo básico del caso de uso “Reservar Habitación”:


CIBERTEC

142

Paso B5

Variable Fecha de llegada de reserva

T1 Válida manualmente

T2 Válida de un calendario

T3 Fecha Pasada

T4 Fecha Actual

Válida con una año después de la actual

B5

Fecha de salida de reserva

Válida manualmente

Válida de un calendario

Fecha Pasada Válida con un año después de la actual Válida con una semana después de la fecha de llegada

B10

Nombre del huésped de la Regular habitación

Con máxima longitud

Con un apóstrofe

Igual a la de llegada

T5 Fecha Incorrecta

Dos palabras

Ninguna

Válida manualmente


Fecha Incorrecta

Ninguna

Válida manualmente


Válida de un calendario Mayor longitud de la permitida

T6

Válida manualmente Un carácter

En blanco Regular

Tabla 10.5 - Matriz con las opciones combinadas para las variables del Caso de Uso “Reservar Habitación”


CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I (TEORÍA)

143

1.6.4. Asignar valores a las variables En este paso, se dividen todos los casos de prueba de la Matriz creada en el paso anterior, creando una tabla separada para cada caso de prueba. Luego, se reemplaza las opciones definidas para cada variable con valores para realizar las pruebas. Además, se agregan más filas para las acciones, tales como clic sobre un botón o selección de item de lista desplegable. Por ejemplo para el caso de prueba T1 del caso de uso “Reservar Habitación” se crea la siguiente tabla. Note que se agregaron filas que contienen acciones en los pasos B2, B7, B10, B11 y B14. Paso

Variable

T1

Resultado esperado

B2

Buscar Cliente

Buscar cliente

Datos de un cliente

B5

Fecha de llegada de reserva

01-12-2009

Aceptar

B5

Fecha de salida de reserva

05-12-2009

B7

Buscar Habitación

Buscar Habitación

Cantidad de días de hospedaje Datos de una habitación disponible

B10

Nombre del huésped de la habitación

Miguel Vásquez

Aceptar

B11

Agregar Habitación

Agregar Habitación

B14

Grabar reserva

Grabar reserva

Resultado actual

Pasa/ Falla

Comentarios

Pago de la habitación (subtotal y monto total) en la cuadrícula de detalle de reservas Número de reserva generada

Tabla 10.6 - Caso de prueba con valores

1.7. Creación de casos de prueba de la especificación suplementaria No existe un criterio unificado para crear casos de prueba para requisitos suplementarios debido a que estos requisitos son de diferente naturaleza. A continuación se presenta los métodos de creación de casos de prueba para requisitos suplementarios: Ejecutar casos de prueba seleccionados en diferentes entornos. Agregando una comprobación adicional a todos los casos de uso. Comprobando y modificando casos de uso específicos. Realizar la acción descrita en el requisito. Listas de verificación. Pruebas de caja blanca. Pruebas automatizadas.

• • • • • • •

CIBERTEC



144

1.7.1. Ejecutar casos de prueba seleccionados en diferentes entornos Este método se utiliza para los requisitos suplementarios que requieren que la aplicación trabaje en diferentes entornos (plataformas) tales como browser de Internet, sistemas operativos, etc. Ejemplo: La interfaz basada en Web será ejecutado en Internet Explorer (versión 6.0 y versiones posteriores) y Netscape (versión 6 y posteriores).

Para realizar la prueba de este requisito se selecciona un escenario de un caso de prueba y luego se ejecuta en los diferentes navegadores: Internet Explorer y luego Netscape. La siguiente figura muestra este método. El escenario seleccionado es probado en diferentes entornos, por lo tanto se tiene un caso de prueba por entorno.

Figura 10.6. Casos de prueba para verificar requisitos suplementarios a partir de un escenario. 1.7.2. Agregando una verificación adicional a todos los casos de uso Muchos requisitos describen la apariencia o el comportamiento de algunos controles en la interfaz de usuario. Algunos ejemplos: • •

•

•

•

•

CIBERTEC

En cada página un botón Siguiente sugerirá un flujo predeterminado. En las pantallas de entrada de datos del sistema deberá indicar qué campos son obligatorios colocando una estrella junto al campo. El sistema deberá mostrar un calendario pop-up cuando se introduce una fecha. Campos de entrada múltiple en una sola página se alinearán verticalmente. Cuando se muestra un cuadro de diálogo, el foco del cursor deberá situarse en el primer campo de texto en el cuadro de diálogo. Por cada entrada no válida para el usuario, el sistema mostrará un mensaje de error significativo, explicando qué formato se espera para el dato ingresado.

CARRERAS CARRERAS PROFESIONALES


•

•

•

145

Cantidades de moneda se calculan y se almacenan con una precisión de dos cifras decimales. Cada característica del sistema debe ser descrito en ayudas en línea, disponible en el menú en cada página. En las páginas que recogen los datos personales del usuario, habrá un enlace a una página describiendo la política de privacidad.

La mejor manera de incorporar las pruebas de estas características es agregando un control a todos los casos de prueba que se ha creado para casos de uso diferentes. Debido a que los casos de prueba derivados de casos de uso cubren cada posible pantalla de la aplicación, sólo puede agregar los controles pertinentes, durante su visita a cada una de las pantallas específicas. De esta forma, podemos estar seguros de que la función se verificó en todos los lugares en los que sea aplicable. En la figura 10.7 se muestra que todos los casos de prueba se actualizan con un requisito suplementario específico.

Figura 10.7. Verificación adicional a casos de prueba 1.7.3. Comprobando y modificando casos de uso específicos A pesar de que algunos requisitos se describen en las especificaciones suplementarias, están asociadas con algunos casos de uso específico. Esto puede ocurrir cuando dicha funcionalidad no está realmente relacionada con el caso de uso principal, pero desempeña un papel de apoyo o administrativos. Como ejemplo, podemos tener a los requisitos relacionados con la seguridad y acceso protegido con contraseña a algunas partes de la aplicación: •

•

CIBERTEC

Una contraseña será necesaria para acceder a las pantallas del administrador. Para presentar las ofertas, los proveedores de hotel, los proveedores de automóviles, y representantes de las aerolíneas deberán iniciar sesión en el sistema utilizando sus nombres de usuario y contraseñas.



146

La figura 10.8 muestra la actualización que se hace al caso de uso, y después se propaga a través de escenarios de y casos de prueba.

Figura 10.8 – Impacto de los requisitos suplementarios en otros tipos de requisitos relacionados 1.7.4. Realizar la acción descrita en el requisito Muy a menudo tenemos que realizar la acción descrita en el requisito debido a que en muchos casos, la tarea no requiere la creación de escenarios formales y casos de prueba. Por ejemplo: •

Un error de registro que contiene información sobre todos los errores críticos deberá ser accesible por el administrador del sistema a través de Internet, por lo que se puede comprobar de forma remota en cualquier momento.

Para probar este requisito, alguien que tenga el rol de administrador ingresará al sistema a través de Internet y comprobará si podrá acceder a un registro de errores. 1.7.5. Listas de verificación Algunos requisitos no necesitan ninguna prueba complicada, por lo que sólo puede comprobarse para ver si se han cumplido agregándolo en una lista de verificación. Por ejemplo: •

El sistema usará una base de datos de Oracle.

O se utiliza Oracle, o no - simplemente se marca en la lista de verificación. Algunos otros ejemplos de este tipo de pruebas, simplemente marcando una lista de verificación podrían incluir las siguientes: Todos los errores del sistema se registrarán y se pondrán a disposición del administrador. • Todas las transacciones (compra de tickets, asi como hacer una reserva, actualizar y anular una reserva) se registrarán y se pondrán a disposición del administrador. • El sistema usará una arquitectura JEE. •

CIBERTEC



147

Si la arquitectura requiere de un servidor de aplicaciones, se utilizará IBM WebSphere. • La Guía del administrador estará disponible en formato PDF. •

1.7.6. Pruebas de caja blanca Algunas pruebas deben hacerse con conocimiento del código fuente de la aplicación o alguna otra aplicación interna. Esto se denomina prueba de caja blanca. •

Al mostrar una lista de habitaciones disponibles, el sistema no puede perder ninguna habitación disponible para las fechas solicitadas.

Para comprobar este requisito, tenemos que acceder directamente a la base de datos y verificar el contenido de la tabla de disponibilidad de habitaciones, Luego se compara los resultados con la lista obtenida a través de nuestro sistema. Otros casos de prueba requieren comprobar si un algoritmo específico se ha aplicado correctamente: •

Para realizar la búsqueda de la lista de los vuelos de retorno deberá incluir el Algoritmo de ruta más corta de Dijkstra.

1.7.7. Pruebas automatizadas La prueba automatizada es muy útil en el control de requisitos de rendimiento y confiabilidad tales como los siguientes: El tiempo promedio de respuesta del sistema deberá ser inferior a dos segundos. • El sistema tendrá capacidad para 1000 vuelos reservados por minuto. • El sistema deberá adaptarse a 5000 usuarios concurrentes. • El sistema puede no estar disponible no más de un minuto por cada 24 horas. •

Para obtener un rendimiento y pruebas de fiabilidad, no es necesario automatizar todos los casos de prueba. Podemos seleccionar entre dos y tres casos de prueba. Vale la pena la selección de un caso de prueba que representa el escenario más utilizado y que contenga varias operaciones. Las herramientas de IBM, disponibles para realizar pruebas, son Rational Robot, Rational Test Manager, Test Manager, Rational Functional Tester y Rational performance Tester.

1.8. Diseño del sistema Los requisitos son la base para el diseño del sistema, el cual es realizado utilizando diagramas de UML. Muchas de las herramientas, tales como Rational Rose, Rational Software Architect, Rational Data Architect y Rational Software Modeler, pueden facilitar la creación de todos los diagramas necesarios. Un método es crear diagramas de interacción de los escenarios (comunicación y/o secuencia) y, al mismo tiempo, asignar funcionalidad a las

CIBERTEC



148

clases. La siguiente figura utiliza la pirámide de requisitos para representar esta actividad.

Figura 10.9 - Diseño de sistemas

CIBERTEC



149

2. Caso Práctico A continuación, se detallan las necesidades del stakeholder y las características del producto, para el caso “Sistema de Ventas y Control de Almacén”: 2.1. Necesidades del Stakeholder 1. El sistema debe permitir crear, cancelar, modificar y ver el detalle de un pedido debe estar disponible. 2. Permitir crear y consultar un pedido vía Web. 3. Consultar los pedidos por estados. 4. Poder autenticar, registrar, modificar y eliminar un cliente. 5. Contar con un catálogo de repuestos actualizado online. 6. El sistema va a permitir al seleccionar el tipo de pago ya sea al contado o crédito. 7. El sistema va a permitir siempre la opción de poder abandonar una interfaz. 8. Existir la posibilidad de imprimir la información de un pedido más la información del pago. 9. Poder registrar las incidencias de almacén, pedido e ingreso de repuestos a almacén. 10. Mostrar una lista de incidencias ordenadas por fecha e imprimirlas. 11. Crear una lista con los ítems agregados a la compra ordenados por código de repuesto. 12. Mostrar las cantidades reales de stock. 13. Comunicación con el Área de Créditos de la empresa. 14. Poder registrar los pagos vía web. 15. Mostrar lista de requerimientos según fecha de elaboración. 16. Asignar prioridad para cada orden de almacén. 17. Asignar cantidad de repuestos a comprar. 18. Permitir enviar requerimientos a uno o más proveedores. 19. Permitir ingresar la cotización de un requerimiento, adjuntar el documento de cotización y ver los detalles. 20. Permita generar una orden de Compra. 21. Mostrar un listado de las órdenes de almacén según estado y ordenadas por prioridad. 22. Permitir la búsqueda de una orden de almacén por fecha de atención. 23. Asignar un estado de atendido, no atendido, listo para envío y enviado a la orden de almacén. 24. Permitir generar, imprimir y ver el detalle de una Orden de Compra de almacén. 25. Mostrar una lista de pedidos ordenados por fecha de facturación. 26. Asignar niveles: urgente, normal o bajo a una orden de almacén. 27. Permitir asignar uno o más operarios de almacén por orden de almacén. 28. Asignar un transportista por Orden de almacén. 29. Mostrar órdenes de compra e imprimir, según estado de recepción. 30. Ver el detalle de una Orden de compra. 31. Ingresar a inventario los nuevos repuestos. 32. Generar reportes de ventas a clientes y compras a proveedores. 2.2. Características del Producto 1. El sistema va a permitir crear un pedido ingresando la información del pedido ítems del pedido y forma de pago 2. El sistema va a permitir cancelar un pedido seleccionado únicamente cuando su estado sea de Elaboración. 3. El sistema va a permitir que el usuario elimine uno o varios ítems por pedido.

CIBERTEC



150

4. El sistema va a permitir que el usuario agregue un ítem al pedido 5. El detalle del pedido va a incluir la información de pedido, ítems del pedido, forma de pago, y costos totales y subtotales. 6. El sistema va a permitir al cliente realizar un pedido a través de una dirección URL. 7. Consultar un pedido vía web va a incluir los detalles los detalles de un pedido (código, fecha, elaboración, estado) 8. El sistema va a mostrar el estado de un pedido (en elaboración, en atención, enviado) de acuerdo con la situación en la que se encuentre 9. El sistema va a permitir la búsqueda de un pedido en función al estado en que éste se encuentre. 10. El sistema va a permitir al usuario registrar un nuevo cliente indicando los campos de nombre y apellido, DNI, razón social, RUC, dirección, número, puerta, distrito, provincia, teléfono, fax, email, persona contacto, teléfono contacto. 11. Los botones de iniciar y cerrar sesión van a encontrarse disponibles desde la interfaz del ingreso de usuario. 12. El sistema va a permitir al RVRS modificar los datos de un cliente cuando sea necesario. 13. El RVRS va a poder eliminar un cliente del sistema cuando sea necesario. 14. El catálogo de repuestos va a incluir una lista de repuestos con los siguientes datos: Código de repuesto, nombre de repuesto, descripción, precio y stock. 15. El sistema va a tener una lista desplegable la cual permitirá seleccionar el tipo de pago a realizar, ya sea al contado o crédito. 16. El sistema va a contar con un botón de salida para poder abandonar cualquier interfaz. 17. El Sistema va a ser capaz de calcular con un algoritmo el subtotal, el IGV y el total del costo de un pedido. 18. El sistema va a contar en todas las interfaces con las opciones de regresar, los cuales nos permitirán volver a una interfaz previa de la actual. 19. El sistema va a permitir la búsqueda de un cliente ya sea por nombre en caso de ser persona natural o razón social si se trata de una empresa. 20. El sistema va a incluir una opción para imprimir las siguientes informaciones: De pedido y la información de pago. Detalle de requerimiento. Orden de Almacén. Orden de Compra 21. El sistema va a tener una interfaz la cual permita ingresar todo tipo de incidencias. 22. El sistema va a mostrar una lista de incidencias ordenadas según fecha de elaboración desde la antigua hasta la más reciente. 23. El sistema va a ser tener la capacidad de crear una lista según el número de ítems agregados. 24. El sistema va a tener una opción que permita el ingreso masivo de ítems. 25. El sistema va a contar con un algoritmo que permita el cálculo stock disponible. 26. El sistema va a permitir calcular y mostrar un stock mínimo. 27. El sistema tendrá una conexión con el área de créditos de la empresa para tener el resultado de la aprobación o desaprobación del Crédito solicitado. 28. El sistema contará con la opción de impresión detallada de una incidencia. 29. El sistema debe permitir registrar los pagos a través de un browser (Internet Explorer y Mozilla Firefox) ingresando los datos correspondientes obligatorios al pago. • • • •

CIBERTEC



151

30. El sistema va a ser capaz de generar reportes de compras y ventas con los datos almacenados. 31. El sistema mediante un algoritmo va a ser capaz de determinar el estado de stock de un repuesto. 32. El sistema deberá mostrar una lista de repuestos ordenada según el estado de stock (alto, normal, bajo). 33. El sistema deberá mostrar una lista con todos los requerimientos realizados ordenados según la fecha de elaboración. 34. El sistema tendrá la opción para asignar prioridad a la orden de almacén. 35. El sistema permitirá ingresar la cantidad de repuesto a comprar. 36. El sistema tendrá una opción que asigne de manera inmediata la cantidad que se debe comprar para satisfacer el stock mínimo. 37. El sistema permitirá insertar o eliminar ítems de una compra. 38. El sistema permitirá seleccionar más de un proveedor. 39. El sistema tendrá una opción para enviar cotización a proveedores. 40. El sistema permitirá manejar la selección de proveedores. 41. El sistema permitirá ingresar Fecha, numero de cotización, plazo de entrega, el código de ítem, nombre del producto , descuento , cantidad, unidades de medida, el precio unitario con y sin impuesto. 42. El sistema va a tener una opción para poder adjuntar documento. 43. El sistema tendrá la opción de ver los detalles de un requerimiento con los siguientes campos: código requerimiento, fecha de elaboración, estado, prioridad, comentarios, proveedores y cotización. 44. Se contarán con las siguientes opciones para un requerimiento: Nuevo, modificar, eliminar y ver detalle. 45. El usuario podrá genera una orden de compra a través del sistema y se indicarán los siguientes campos: Código O/C, proveedor, Fecha de elaboración, Fecha de entrega, Forma de pago y estado. 46. El sistema va a permitir mostrar una lista con las órdenes de almacén ordenadas por prioridad con los siguientes datos: Código de O/A, Cliente, Fecha de inicio, prioridad. 47. El sistema tendrá la opción filtrar que permitirá mostrar las órdenes de almacén en función a la fecha de almacén indicada por el usuario. 48. El usuario debe establecer en las órdenes de almacén el estado de atención por pedido (atendido, no atendido y listo para envío). 49. El sistema va a mostrar el detalle de una orden de almacén con los siguientes campos: Código de O/A, Cliente, Fecha de inicio y prioridad. 50. El sistema podrá generar una orden de almacén ingresando previamente los siguientes datos: Código de O/A, Cliente, Fecha de inicio, prioridad. 51. El sistema mostrará una lista de pedidos que serán ordenados de acuerdo con la fecha de facturación registrada. 52. El usuario debe poder asignar en el sistema los niveles de priorización de los pedidos: urgente, normal y bajo. 53. El sistema debe permitir asignar uno o más operarios para el despacho de una orden de almacén. 54. El sistema debe permitir asignar un transportista por orden de almacén presentando la siguiente información: nombre y foto. 55. El sistema debe mostrar una lista de órdenes de compra con los siguientes datos: código O/C, proveedor, fecha de elaboración, fecha de entrega y monto total según los estados de recepción pendiente, observada y completada. 56. El sistema tendrá la opción de ver los detalles de una orden de compra con los siguientes datos: Código O/C, proveedor, fecha de elaboración, fecha de entrega, forma de pago y estado.

CIBERTEC



152

57. El sistema debe tener la opción de ingresar a inventario un repuesto mostrando los siguientes campos: Código o/c, proveedor fecha de elaboración, fecha de entrega, monto total y estado de recepción. 58. En todos los formularios que soliciten ingresos de datos, el sistema va a indicar qué campos son obligatorios mediante la colocación de un asterisco cerca al campo. 59. Todos los formularios que muestren fechas, se van a mostrar en el formato dd / mm / aaaa. 60. El sistema va a mostrar calendarios para seleccionar una fecha, en las ventanas que lo requieran. NOTA.- Una vez identificados las necesidades de stakeholders (STR) y las características (FEAT) para el caso, podemos crear los documentos “Peticiones del stakeholder” y “Visión del Producto” respectivamente.

CIBERTEC



153

ACTIVIDADES PROPUESTAS A partir de la lista de necesidades de stakeholders para una Agencia de viajes, derive características del sistema (FEATURES ) e indique qué tipo de transformación utilizó; STRQ1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos. STRQ2: Las fechas deberán ser mostradas en formato dd/ mm / aaaa. STRQ3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios. STRQ4: La capacidad para cancelar una compra de boleto deberá estar disponible. STRQ5: El usuario será capaz de cancelar una reservación de un auto o un hotel. STRQ6: Los vuelos de ida y llegada serán ordenados por el menor número de paradas. STRQ7: El usuario será capaz de seleccionar los asientos. STRQ8: El sistema deberá tener una interfaz de lenguaje natural. STRQ9: El sistema mostrará un calendario emergente cuando se introduzca una fecha. STRQ10: El usuario deberá indicar si necesita un boleto solo de ida o ida y retorno, marcando la casilla de verificación. STRQ11: Para los vuelos de llegadas y salientes, los usuarios podrán comparar los precios de otros aeropuertos cercanos. STRQ12: A veces un Usuario ingresará un código de aeropuerto, que el sistema entenderá, pero a veces la ciudad más cercana puede reemplazarlo, entonces el Usuario no necesita saber el código del aeropuerto, y todavía no será entendida por el sistema. STRQ13: El sistema deberá tener una navegación clara. STRQ14: Si el usuario compra un boleto una vez, no será necesario repetir la misma información, como dirección o número de tarjeta de crédito. STRQ15: Pago por PayPal estará disponible. STRQ16: Las fechas se muestran en el formato dd / mm / aaaa. STRQ17: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. STRQ18: Será ordenado por precio. STRQ19: La comparación de precios de alquileres de autos de diferentes empresas se facilitará. STRQ20: Los precios de alquiler de autos deben mostrar todos los impuestos aplicables (incluido el 6% IVA del estado). STRQ21: Un calendario estará disponible para ayudar el ingreso de las fechas del vuelo. STRQ22: El sistema deberá proporcionar la posibilidad de reservar el vuelo, comprar un boleto, reservar una habitación de hotel, reservar un auto, y proporcionar información acerca de las atracciones. STRQ23: El usuario será capaz de comprar un boleto en línea, sin necesidad de llamar a al Agente de viajes. STRQ24: El sistema deberá seguir las guías de implementación prevista en la cadena de nuestras agencias de viajes. STRQ25: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. STRQ26: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad adecuado para las aplicaciones comerciales. STRQ27: El sistema será desarrollado en tres meses.

CIBERTEC



154

STRQ28: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. STRQ29: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación en base al: apellido, ciudad de destino, fecha, etc. STRQ30: El Agente de Viajes podrá cambiar los detalles de la reservación o cancelar una reservación. STRQ31: Mientras se este ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML. STRQ32: La información de contenido debe ser almacenado en un archivo de texto. STRQ33: El sistema deberá ser completamente probado solo en versiones específicas de los más populares navegadores. STRQ34: El sistema puede mostrar un mapa del aeropuerto. STRQ35: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reserva en base a apellidos y fecha. STRQ36: Todas las actividades en el Site se registran. STRQ37: Varios informes estarán disponibles. STRQ38: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación. STRQ39: Mientras se proporcione información acerca del hotel, la siguiente información se desplayará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos, las formas de pago disponibles, etc. STRQ40: Al usuario se le ofrecerá ofertas de vuelos y hoteles. STRQ41: Sólo serán aceptados pagos con tarjeta de crédito. No se aceptan cheques, ni PayPal.

Solución: No olvidar que para crear uno o varios requisitos FEAT a partir de los STRQ podemos aplicar algunas de las siguientes estrategias de transformación (derivaciones): •

• •

•

•

•

•

•

•

•

Copiar: Si no se requieren cambios, el STRQ puede ser copiado a FEAT exactamente como está. Dividir: Si el requisito no es atómico, podemos dividirlo en dos o más requisitos. Aclaración: Aclaración o explicación, se puede aplicar cuando el requisito inicial es poco claro o ambiguo. Cualificación: Logramos cualificar (cuantificar) mediante la adición de restricciones o condiciones al requisito. Puede ayudar a resolver las necesidades contradictorias. Combinación: Si los requisitos son redundantes o se superponen se pueden combinar en un solo requisito. Generalización: Si la necesidad no es abstracta, e incluye algunos detalles innecesarios, podemos aplicar la generalización. Cancelación: A veces un requisito debe ser eliminado. Esto puede suceder cuando el requisito es no viable, innecesario, o incompatible con otro requisito. Completar: Si el conjunto de requisitos es incompleto, puede ser necesario añadir requisitos en esta etapa. Corrección: Este término puede significar una nueva redacción del requisito para corregir la gramática, ortografía o puntuación; o cambiar una parte de la necesidad que no es cierta. Unificación: Los requisitos que usan un vocabulario inconsistente pueden ser unificados (estandarizados).

CIBERTEC



•

155

Adición de detalles: Si el requisito no es lo suficientemente preciso, podemos añadir más detalles. Esta técnica se utiliza a menudo para obtener requisitos verificables de los que no han sido especificados como tal.

STRQ1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos. Este requisito es redundante con STRQ11. Se pueden combinar en un solo requisito: FEAT1 El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos (para vuelo de ida y vuelo de llegada). STRQ2: Las fechas deberán ser mostradas en formato dd/mm/aaaa. Este requisito es inconsistente con STRQ 16, que pide al formato mm/dd/aaaa. El requisito STRQ2 vino por parte del Usuario francés y STRQ16 fue suministrada por el Usuario estaunidence. Los requisitos STRQ2 y STRQ16 fueron reemplazados por el siguiente requisito: FEAT2: Las fechas deberán ser mostradas de acuerdo al formato cargado en la configuración del navegador Web. STRQ3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios. En algún momento se tomará la decisión de aquellos campos obligatorios, que serán indicados como campos requeridos. Supongamos que queremos hacerlo ahora, entonces aplicamos la explicación para crear el requisito: FEAT3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios de ingresar colocando un asterisco cerca al campo. STRQ4: La capacidad para cancelar una compra de boleto deberá estar disponible. Por consistencia, es mejor usar construcciones estándares en requisitos, tales como "deberá" en vez de "debería". Usar diferentes palabras como "será", "hará ", "debería", y "podría" pueden ser erróneamente interpretados en los diferentes niveles de necesidad. (Por ejemplo, "se" puede sonar más fuerte que "deberá", y "se" puede sonar más fuerte que "debería". Es necesario una aclaración en cuanto a quién será capaz de cancelar la compra de los boletos (usuario, cliente representante o administrador) y en qué etapa del proceso es requerido: FEAT4: El usuario será capaz de cancelar la compra de un boleto en cualquier momento antes de la confirmación final de la compra. STRQ5: El usuario será capaz de cancelar una reservación de un auto o un hotel. El analista de sistemas decide si un requisito específico es atómico. En este caso, decidió que la cancelación de una reservación de un auto o de una habitación de hotel puede ser considerado el mismo requisito, entonces no hay la necesidad de dividir esto: FEAT5: El usuario será capaz de cancelar una reservación de un auto o un hotel. STRQ6: Los vuelos de ida y llegada serán ordenados por el menor número de paradas. Esta terminología es inconsistente con el STRQ11. El mismo concepto es llamado “Vuelo de retorno” en STRQ6 y “Vuelo de llegada” en STRQ11. Asumiremos que

CIBERTEC



156

después de consultar hemos decidido usar el término “Vuelo de retorno”. Necesitamos retornar al FEAT1 para cambiar por consistencia: FEAT1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos (para vuelo de ida y vuelo de retorno). Porque tenemos que cambiar el FEAT1 para consistenciarlo con STRQ6, reescribiremos el STRQ6 en FEAT6: FEAT6: Los vuelos de ida y retorno deben ser ordenados por el menor número de paradas. Sin embargo, contradice al STRQ18, porque que los vuelos sean ordenados por precio. Podemos acomodar ambos requisitos en una característica: FEAT6: El usuario será capaz de seleccionar si los vuelos son ordenados por el menos número de paradas o por precio. Como usted puede ver, derivar características es un proceso iterativo, y algunos requisitos necesitan ser cambiados en poco tiempo mientras son consistentes y no redundantes. Como usted puede observar, derivar características es un proceso iterativo , y algunos requisitos, necesitan ser cambiados en poco tiempo, mientras sean consistentes y no redundantes .

STRQ7: El usuario será capaz de seleccionar los asientos. Para la unificación, cambiamos la "voluntad" a "se." Por la obligación de ser completamente independiente, tenemos que añadir alguna explicación: FEAT7: Durante la compra de un boleto de avión, el usuario será capaz de seleccionar los asientos. STRQ8: El sistema deberá tener una interfaz de lenguaje natural. A primera vista, este requisito es correcto. Sin embargo, después de analizar el alcance de las limitaciones del sistema y el tiempo, fue obvio que este requisito no era realista (factible). Es contradictorio con STRQ27, que pide que el sistema se desarrolle en tres meses. – Implementando una interfaz de lenguaje natural se tardaría más de tres meses. Este requisito se cancela, y el usuario que proporciona este requisito es notificado de la cancelación. STRQ9: El sistema mostrará un calendario emergente cuando se introduzca una fecha. Esto se superpone con STRQ21, que pide un calendario cuando la fecha del vuelo se ingrese. Debido al STRQ9 que es más genérico (menciona una fecha, que incluye una estancia en el hotel fecha o un alquiler de la fecha de coches), volveremos a escribir STRQ9 y cancelar STRQ21. Como aclaración, podemos explicar una lista de todas las fechas: FEAT8: El sistema mostrará un calendario emergente en cualquier fecha que se ingrese, tales como una fecha de vuelo, fechas de permanencia en el hotel, o la fecha del alquiler de un auto). STRQ10: El usuario deberá indicar si necesita un boleto solo de ida o ida y retorno, marcando la casilla de verificación. Este requisito contiene el diseño innecesario. Detalles, como si se utiliza un botón o casilla de verificación, debe dejarse en manos del diseñador de la pantalla. En este caso, un botón de opción puede ser más apropiado porque las opciones son excluyentes.

CIBERTEC



157

FEAT9: El usuario tendrá la oportunidad de indicar si necesita solo un boleto de ida o ida y retorno. STRQ11: Para los vuelos de llegadas y salientes, los usuarios podrán comparar los precios de otros aeropuertos cercanos. Esta solicitud se combina con FEAT1, por lo que puede ser cancelada. STRQ12: A veces un Usuario ingresará un código de aeropuerto, que el sistema entenderá, pero a veces la ciudad más cercana puede reemplazarlo, entonces el Usuario no necesita saber el código del aeropuerto, y todavía no será entendida por el sistema. Esta frase es complicada y poco clara. Podemos sustituirlo por uno más simple: FEAT10: El sistema deberá identificar el aeropuerto en base al código del aeropuerto o al nombre de la ciudad. STRQ13: El sistema deberá tener una navegación clara. Este requisito es vago y no lo suficientemente preciso, sin embargo puede ser probable. Dos características concretas se derivan: FEAT11: Separación por pestañas disponibles para la funcionalidad principal. FEAT12: En cada página un botón “Siguiente” sugiere el flujo pre determinado. STRQ14: Si el usuario compra un boleto una vez, no será necesario repetir la misma información, como dirección o número de tarjeta de crédito. En esta petición se aclara por adición "durante las transacciones futuras": FEAT13: Si el usuario compra un boleto de una vez, no será necesario repetir la misma información (tales como dirección o número de tarjeta de crédito) durante las transacciones futuras. STRQ15: Pago por PayPal estará disponible. Este requisito es contradictorio con STRQ41, que establece que PayPal no puede ser disponible. En este caso, por alguna razón el vendedor no puede proporcionar este servicio, es necesario anular el requisito del usuario. STRQ16: Las fechas se muestran en el formato dd / mm / aaaa. Este requisito fue incluido en FEAT2. STRQ17: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. No hay nada malo con esto, así que simplemente es re-escribir: FEAT14: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. STRQ18: Será ordenado por precio. La palabra "Será" se refiere al requisito anterior. Sin embargo, si el orden de los requisitos cambia, este requisito no será comprensible. Para ser independiente, el requisito tendría que ser redactado como sigue: La lista de los vuelos disponibles deberá ser ordenada por precios. Sin embargo, ya se ha incluido este requisito en FEAT6.

CIBERTEC



158

STRQ19: La comparación de precios de alquileres de autos de diferentes empresas se facilitará. Este requisito está bien. Sólo tenemos que eliminar la voz pasiva: FEAT15: El sistema deberá proporcionar la comparación de los precios de alquiler de autos de diferentes empresas. STRQ20: Los precios de alquiler de autos deben mostrar todos los impuestos aplicables (incluido el 6% IVA del estado). El impuesto varía según el estado, por lo que el % cifra es incorrecta. Podemos eliminar las palabras entre paréntesis, dejando el cálculo de los impuestos para los diseñadores: FEAT16: Los precios del alquiler de autos deben mostrar todos las Impuestos aplicables. STRQ21: Un calendario estará disponible para ayudar el ingreso de las fechas del vuelo. Este requisito se incorporó en FEAT8. STRQ22: El sistema deberá proporcionar la posibilidad de reservar el vuelo, compra un boleto, reservar una habitación de hotel, reservar un auto y proporcionar información acerca de las atracciones. Este requisito es una combinación de cinco requisitos atómicos, lo que hace trazabilidad muy difícil. Este requisito compuesto se dividirá en cinco requisitos atómicos: FEAT17: El sistema deberá proporcionar la oportunidad de reservar el vuelo. FEAT18: El sistema deberá proporcionar la oportunidad de comprar un boleto de avión. FEAT19: El sistema deberá proporcionar la oportunidad de reservar una habitación de hotel. FEAT20: El sistema deberá proporcionar la oportunidad de reservar un auto. FEAT21: El sistema deberá proporcionar información acerca las atracciones en lugares específicos. STRQ23: El usuario será capaz de comprar un boleto en línea, sin necesidad de llamar a al Agente de viajes. No hay nada malo aquí, así que podemos copiar el requisito. FEAT22: El usuario será el capaz de comprar un boleto en línea, sin necesidad de llamar al Agente de viajes. STRQ24: El sistema deberá seguir las guías de implementación prevista en la cadena de nuestras agencias de viajes. Este requisito no es claro, al menos que otro documento se adjunte, describiendo las directrices de implementación. O todas las pautas pueden ser listadas de forma explicita. Por ejemplo: FEAT23: El sistema utilizará la arquitectura JEE. FEAT24: Si la arquitectura requiere de un servidor de aplicaciones IBM WebSphere deberá utilizar. FEAT25: Si el sistema requiere una base de datos. Oracle deberá utilizar. STRQ25: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los

CIBERTEC



159

proveedores de automóviles, y los representantes de líneas aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. No hay nada malo aquí, así que podemos copiar el requisito. FEAT26: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. STRQ26: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad adecuado para las aplicaciones comerciales. Este requisito no es lo suficientemente precisa para ser probado. En algún momento tenemos que reemplazar con los requisitos detallados en cuanto a fiabilidad. Podemos hacer esto ahora, mientras creamos las características o podemos esperar hasta que creemos las especificaciones suplementarias de las características. Por ahora, mantenemos la exigencia como es: FEAT27: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad apropiado para las aplicaciones comerciales. STRQ27: El sistema será desarrollado en tres meses. Podemos añadir una explicación acerca de cuándo comienza este cálculo del tiempo. FEAT28: El sistema deberá ser desarrollado tres meses a partir de la fecha en que el cliente firme los Casos de Uso y las especificaciones suplementarias. STRQ28: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. Podemos copiar este requisito, porque no hay nada que corregir. FEAT29: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. STRQ29: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación sobre la base del apellido, ciudad de destino, fecha, etc. El "etc" no es lo suficientemente preciso. Después de confirmar con el solicitante de este requerimiento que no se requieren otros criterios de búsqueda, "etc" fue eliminado. FEAT30: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación sobre la base de siguiente: apellido, ciudad de destino y fecha. STRQ30: El Agente de Viajes podrá cambiar los detalles de la reservación o cancelar una reservación. Debido a que este requisito no es atómico, podemos dividirlo en dos: FEAT31: El Agente de Viajes será podrá cambiar los detalles de una reservación. FEAT32: El Agente de Viajes podrá de cancelar una reservación. STRQ31: Mientras se esté ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML. Este requisito está bien, por lo que solo se copia: FEAT33: Mientras se esté ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML.

CIBERTEC



160

STRQ32: La información de contenido debe ser almacenada en un archivo de texto. Cómo se almacenará la información, debe ser transparente para el usuario, y será decisición del diseñador o arquitecto. Este requisito puede ser cancelado. Esta sugerencia, sin embargo, puede ser pasada a consideración en el diseño. STRQ33: El sistema deberá ser completamente probado solo en versiones específicas de los más populares navegadores. Después de transmitir al cliente que no es realista poner a prueba el sistema en todos los navegadores disponibles, el cliente estuvo de acuerdo con limitar el requerimiento de las pruebas en los navegadores Internet Explorer y Netscape. FEAT34: El sistema deberá ser completamente probado en los siguientes navegadores: Internet Explorer y Netscape. STRQ34: El sistema puede mostrar un mapa del aeropuerto. Este requisito llegó del desarrollador, que no es un cliente ni un usuario. Después de comprobar con el cliente, se confirmó que este requerimiento es innecesario, por lo que se canceló. STRQ35: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reserva en base con apellidos y fecha. Debido a STRQ35 es un subconjunto de STRQ29, que se incorporó en FEAT30, cancelamos el STRQ35. STRQ36: Todas las actividades en el Site se registran. Agregamos algunos detalles y explicación: FEAT35: Todas las transacciones y los errores deberán ser registrados y estarán disponibles para el Administrador. STRQ37: Varios informes estarán disponibles. Este requisito es impreciso. Después de entrevistas adicionales, los detalles fueron añadidos: FEAT36: Los siguientes informes estarán disponibles para el Administrador: Una lista de todos los boletos de avión comprados en un período de tiempo determinado. Una lista de todas las reservas de autos en un período de tiempo determinado. Una lista de todas las reservas de habitaciones de hotel en un periodo de tiempo determinado. STRQ38: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación. Este requisito está bien, por lo que sólo se copia: FEAT37: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación. STRQ39: Mientras se proporcione información acerca del hotel, la siguiente información se mostrará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos, las formas de pago disponibles, etc.

CIBERTEC



161

El "etc" se elimina: FEAT38: Mientras se proporcione información acerca del hotel, la siguiente información se mostrará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos y las formas de pago disponibles. STRQ40: Al usuario se le ofrecerá ofertas de vuelos y hoteles. Alguna explicación se adiciona: FEAT39: Al usuario se le ofrecerá paquetes de ofertas que constan de vuelos y alojamiento en hoteles. STRQ41: Solo serán aceptados pagos con tarjeta de crédito. No se aceptan cheques, ni PayPal. Algunos cambios en la redacción para aclarar fueron aplicados: FEAT40: Durante el pago del boleto de avión, sólo se aceptará con tarjeta de crédito. Cheques y PayPal no serán aceptados. NOTA.- Una vez identificados las necesidades de stakeholders (STR) y las características (FEAT) para una Agencia de viajes, podemos crear los documentos “Peticiones del stakeholder” y “Visión del Producto” respectivamente.

CIBERTEC



162

Resumen 

En RUP, una descripción simplificada del proceso de gestión de requisitos contiene los siguientes pasos: Establecimiento de un plan de gestión de requisitos Captura de requisitos Desarrollo del documento Visión Creación de casos de uso Especificación suplementaria Creación de casos de prueba de casos de uso Creación de casos de prueba de la especificación suplementaria Diseño del sistema • • • • • • • •

 Los

documentos que se utilizan comúnmente en la gestión de requisitos son los siguientes: 1. Plan de gestión de requisitos 2. Peticiones de stakeholders 3. Visión 4. Glosario de términos 5. Especificación de caso de uso 6. Especificación de requisitos suplementarios 7. Especificación de requisitos del software 8. Especificación de caso de prueba.



Cada paso de la gestión de requisitos, a partir del segundo, navega a través de la pirámide de requisitos de arriba hacia abajo y de izquierda a derecha.



Los requisitos son más específicos en los niveles inferiores de la pirámide



Si desea saber más acerca de estos temas, puede consultar el siguiente libro:  “REQUIREMENTS

MANAGEMENT USING IBM RATIONAL REQUISITE PRO” de Peter Zielczynski. Del capítulo 3 al 11 se describe con más detalle cada uno de los pasos de la gestión de requisitos según RUP.

CIBERTEC



163

ESQUEMA DEL TEMA 8: GESTIÓN DE REQUISITOS EN RUP 1. Visión general de la gestión de requisitos en RUP La descripción simplificada del proceso de gestión de requisitos contiene los siguientes pasos: Establecimiento de un plan de gestión de requisitos Captura de requisitos Desarrollo del documento Visión Creación de casos de uso Especificación suplementaria Creación de casos de prueba de casos de uso Creación de casos de prueba de la especificación suplementaria Diseño del sistema. 1.1. Establecimiento de un plan de gestión de requisitos Se toma en cuenta los siguientes aspectos: Todas las decisiones sobre el plan se documentan. Un proyecto de RequisitePro se crea sobre la base al PGR. El PGR es creado a partir de una plantilla de RequisitePro. El documento de Microsoft Word con el PGR se importa en RequisitePro. 1.2. Captura de requisitos Para capturar las necesidades de los stakeholders se utilizan una o más técnicas que se citan a continuación: Entrevistas Cuestionarios Workshops (talleres) Storyboards (guiones gráficos) Role playing (Juego de roles) Sesiones de lluvias de ideas (brainstorming) Prototipos Casos de uso Análisis de documentos. 1.3. Desarrollo del documento Visión Documento que puede ser utilizado como contrato entre los desarrolladores y clientes para los requisitos técnicos. Los propósitos del documento son los siguientes: Definir los límites del sistema Identificar restricciones impuestas en el sistema Conseguir acuerdos con los clientes sobre el alcance del proyecto Crear una base sobre la cual se definen los documentos: especificaciones de casos de uso y especificaciones de requisitos suplementarios. Las características se derivan de las necesidades de los stakeholders. 1.4. Creación de casos de uso Los requisitos funcionales son descritos en forma de casos de uso. Se derivan de las características del sistema y a partir de ellos se derivan sus escenarios. El propósito de los casos de uso es facilitar acuerdos entre desarrolladores, clientes y usuarios acerca de lo que el sistema debe hacer. Las características de casos de uso son las siguientes: Son iniciados por un actor. Modelan una interacción entre el actor y el sistema. Describen una secuencia de acciones. Capturan requisitos funcionales. Proporcionan algún valor a un actor. Representan un completo y significativo flujo de eventos. • • • • • • • •

• • • •

• • • • • • • • •

• • • •

• • • • • •

CIBERTEC



164

1.5. Especificación suplementaria Captura todos los requisitos que no pueden ser expresados en casos de uso, llamados requisitos no funcionales. Su inclusión en la Especificación Suplementaria proporciona una oportunidad para añadir más detalles y organizar los requisitos de acuerdo a la categoría FURPS+ a la que pertenecen. 1.6. Creación de casos de prueba de casos de uso Cuando se tienen todos los escenarios de un caso de uso, se crean los casos de prueba. Para ello, se siguen cuatro pasos: Identificar las variables para cada paso del caso de uso. Identificar opciones significativamente diferentes para cada variable. Combinar opciones en estudio en los casos de prueba. Asignar valores a las variables. 1.7. Creación de casos de prueba de la especificación suplementaria No existe un criterio unificado para crear casos de prueba. Existen métodos para la creación de casos de prueba para requisitos suplementarios: Ejecutar casos de prueba seleccionados en diferentes entornos. Agregando una comprobación adicional a todos los casos de uso. Comprobando y modificando casos de uso específicos. Realizar la acción descrita en el requisito. Listas de verificación. Pruebas de caja blanca. Pruebas automatizadas. 1.8. Diseño del sistema Los requisitos son la base para el diseño del sistema, el cual es realizado utilizando diagramas de UML. Un método es crear diagramas de interacción de los escenarios (comunicación y/o secuencia) y, al mismo tiempo, asignar funcionalidad a las clases. • • • •

• • • • • • •

CIBERTEC



165


2 TEMA

9 DOCUMENTOS - ATRIBUTOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO 1. Documentos de la Ingeniería de Requisitos. 2. Atributos de los tipos de requisitos.

ACTIVIDADES PROPUESTAS 1. Los alumnos rinden la Evaluación Continua Nº 3. 2. Los alumnos reconocen los documentos propuestos por el profesor. 3. Los alumnos asignan algunos atributos a los tipos de requisitos.

CIBERTEC



166

1. DOCUMENTOS DE LA INGENIERIA DE REQUISITOS Según el plan de gestión de los requisitos, se definen los requisitos de la pirámide y cada paso tiene su correspondiente documento a crear. En la tabla 11.1 se muestran los documentos que debemos documentar. Paso 1

Descripción

___________

Plan de Gestión de Requisitos

Captura de requisitos

Necesidades de stakeholders

Peticiones Stakeholders

Desarrollo del documento Visión

Características

Documento Visión, Glosario de Términos.

Creación de casos de uso

Casos de uso y escenarios

Especificación Requisitos Software. Especificación Caso de Uso

de de


Requisitos suplementarios

Especificación Requisitos Suplementarios

de

Creación de casos de prueba de casos de uso

Casos de prueba

Plan de casos de prueba, Especificación de Caso de Prueba.

Creación de casos de prueba de la especificación suplementaria

Casos de prueba

Especificación Caso de Prueba.

4

5

6

7

Documentos

Establecimiento de un plan de gestión de requisitos

2 3

Tipo de requisito

de

de

de

Tabla 11.1 - Documentos de la gestión de requisitos A continuación veremos algunos ejemplos de los documentos a crear en la gestión de requisitos. En el Anexo 1 se tienen todas las plantillas de los documentos con la explicación del contenido de cada uno de sus párrafos.

1. 2. 3. 4. 5. 6.

Plan de Gestión de Requisitos Petición del Stakeholder Documento Visión Especificación de Requisitos de Software Especificación de Caso de Uso Especificación de Requisitos Suplementarios. 7. Especificación de casos de prueba.

CIBERTEC



167

Petición de los Stakeholders 1. Introducción El documento contiene los requerimientos del Sistema SVGA, los cuales han sido obtenidos según las exigencias y alcance de los Stakeholders interesados en el desarrollo del sistema. 2. Perfil del Stakeholder Nombre: Juan Loarte Pérez Compañía: CIMAQ S.A. Cargo: Gerente General • • •

3. Lista de Requerimientos 1. El sistema debe permitir crear, cancelar, modificar y ver el detalle de un pedido debe estar disponible. 2. Permitir crear y consultar un pedido vía Web. 3. Consultar los pedidos por estados. 4. Poder autenticar, registrar, modificar y eliminar un cliente. 5. Contar con un catálogo de repuestos actualizado online. 6. El sistema va a permitir al seleccionar el tipo de pago ya sea al contado o crédito. 7. El sistema va a permitir siempre la opción de poder abandonar una interfaz. 8. Existir la posibilidad de imprimir la información de un pedido más la información del pago. 9. Poder registrar las incidencias de almacén, pedido e ingreso de repuestos a almacén. 10. Mostrar una lista de incidencias ordenadas por fecha e imprimirlas. 11. Crear una lista con los ítems agregados a la compra ordenados por código de repuesto. 12. Mostrar las cantidades reales de stock. 13. Comunicación con el Área de Créditos de la empresa. 14. Poder registrar los pagos vía Web. 15. Mostrar lista de requerimientos según fecha de elaboración. 16. Asignar prioridad para cada orden de almacén. 17. Asignar cantidad de repuestos a comprar. 18. Permitir enviar requerimientos a uno o más proveedores. 19. Permitir ingresar la cotización de un requerimiento, adjuntar el documento de cotización y ver los detalles. 20. Permita generar una orden de Compra. 21. Mostrar un listado de las órdenes de almacén según estado y ordenadas por prioridad. 22. Permitir la búsqueda de una orden de almacén por fecha de atención. 23. Asignar un estado de atendido, no atendido, listo para envío y enviado a la orden de almacén. 24. Permitir generar, imprimir y ver el detalle de una Orden de Compra de almacén. 25. Mostrar una lista de pedidos ordenados por fecha de facturación. 26. Asignar niveles: urgente, normal o bajo a una orden de almacén. 27. Permitir asignar uno o más operarios de almacén por orden de almacén. 28. Asignar un transportista por Orden de almacén. 29. Mostrar órdenes de compra e imprimir, según estado de recepción. 30. Ver el detalle de una Orden de compra. 31. Ingresar a inventario los nuevos repuestos. 32. Generar reportes de ventas a clientes y compras a proveedores.

CIBERTEC



168

Especificación de Requisitos de Software 1. Introducción 1.1. Propósito El presente documento tiene como propósito definir las especificaciones funcionales, no funcionales y del sistema para la implementación de una aplicación web que permitirá gestionar de manera adecuada tanto el proceso de ventas y entrega de repuestos, como el de abastecimiento de almacén también. Para lo cual se diseñara un software el cual será utilizado por los diferentes trabajadores y clientes de CIMAQ. 1.2. Alcance El documento Especificaciones de Requerimientos de Software nos permitirá diseñar, desarrollar e implantar del sistema SVGA (Sistema de Ventas y Gestión de Almacén). El SVGA será una aplicación que funcionará en un entorno web que permitirá gestionar de manera adecuada el proceso de ventas, entrega de repuestos y de abastecimiento de almacén de la empresa CIIMAQ. Ésta aplicación dará apoyo a los siguientes procesos: Venta de repuestos Entrega de repuestos y Abastecimiento de almacén. 1.3. Referencias Las referencias al presente documento son: Documento Visión Especificación de Casos de Uso y Especificación de Requerimientos Suplementarios. 1.4. Resumen Ejecutivo La problemática actual es la utilización de los recursos humanos en el área de almacén que se ve afectada negativamente por la falta de control de tiempos empleados y priorización en la entrega de productos. Además, existe una deficiente sincronización entre la elaboración de pedidos del área de ventas y la gestión de existencias e inventarios del área de almacén. Es así que el presente proyecto va a referir el nombre del siguiente sistema: “Sistema de Ventas y Gestión de Almacén” – SVGA El contenido referente al proyecto va a incluir los siguientes capítulos: Estudio de factibilidad. Modelado del Negocio Captura de Requerimientos Análisis Diseño Implementación Administración del Proyecto. Para el desarrollo adecuado del proyecto nos basamos en las diferentes herramientas que ofrece IBM Rational, tales como: IBM Rational RequisitePro, IBM Rational Software Architect, InfoSphere Data Architect; así también como las herramientas del Office. Todos estos mecanismos serán utilizados basándonos en la metodología RUP. • • •

• • •

• • • • • • •

2. Requerimientos Funcionales El sistema debe cumplir con los siguientes requerimientos: 2.1. Asociados a los Casos de Uso del sistema 1. Registrar pedido online 2. Registrar pedido 3. Registarar requerimiento

CIBERTEC



169

4. Generar Orden de Almacén 5. Ingresar repuestos a inventario 6. Cotizar requerimiento 7. Atender Orden de Almacén 8. Registrar pago 9. Mantaner cliente 10. Asignar proveedores 11. Agregar Item a requerimiento 12. Agregar Item a pedido 13. Mantener usuario 14. Registrar incidencia de pedido 15. Registrar incidencia de Ingreso 16. Registrar incidencia de Atención 17. Buscar cliente 18. Generar reporte de almacén 19. Consultar incidencia 20. Generar reporte de compras 21. Generar reporte de ventas 22. Consultar pedido. 2.2. Asociados a aspectos generales 1. Obligar al usuario a que el cambio de contraseña sea cada 120 días. 2. Incluir un mecanismo que permita su actualización automática sin la intervención del usuario. 3. Mantener un registro de los errores (logs). Para cada error el sistema debe registrar: el código del error, una descripción del error, la fecha y la hora del error. 4. Permitir que se puedan adjuntar documentos al sistema. 5. Permitir que un usuario sea capaz de imprimir algún reporte. 6. Incluir elementos interactivos, como por ejemplo calendarios que van a aparecer en ventanas emergentes. 7. Permitir que el sistema pueda ser utilizado en las distintas variantes de browser que ofrece el internet. 8. Mantener un performance estable, para que el usuario no tenga problemas para desenvolverse en el sistema. 3. Requerimientos No Funcionales 3.1. Usabilidad En todos los formularios que soliciten ingresos de datos, el sistema va a indicar qué campos son obligatorios mediante la colocación de un asterisco cerca al campo. Todos los formularios que muestren fechas, se van a mostrar en el formato dd/mm/aaaa. El sistema debe mostrar calendarios para seleccionar una fecha, en las ventanas que lo requieran. El sistema va a contar con un botón de salida para poder abandonar cualquier interfaz. El sistema va a tener una opción que permita el ingreso masivo de items. El sistema va a tener una conexión con el área de créditos de la empresa para tener el resultado de la aprobación o desaprobación del Crédito solicitado. El sistema va a permitir registrar los pagos a través de un browser ya sea Internet Explorer o Mozilla Firefox (sin importar las versiones). Los siguientes campos: código de O/A, cliente, fecha de inicio, prioridad; van a ser mostrados ordenadamente en una lista de ordenes de almacén. •

•

•

•

• •

•

•

CIBERTEC



170

En todas las interfaces se encontrarán disponibles los botones de regresar los cuales permitirán volver a una interfaz previa de la actual. El sistema va a tener una opción para poder adjuntar un documento En el caso del ingreso de datos, los botones de limpiar se encontrarán presentes con el objetivo de permitir reanudar el ingreso de información. Las fechas deberán ser mostradas de acuerdo al formato cargado en la configuración del navegador Web. En el caso de la búsqueda e ingreso de datos, van a encontrarse disponibles mensajes de ayuda los cuales le brinden al usuario una guía para la toma de decisiones. 3.2. Confiabilidad 3.2.1. Tolerancia de Error El tiempo medio de reparación dependerá de la complejidad de los ajustes necesarios para lo corrección de errores, dicha demora se verá disminuida gracias al registro de mensajes de error, que facilitará la identificación y posible solución a la falla presentada. 3.2.2. Recuperabilidad El tiempo medio de reparación dependerá de la complejidad de los ajustes necesarios para lo corrección de errores, dicha demora se verá disminuida gracias al registro de mensajes de error, que facilitará la identificación y posible solución a la falla presentada. 3.2.3. Disponibilidad El sistema SVGA tendrá una disponibilidad de uso del 41.6% del día (10 horas), es decir, el horario laborable del personal de almacén (8 horas) más 2 horas, en caso que se deseen revisar reportes de las actividades realizadas en el transcurso del día. 3.2.4. Precisión Las cantidades actuales van a ser calculados y almacenados con una precisión de 2 decimales. 3.2.5. Seguridad El password va a ser requerido por el administrador de interfaces. 3.3. Rendimiento El rendimiento del Sistema de Ventas y Gestión de Almacén SVGA es estimado desde el inicio del proyecto de desarrollo y es ampliado durante su construcción; no obstante, se verá influenciado de acuerdo con la carga de trabajo. 3.3.1. Tiempo de Respuesta El tiempo estimado de respuesta por actividad, de la aplicación web, no debe ser mayor a 5 segundos. 3.3.2. Tiempo de Recuperación El tiempo estimado de acceso a la aplicación web no debe ser mayor a 5 segundos. 3.3.3. Tiempo de Encendido y Apagado El tiempo estimado de encendido y apagado del software será de 5 segundos. 3.3.4. Capacidad El sistema va a alojar a 700 usuarios actualmente. 3.3.5. Utilización de Recursos El sistema va a almacenar en la base de datos no más de un millón de transacciones. Si la base de datos crece más del límite, las antiguas transacciones serán eliminadas y suplantados desde la base de datos operacional. •

• •

•

•

CIBERTEC



171

3.4. Soporte y Mantenimiento 3.4.1. Capacidad de Prueba La interfaz de Usuario no va a contener ningún otro componente que impida el uso de la herramienta IBM Rational Functional Tester. 3.4.2. Adaptabilidad El tiempo de implementación de otras herramientas requeridas para el adecuado funcionamiento del sistema no va a durar más de un día. 3.4.3. Mantenimiento El SVGA va a contar con errores programados que serán mostrados y registrados para hacer uso de éstos en una futura solución al problema. 3.4.4. Compatibilidad Después que SVGA esté en ejecución, las versiones siguientes van a ser compatibles con sus predecesoras. Todas las transacciones ingresadas previamente en versiones previas van a ser disponibles en las nuevas versiones. 3.4.5. Capacidad de Actualización El sistema va a ser provisto de actualizaciones que pueden contener asistencia técnica que contribuya con su operatividad. 3.4.6. Capacidad de Instalación La instalación del sistema no va a requerir alguna otra instalación de alguna estación de trabajo. 3.4.7. Escalabilidad Después de 6 meses de trabajo, el sistema va a ser capaz de alojar un adicional de 500 usuarios más. 3.4.8. Portabilidad Cambiar la base de datos del sistema en el futuro, no va a requerir alguna reescritura de una aplicación lógica. 3.4.9. Capacidad de ser Reusable Las funcionalidades principales del sistema van a ser encapsulados en componentes que van a ser reusados un una aplicación cliente-servidor. 3.4.10. Variabilidad La variabilidad del sistema no va a contener herramientas internas o externas las cuales cambien la funcionalidad del software. 3.4.11. Capacidad de ser Analizado El sistema va a contener un estándar apropiado para el fácil análisis por parte del usuario que lo requiera. 3.4.12. Capacidad de ser Localizado El sistema va a estar disponible en español. 3.5. Consideraciones de diseño e implementación El sistema utilizará la arquitectura JEE. El sistema será desarrollado en Eclipse Helios para su programación y Dreamweaver CS5 para su diseño. Se utilizará IBM WebSphere como servidor de aplicaciones. Se utilizará SQL Server como base de datos, bajo la plataforma Windows Server 2003 de 64 bits. El sistema funciona bajo la plataforma Windows XP Professional 32 bits. 3.6. Documentación de Usuario en Línea y Sistema de Ayuda El SVGA contará con un espacio web en el cual el usuario podrá encontrar ayuda en línea; además, tendrá disponible un campo en el que pueda dejar sugerencias y reportar cualquier tipo de inconveniente. 3.7. Interfaces 3.7.1. Interfaces de Usuario Las interfaces que serán implementadas por el software, serán de fácil uso y entendimiento para el usuario; además, presentará un entorno • •

• •

•

CIBERTEC



172

amigable que ofrece una serie de ventajas por su sencillez de operación, que hará que se sientan a gusto utilizando la herramienta. 3.7.2. Interfaces de Hardware El sistema será implementado sobre el servidor netfinity IBM con el que ya cuenta CIMAQ S.A., y será instalado en los módulos que serán ubicados en almacén. 3.7.3. Interfaces de Software EL sistema será desarrollado en Eclipse Helios y diseñado en Dream weaver CS4, y será funcional bajo la plataforma Windows XP Professional 32bits; el servidor de base de datos será SQL Server 2005, bajo la plataforma Windows Server 2003 de 64bits. 3.7.4. Interfaces de Comunicaciones Se hará uso de una Conexión de área local (LAN), utilizando para la comunicación, cables de internet UTP con conectores RJ45. 3.8. Requerimientos de Licencia El sistema será implementado sobre los recursos informáticos que ya existen en CIMAQ S.A., por lo tanto, no será necesario adquirir nuevas licencias. 3.9. Requerimientos legales, Copyright y Otros El SVGA formará parte de los módulos o sistemas ya existentes dentro de las instalaciones de CIMAQ S.A. 3.10. Aplicación de Estándares Los estándares aplicables para la realización del sistema SVGA serán los siguientes: 3.10.1. Hardware Estandarizado al actual que está siendo usado en las instalaciones de CIMAQ S.A. 3.10.2. Software Estandarizado aplicando patrones de diseño (DAO, MVC), interfaces gráficas, web 2.0. 3.10.3. Redes Estandarizado siguiendo el modelo OSI.

CIBERTEC



173

Especificación de caso de uso: Generar Orden de Almacén 1. Breve descripción El caso de uso permite al Coordinador de Almacén generar una orden de almacén a partir de un pedido facturado. 2. Actores Coordinador de almacén (CO) 3. Flujo de eventos 3.1. Flujo Básico 1. El caso de uso inicia cuando el CO solicita “Generar Orden Almacén” en el menú de Supervisión de Almacén. 2. El sistema muestra la interfaz “Gestión de Orden Almacén” con la siguiente información: Datos de los pedidos facturados ordenados por fecha de facturación (lista): código de pedido, cliente, fecha de elaboración y fecha de facturación y las opciones “Ver Detalle” y “Salir”. 3. El CO selecciona un pedido de la lista de pedidos facturados. 4. El CO solicita “Ver Detalle”. 5. El sistema muestra la interfaz “Detalle de Pedido Facturado” con la siguiente información: Datos de Facturación: representante de facturación, fecha de facturación (no habilitados) Datos de pedido: código del pedido, cliente, fecha de elaboración, representante de ventas, dirección de envió, número, puerta, distrito, provincia, persona de contacto, teléfono de contacto, referencia. (no habilitados) Datos de los repuestos del pedido (lista): código de repuesto, descripción, cantidad y unidad, ordenados por código de repuesto. Datos de pago: forma de pago, subtotal, IGV y total. (no habilitados) Las opciones “Generar Orden de Almacén”, “Imprimir”, “Volver”. 6. Si el CO selecciona la opción “Imprimir”, ir al subflujo “Imprimir Detalle”. 7. Si el CO solicita “Volver”, el flujo continúa en el paso 1 del flujo básico. 8. El CO solicita “Generar Orden Almacén”. 9. El sistema muestra la interfaz “Priorización de Orden de Almacén” con la siguiente información: Datos del cliente: código, nombre o razón social, récord de compras (unid monetarias), récord de pedidos (# pedidos), tiempo promedio de pago (días) y confiabilidad (%). Un campo de selección de Nivel: urgente, normal y bajo. Las opciones “Siguiente” y “Cancelar”. 10. EL CO selecciona el nivel de priorización de la Orden de Almacén. 11. El CO selecciona la opción “Siguiente”. 12. El sistema valida la selección del campo nivel. 13. El sistema graba la prioridad de la Orden de Almacén (en sesión). 14. El sistema muestra la interfaz “Asignación de Operarios” con la siguiente información: Un campo fecha con la opción “Ver disponibilidad”. Datos de operarios asignados a la Orden de Almacén (lista): nombre, horas disponibles y horas asignadas. Un campo duración total (en horas) (no habilitado). Las opciones “Siguiente”, “Volver” y “Cancelar”. 15. El CO ingresa una fecha para ver la disponibilidad de operarios. 16. El CO solicita “Ver Disponibilidad”. •

•

•

•

• •

•

• •

• •

• •

CIBERTEC



174

17. El sistema muestra la interfaz “Operarios Disponibles” con la siguiente información: Datos de operarios disponibles en dicha fecha (lista): código de operario, nombre, horas disponibles y horas asignadas (habilitado), con las opciones “Asignar” y “Cancelar”. 18. El CO ingresa la cantidad de horas a asignar a cada operario en el campo horas asignadas de la lista de operarios. 19. Si el CO selecciona la opción “Cancelar”, el flujo regresa al paso 14 del flujo básico. 20. El CO solicita “Asignar”. 21. El sistema valida la cantidad de horas ingresadas. 22. El sistema calcula la duración total de atención de la Orden de Almacén. 23. El sistema muestra la interfaz “Asignación de Operarios de Orden de Almacén” con los datos de los operarios y la duración total. 24. Si el CO desea asignar más operarios a la Orden de Almacén, se repiten los pasos del 16 a 23. 25. Si el CO selecciona la opción “Volver”, el flujo regresa al paso 9 del flujo básico. 26. El CO selecciona la opción “Siguiente”. 27. El sistema graba los datos de los operarios asignados a la Orden de Almacén (en sesión). 28. El sistema muestra la interfaz “Asignación de Transporte” con la siguiente información: Datos del Pedido: código de pedido, dirección de envió, numero, puerta, distrito, provincia y referencia (no habilitados). Datos del Transportista: código de transportista, nombre, DNI y zona (no habilitados) con la opción “Asignar Transportista”. Las opciones “Aceptar”, “Volver” y “Cancelar”. 29. El CO selecciona la opción “Asignar Transportista”. 30. El sistema muestra la interfaz “Selección de Transportista” con la siguiente información: Datos de transportistas disponibles (lista): código, nombre, DNI y zona y las opciones “Aceptar” y “Cancelar”. 31. El CO selecciona un transportista de la lista. 32. El CO selecciona la opción “Aceptar”. 33. El sistema valida la selección de transportista. 34. El sistema muestra la interfaz “Asignación de Transporte” con los datos del transportista asignado. 35. Si el CO selecciona la opción “Volver”, el flujo retorna al paso 28 del flujo básico. 36. El CO selecciona la opción “Aceptar”. 37. El sistema muestra el MSG de confirmación (Aceptar o Cancelar) “¿Desea generar Orden de Almacén?” 38. El CO selecciona la opción “Aceptar”. 39. El sistema genera un código de Orden de Almacén. 40. El sistema obtiene los datos de prioridad y de operarios de la sesión. 41. El sistema graba los datos de la Orden de Almacén con su detalle (prioridad, operarios y transportista) y con la fecha actual, en estado de “No Atendida” y muestra el MSG: “Orden de Almacén generada correctamente” 42. El CO selecciona “Salir”, el sistema cierra la interfaz “Gestión de Orden de Almacén” y el caso de uso finaliza. 3.2. Sub Flujos Imprimir Detalle 1. El sistema imprime el detalle del pedido facturado. 2. El flujo continúa en el paso 8 del flujo básico. •

•

•

•

•

CIBERTEC



175

3.3. Flujos Alternativos 10.1. Cancelar Generación de Orden de Almacén 1. El sistema muestra un mensaje de confirmación (Aceptar o Cancelar) “¿Cancelar generación de Orden de Almacén?” 2. El CO selecciona “Aceptar” para cancelar Orden de Almacén. 3. El sistema cancela la Orden de Almacén y finaliza el caso de uso. 12.1. Datos de priorización inválidos Si los datos ingresados en la prioridad (nivel) son nulos o inválidos en el paso 13 del flujo básico. 1. El sistema muestra un mensaje “Selección de nivel de prioridad obligatoria”. 2. El flujo continúa en el paso 10 del flujo básico. 13.1. – 27.1. Error al grabar en sesión Si el sistema no puede grabar el nivel de prioridad y/o los datos de operarios, muestra el MSG “Error al grabar datos en sesión” y finaliza el caso de uso. 21.1. Cantidad Inválida Si la cantidad ingresada es inválida, el sistema muestra el MSG: “Cantidad de horas invalidas” y el caso de uso continúa en el paso 18. 33.1. Datos de transportista inválidos Si los datos ingresados del transportista son nulos o inválidos, el sistema muestra el MSG: “Selección del transportista obligatoria” y el caso de uso continúa en el paso 31. 41.1. Error al grabar Orden de Almacén Si el sistema no puede grabar la Orden de Almacén muestra el MSG: “Error al grabar Orden de Almacén” y el caso de uso continúa en el paso 38. 4. Precondiciones 4.1. El CO debe estar registrado y logueado en el sistema. 5. Post condiciones 5.1. La Orden de Almacén, con su detalle quedará grabado en el sistema. 5.2. El estado del pedido cambiará a “Enviado a Almacén”, en el sistema. 5.3. El estado de la Orden de Almacén cambiará a “No Atendida”, en el sistema. 6. Requerimientos especiales 6.1. La PC del Coordinador debe tener acceso a intranet. 6.2. La PC del Coordinador debe estar conectada a una impresora. 7. Puntos de extensión Ninguno. 8. Prototipo (A ser diseñado por los alumnos)

2. ATRIBUTOS DE LOS TIPOS DE REQUISITOS

Para cada tipo de requisito identificado, podemos definir una lista de atributos que se utilizarán durante la gestión de los requisitos. A continuación, se describen los atributos que pueden ser utilizados según el tipo de requisito. Ver tabla 11.2.

CIBERTEC



CIBERTEC

176



CIBERTEC

177



CIBERTEC

178



179

Tabla 11.2 – Atributos de los requisitos

CIBERTEC



180

ACTIVIDADES PROPUESTAS 1. Para la próxima clase los equipos de proyectos presentarán los documentos: Plan de gestión de Requerimientos y Documento Visión de su proyecto. 2. Traer dos (2) de los casos de uso más críticos de su proyecto. 3. Exponer sus documentos Plan de Gestión de Requisitos y Documento Visión de su proyecto. 4. Detallar dos (2) Especificaciones de Casos de Uso de su proyecto. 5. Crear un (1) documento Especificación de Caso de Prueba de una (1) de sus especificaciones de caso de uso del punto 1.

CIBERTEC



181

Resumen  Los

documentos se crean según el Plan de Gestión de Requisitos y según los niveles de la pirámide.



Además, puede consultar las siguientes páginas. 

http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html Este artículo ilustra el uso de IBM Rational Requisite Pro para la trazabilidad de los casos de uso con escenarios y casos de prueba.

CIBERTEC



182

ESQUEMA DEL TEMA 9: DOCUMENTOS Y ATRIBUTOS 1. Documentos de la ingeniería de requisitos Según el plan de gestión de los requisitos, se definen los requisitos de la pirámide y cada paso tiene su correspondiente documento a crear. Plan de Gestión de Requisitos Petición del Stakeholder Documento Visión Especificación de Requisitos de Software Especificación de Caso de Uso Especificación de Requisitos Suplementarios. Especificación de casos de prueba. • • • • • • •

2. Atributos de los tipos de requisitos Para cada tipo de requisito identificado, podemos definir una lista de atributos que se utilizan durante la gestión de los requisitos. Los tipos de atributos que se utilizan entre los tipos de requisitos son los siguientes: prioridad, estado, iteración planeada, iteración actual, dificultad, estabilidad, riesgo, origen, nombre de contacto, requisito de mejora, defecto, tipo, propiedad, obsoleto, afecta la arquitectura y prioridad para stakeholder.

CIBERTEC



183


2 TEMA

10 TRAZABILIDAD DE REQUISITOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al finalizar la segunda unidad, el alumno documenta los requisitos funcionales y no funcionales de un software que da soporte a un proceso de negocio, y controla sus cambios haciendo uso de la herramienta CARE IBM Rational Requisite PRO.

TEMARIO 1. Trazabilidad entre requisitos. 2. Caso de Matriz de requisitos.

ACTIVIDADES PROPUESTAS 1.

Los alumnos crean la matriz de necesidades del stakeholder entre las características del sistema.

CIBERTEC



184

1. TRAZABILIDAD ENTRE REQUISITOS La trazabilidad es una técnica que proporciona una relación entre los diferentes niveles de requisitos en el sistema. Esta técnica ayuda a determinar el origen de cualquier requisito. La figura 13.1 ilustra cómo los requisitos se trazan desde el nivel superior hacia abajo. Todas las necesidades por lo general se asignan a algunas características. En general, es una relación de muchos a muchos, porque una necesidad puede rastrear a muchas características, y una característica puede obtenerse de muchas necesidades. Un caso común también es que una necesidad rastrea a una característica. En el siguiente nivel también notamos que las características mapean a los casos de uso en una relación de muchos a muchos. Las características también trazan a los requisitos suplementarios en una relación de muchos a muchos.

Figura 13.1 - Trazabilidad de Requisitos Cada caso de uso traza a uno o más escenarios, así es que existe una relación de uno a muchos entre los casos de uso y escenarios. Los escenarios también tienen una relación de uno a muchos con los casos de prueba. La trazabilidad desempeña varios roles importantes porque permite: 1. Verificar si la aplicación cumple con todos los requisitos: Todo lo que el cliente pidió fue implementado. 2. Verificar si la aplicación hace sólo lo que se pidió: No implementa algo que el cliente nunca solicitó. 3. Realizar un análisis de impacto: ¿Qué elementos se verán afectados si se considera la adición de un nuevo requisito o cambiar una ya existente? 4. Ayudar con la gestión del cambio: Cuando algún requisito cambia, queremos saber qué casos de prueba deben rehacerse para probar este cambio. La trazabilidad es una propiedad de los requisitos aplicable al resto del desarrollo que permite conocer las dependencias entre los distintos artefactos que se van generando.

CIBERTEC



185

Cada vez que se crea o cambia un nuevo artefacto (un objetivo, un requisito, un elemento de modelado, un módulo, un fichero de código fuente, una prueba, etc.) se debe registrar de qué elementos de nivel superior y de su mismo nivel depende. Esta tarea es la única forma de poder realizar un análisis de impacto cuando se solicita un cambio, pues todos los que dependen del artefacto, tanto directa como indirectamente, están expuestos a posibles cambios. La siguiente figura muestra la estructura de trazabilidad utilizada en un proyecto.

Figura 13.2 - Diagrama de Trazabilidad Un elemento de la trazabilidad es un elemento del proyecto que debe ser explícitamente trazado a partir de otro elemento textual o modelo para hacer un seguimiento de las dependencias entre ellos. La siguiente tabla describe todos los tipos de requisitos a utilizar en el proyecto.

Tabla 13.1 - Tabla de descripción de elementos de trazabilidad

CIBERTEC



186

ACTIVIDADES RESUELTAS 1.

A partir de la especificación de la lista de requisitos dada por su profesor realice las siguientes matrices de trazabilidad: Necesidades de stakeholder (STRQ) versus características del producto (FEAT).

•

NECESIDADES STRQ1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos. STRQ2: Las fechas deberán ser mostradas en formato dd/ mm / aaaa. STRQ3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios. STRQ4: La capacidad para cancelar una compra de boleto deberá estar disponible. STRQ5: El usuario será capaz de cancelar una reservación de un auto o un hotel. STRQ6: Los vuelos de ida y llegada serán ordenados por el menor número de paradas. STRQ7: El usuario será capaz de seleccionar los asientos. STRQ8: El sistema deberá tener una interfaz de lenguaje natural. STRQ9: El sistema mostrará un calendario emergente cuando se introduzca una fecha. STRQ10: El usuario deberá indicar si necesita un boleto solo de ida o ida y retorno, marcando la casilla de verificación. STRQ11: Para los vuelos de llegadas y salientes, los usuarios podrán comparar los precios de otros aeropuertos cercanos. STRQ12: A veces un Usuario ingresará un código de aeropuerto, que el sistema entenderá, pero a veces la ciudad más cercana puede reemplazarlo, entonces el Usuario no necesita saber el código del aeropuerto, y todavía no será entendida por el sistema. STRQ13: El sistema deberá tener una navegación clara. STRQ14: Si el usuario compra un boleto una vez, no será necesario repetir la misma información, como dirección o número de tarjeta de crédito. STRQ15: Pago por PayPal estará disponible. STRQ16: Las fechas se muestran en el formato dd / mm / aaaa. STRQ17: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. STRQ18: Será ordenado por precio. STRQ19: La comparación de precios de alquileres de autos de diferentes empresas se facilitará. STRQ20: Los precios de alquiler de autos deben mostrar todos los impuestos aplicables (incluido el 6% IVA del estado). STRQ21: Un calendario estará disponible para ayudar el ingreso de las fechas del vuelo. STRQ22: El sistema deberá proporcionar la posibilidad de reservar el vuelo, compra un boleto, reservar una habitación de hotel, reservar un auto, y proporcionar información acerca de las atracciones. STRQ23: El usuario será capaz de comprar un boleto en línea, sin necesidad de llamar a al Agente de viajes. STRQ24: El sistema deberá seguir las guías de implementación prevista en la cadena de nuestras agencias de viajes. STRQ25: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas

CIBERTEC



187

aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. STRQ26: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad adecuado para las aplicaciones comerciales. STRQ27: El sistema será desarrollado en tres meses. STRQ28: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. STRQ29: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación en base al: apellido, ciudad de destino, fecha, etc. STRQ30: El Agente de Viajes podrá cambiar los detalles de la reservación o cancelar una reservación. STRQ31: Mientras se este ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML. STRQ32: La información de contenido debe ser almacenado en un archivo de texto. STRQ33: El sistema deberá ser completamente probado solo en versiones específicas de los más populares navegadores. STRQ34: El sistema puede mostrar un mapa del aeropuerto. STRQ35: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reserva en base a los apellidos y fecha. STRQ36: Todas las actividades en el Site se registran. STRQ37: Varios informes estarán disponibles. STRQ38: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación. STRQ39: Mientras se proporcione información acerca del hotel, la siguiente información se desplayará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos, las formas de pago disponibles, etc. STRQ40: Al usuario se le ofrecerá ofertas de vuelos y hoteles. STRQ41: Sólo serán aceptados pagos con tarjeta de crédito. No se aceptan cheques ni PayPal. CARACTERISTICAS FEAT1: El usuario deberá ser capaz de comparar los precios de vuelos de otros aeropuertos cercanos (para vuelo de ida y vuelo de retorno). FEAT2: Las fechas deberán ser mostradas de acuerdo al formato cargado en la configuración del navegador Web. FEAT3: En las pantallas de entrada de datos, el sistema indicará que campos son obligatorios de ingresar colocando un asterisco cerca al campo. FEAT4: El usuario será capaz de cancelar la compra de un boleto en cualquier momento antes de la confirmación final de la compra. FEAT5: El usuario será capaz de cancelar una reservación de un auto o un hotel. FEAT6: El usuario será capaz de seleccionar si los vuelos son ordenados por el menos número de paradas o por precio. FEAT7: Durante la compra de un boleto de avión, el usuario será capaz de seleccionar los asientos. FEAT8: El sistema mostrará un calendario emergente en cualquier fecha que se ingrese, tales como una fecha de vuelo, fechas de permanencia en el hotel, o la fecha del alquiler de un auto). FEAT9: El usuario tendrá la oportunidad de indicar si necesita solo un boleto de ida o ida y retorno. FEAT10: El sistema deberá identificar el aeropuerto en base al código del aeropuerto o al nombre de la ciudad. FEAT11: Separación por pestañas disponibles para la funcionalidad principal. FEAT12: En cada página un botón “Siguiente” sugiere el flujo pre determinado.

CIBERTEC



188

FEAT13: Si el usuario compra un boleto de una vez, no será necesario repetir la misma información (tales como dirección o número de tarjeta de crédito) durante las transacciones futuras. FEAT14: La lista de vuelos disponibles deberán incluir número de vuelo, hora de partida, hora de llegada en cada etapa del vuelo. FEAT15: El sistema deberá proporcionar la comparación de los precios de alquiler de autos de diferentes empresas. FEAT16: Los precios del alquiler de autos deben mostrar todos las Impuestos aplicables. FEAT17: El sistema deberá proporcionar la oportunidad de reservar el vuelo. FEAT18: El sistema deberá proporcionar la oportunidad de comprar un boleto de avión. FEAT19: El sistema deberá proporcionar la oportunidad de reservar una habitación de hotel. FEAT20: El sistema deberá proporcionar la oportunidad de reservar un auto. FEAT21: El sistema deberá proporcionar información acerca las atracciones en lugares específicos. FEAT22: El usuario será el capaz de comprar un boleto en línea, sin necesidad de llamar al Agente de viajes. FEAT23: El sistema utilizará la arquitectura JEE. FEAT24: Si la arquitectura requiere de un servidor de aplicaciones deberá utilizar IBM WebSphere. FEAT25: Si el sistema requiere una base de datos. Oracle deberá utilizar. FEAT26: Las páginas donde los proveedores de servicios pueden presentar sus ofertas deberán estar protegidas con contraseñas. Los proveedores de hotel, los proveedores de automóviles, y los representantes de líneas aéreas deberán usar su ID y contraseña asignado para acceder a estas páginas. FEAT27: El sistema debe estar disponible las 24 horas del día, con un grado de fiabilidad apropiado para las aplicaciones comerciales. FEAT28: El sistema deberá ser desarrollado tres meses a partir de la fecha en que el cliente firme los Casos de Uso y las especificaciones suplementarias. FEAT29: Los usuarios recogerán sus ID y contraseñas mientras compran un boleto de avión. FEAT30: El servicio de búsqueda permitirá al Agente de Viajes encontrar una reservación en basado en lo siguiente: apellido, ciudad de destino y fecha. FEAT31: El Agente de Viajes será podrá cambiar los detalles de una reservación. FEAT32: El Agente de Viajes podrá de cancelar una reservación. FEAT33: Mientras se este ingresando la información de contenidos, el administrador de Contenido podrá ingresar el texto sin etiquetas HTML. FEAT34: El sistema deberá ser completamente probado en los siguientes navegadores: Internet Explorer y Netscape. FEAT35: Todas las transacciones y los errores deberán ser registrados y estarán disponibles para el Administrador. FEAT36: Los siguientes informes estarán disponibles para el Administrador: Una lista de todos los boletos de avión comprados en un período de tiempo determinado. Una lista de todas las reservas de autos en un período de tiempo determinado. Una lista de todas las reservas de habitaciones de hotel en un periodo de tiempo determinado. FEAT37: Mientras se reserve una habitación, el cliente deberá proporcionar la siguiente información: ciudad, días de alojamiento, el número de adultos, número de hijos y preferencias de habitación.

CIBERTEC



189

FEAT38: Mientras se proporcione información acerca del hotel, la siguiente información se mostrará: dirección, teléfono, fax, correo electrónico, los descuentos ofrecidos y las formas de pago disponibles. FEAT39: Al usuario se le ofrecerá paquetes de ofertas que constan de vuelos y alojamiento en hoteles. FEAT40: Durante el pago del boleto de avión, solo se aceptará con tarjeta de crédito. Cheques y PayPal no serán aceptados. 2.

A partir del siguiente caso, identificar las necesidades del stakeholder, características del sistema y casos de uso. Luego crear las matrices correspondientes.

Caso Saga Falabella “Saga Falabella” es un conocido Centro Comercial que se dedica a las ventas de productos al crédito, dentro de su política de calidad y mejora continua desea realizar el estudio de sus procesos. El Centro Comercial “Saga Falabella” tiene dos (2) diferentes tipos de clientes que son: individuales (titulares) y familiares (dependientes). Para obtener una tarjeta de crédito, cualquier solicitante debe acercarse a una de las tiendas del Centro donde es atendido por un vendedor que se encarga de llenar sus datos tanto personales como del crédito en el formulario GCC-01 denominado “Solicitud de crédito”. Para completar el expediente del cliente, además del formulario adjunta la copia del DNI, un recibo de luz, agua o teléfono y las tres últimas boletas o recibos de honorarios profesionales que acrediten los ingresos del cliente. Al final del día el vendedor recopila los expedientes y los entrega al coordinador de inspectoría de la central de créditos, quien se encarga de repartir los expedientes a los diferentes inspectores. Por cada expediente, el inspector debe primero verificar que el solicitante no tiene ningún trámite de crédito pendiente ni se encuentra calificado como “Inhabilitado para créditos” en la base de datos de INFOCORP, luego procede a realizar la verificación de los datos declarados por el solicitante mediante llamadas telefónicas o visitas personales. Después de realizar un máximo de tres visitas y de constatar la validez de la información declarada por el futuro cliente, prepara un informe de inspectoría que le hace llegar, junto con el expediente del solicitante, al jefe de créditos. El jefe de créditos tiene la última palabra acerca de la aprobación o denegación del crédito. Si su evaluación es positiva le otorgará una línea de crédito de consumo mensual y comunicará al asistente de créditos que genere una tarjeta con una clave secreta para el cliente, la cual será remitida en sobre sellado. PREGUNTAS 1. Usted es el Analista de Sistema y deberá identificar las Necesidades relacionadas a este proceso, describiendo brevemente cada uno. Necesidades Descripción STRQ1 El usuario podrá registrar una solicitud de crédito con los datos personales del cliente. STRQ2 El sistema permitirá asignar expedientes a los inspectores. STRQ3

CIBERTEC

La capacidad de registrar informes de las inspectorias a los clientes.



STRQ4

190

El Jefe de créditos podrá evaluar una solicitud de crédito para aprobarlo o rechazarlo. Debe estar disponible la opción de generar una línea de crédito después de aprobada una solicitud. El sistema debe imprimir la tarjeta de crédito para el cliente que se le aprobó el crédito. Los usuarios podrán consultar trámites pendientes del cliente y solicitudes por estado. Los usuarios podrán verificar la calificación de un cliente con el sistema de INFOCORP. La comunicación entre usuarios será por correo electrónico.

STRQ5 STRQ6 STRQ7 STRQ8 STRQ9 STRQ10

Los usuarios del sistema tendrán un Usuario y contraseña para ingresar al sistema.

2. En función a las necesidades identificar las características del producto. Necesidad STRQ1

Característica

STRQ1

FEAT2

STRQ2

FEAT3

STRQ2

FEAT4

STRQ3

FEAT5

STRQ4

FEAT6

STRQ5

FEAT7

STRQ7 STRQ8 STRQ8

FEAT8

STRQ8

FEAT10

STRQ9

FEAT11

STRQ10

FEAT12

STRQ1 STRQ2

FEAT13

FEAT1

Descripción El sistema permitirá registrar una solicitud de crédito. El sistema permitirá registrar los datos personales de un cliente. Disponibilidad de la lista de inspectores, para su búsqueda. El sistema permitirá asignar expedientes a los inspectores para su inspección. El sistema proveerá la oportunidad de registrar un Informe de las inspecciones realizadas a un cliente. El sistema permitirá evaluar una solicitud de crédito, para aprobar o rechazar. El sistema permitirá generar una línea de crédito, si el crédito fue aprobado. Una vez generado la línea de crédito, el sistema permitirá imprimir una tarjeta de crédito para el cliente. El sistema tendrá consultas de: trámites pendientes, a INFOCORP solicitudes por estado y solicitudes mensuales El sistema deberá comunicarse con el sistema de INFOCORP, para verificar la calificación de riego de los clientes. El sistema permitirá a los usuarios conocer el estado de las solicitudes por correo electrónico. El sistema verificará el usuario y contraseña para ingresar al aplicativo. El sistema permitirá gestionar los datos de los clientes e inspectores.

FEAT9

3. De las características identificadas en la pregunta 2, se le pide que usted identifique los casos de uso del sistema que deben darle cobertura. Describa brevemente cada uno de ellos. Característica FEAT1 FEAT2 FEAT3

CIBERTEC

Caso de Uso UC1

Descripción Registrar solicitud de Crédito.

UC2

Buscar Inspector.



191

FEAT4

UC3

Asignar Expediente.

FEAT5

UC4

Registrar Inspectorias

FEAT6

UC5

Evaluar Crédito.

FEAT7

UC6

Generar Línea de Crédito.

FEAT8

UC7

Generar Tarjeta de Crédito.

FEAT9 FEAT9 FEAT10 FEAT9

UC8 UC9

Consultar trámites pendientes. Consultar Cliente en INFOCORP.

UC10

Consultar solicitudes x estado.

FEAT9

UC11

Consultar solicitudes mensuales.

FEAT11

UC12

Enviar correo.

FEAT12

UC13 UC14 UC15 UC16

Mantener Cliente Buscar Cliente Mantener Inspector. Ingresar al sistema.

FEAT13

4. Elaborar el diagrama estructurado de casos de uso. Asuma los casos de uso incluidos y/o extendidos y justifíquelos.

CIBERTEC



CIBERTEC

192



193

Resumen 

La trazabilidad es una propiedad de los requisitos aplicable al resto del desarrollo que permite conocer las dependencias entre los distintos artefactos que se van generando.



Además, puede consultar las siguientes páginas: 

http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html Este artículo ilustra el uso de IBM Rational Requisite Pro para la trazabilidad de los casos de uso con escenarios y casos de prueba.

CIBERTEC



194

ESQUEMA DEL TEMA 10: TRAZABILIDAD DE REQUISITOS 1. Trazabilidad entre requisitos La trazabilidad es una técnica que proporciona una relación entre los diferentes niveles de requisitos en el sistema. Esta técnica ayuda a determinar el origen de cualquier requisito. La trazabilidad desempeña varios roles importantes porque permite: Verificar si la aplicación cumple con todos los requisitos: Todo lo que el cliente pidió fue implementado. Verificar si la aplicación hace sólo lo que se pidió: No implementa algo que el cliente nunca solicitó. Realizar un análisis de impacto: ¿Qué elementos se verán afectados si se considera la adición de un nuevo requisito o cambiar una ya existente? Ayudar con la gestión del cambio: Cuando algún requisito cambia, queremos saber qué casos de prueba deben rehacerse para probar este cambio. •

•

•

•

CIBERTEC



195

ANEXO

1 PLANTILLAS REQUISITOS

DE

DOCUMENTOS

DE LA

GESTIÓN

DE

CONTENIDO • • • • • • •

CIBERTEC

Plan de Gestión de Requisitos Petición del Stakeholder Documento Visión Glosario de Términos Especificación de Requisitos de Software Especificación de Casos de Uso Especificación de Requisitos Suplementarios.



196

Plan de Gestión de Requisitos

1. Introducción [Este documento describe los criterios que utiliza el proyecto para establecer documentos de requisitos estándar, tipos de requisitos, atributos de requisito, y trazabilidad. Se define una estrategia general para la gestión de requisitos y sirve como un recurso para todas las personas que participan en este proyecto] 1.1. Propósito [El propósito de este plan es establecer y documentar un enfoque sistemático para capturar, organizar y documentar los requisitos del sistema. Este plan también establece y mantiene un acuerdo entre el cliente y el equipo del proyecto sobre las necesidades cambiantes del sistema] 1.2. Alcance [Este plan proporciona la guía para la gestión del [nombre del proyecto] 1.3. Descripción [Este documento contiene detalles específicos y estrategias para la gestión de los requisitos de [nombre del proyecto]. El documento detalla cómo los requisitos están organizados y administrados dentro de nuestro proyecto. También se describe cómo los requisitos son identificados, atributos asignados, rastreados, y modificados] [El documento describe la gestión de los procesos de cambio de los requisitos. En él se describen los flujos de trabajo y actividades relacionadas con el mantenimiento del control de los requisitos de proyecto] [Se especifican los hitos que deben alcanzarse y las normas que deben ser respetadas de manera que podamos garantizar y evaluar el cumplimiento de los requisitos que se especifican] 2. Herramientas, Entorno e Infraestructura [Describe el entorno de computación y herramientas de software para ser utilizados en el cumplimiento de las funciones de gestión de requisitos a través del proyecto o del ciclo de vida del producto] Herramienta

Descripción

Rational RequisitePro

Para gestión de requisitos

Información de Licencia

Soporte Técnico

Website

[email protected] www.rati onal.co m

3. Artefactos de los Requisitos 3.1. Tipo de Documentos [Esta tabla describe los tipos de documento por defecto incluido en esta plantilla, y sus tipos requisito asociado por defecto. Usted debe agregar sus tipos de documentos personalizados a esta tabla a medida que los crea] Tipo de Documento Peticiones del Stakeholder (PSH) Vision (VIS) Especificación de Caso de Uso (ECU)

CIBERTEC

Descripción Peticiones claves de los Stakeholders Condiciones o capacidades de la versión del sistema. Elaboración y descripción del caso de uso.

Tipo de requisito por defecto Stakeholder Request (STRQ) Feature (FEAT) Use Case (UC)



Glosario (GLS) Especificación de Requerimientos Suplementarios (SUP) Plan de Gestión de Requisitos (PGR)

197

Usado para capturar el vocabulario común Describe los requisitos del sistema que no son fácilmente capturados por los casos de uso Describe los requisitos y estratégias específicas para la gestión y el desarrollo del proyecto

Glossary Item (TERM) Supplementary Requirement (SUPL) Ninguno (NONE)

3.2. Tipos de Requisitos [Esta tabla describe los tipos de requisitos por defecto incluido en esta plantilla. Usted debería agregar sus tipos requisitos personalizados a esta tabla a medida que los crea] 3.3. Atributos [Para cada tipo de requisito que ha identificado, defina una lista de atributos que se utilizarán y explique brevemente lo que significan. Usted puede describir los atributos y sus valores por cada tipo de requisito en diferentes secciones. A continuación, se describen cada uno de los a utilizar por cada tipo de requisito de su proyecto.] 3.4. Trazabilidad Necesidad del Stakeholder

Característica

Caso de Uso

Requerimiento Suplementario

[Para cada tipo de requisito que usted ha identificado, liste algunas reglas adicionales o directrices que se aplican a los enlaces de trazabilidad. Describa las limitaciones aplicables, tales como "todas las características aprobadas deben rastrear a uno o más Casos de Uso o a uno o más Requisitos Suplementarios.”] Tipo de Requisito Stakeholder Request (STRQ) Feature (FEAT) Use Case (UC) Glossary Item

CIBERTEC

Directrices

Notas



(TERM) Supplementary Requirement (SUPL)

198

.

3.5. Informes / Medidas [Describa el contenido, formato y propósito de los informes y medidas de requisitos. Use las plantillas de la tabla para describir los informes que usted genera usando RequisitePro’s Requirements Metrics tool. Para más información revise RequisitePro online help] Descripciones de la Vista: [Use esta sección para describir las vistas que has creado para tu proyecto] Nombre de la Descripción Vista de Trazabilidad FEAT no trazadas de STRQ

Tipo de Atributos Requisito FEAT, STRQ

n/a

Rango de valor del atributo No trazado

SUPL no trazadas de FEAT UC no trazadas de FEAT Todas los FEAT

SUPL, FEAT

n/a

No trazado

UC, FEAT

n/a

No trazado

FEAT

todo

todo

FEAT, STRQ

n/a

todo

TERM

todo

todo

FEAT impactados por cambios de STRQ SUPL impactados por cambios de FEAT

FEAT, STRQ

n/a

Solo sospechoso

SUPL, FEAT

n/a

Solo sospechoso

UC impactados por cambios de FEAT Todas las STRQ

UC, FEAT

n/a

STRQ

todo

Solo sospechoso todo

Todos los SUPL

SUPL

todo

todo

SUPL trazadas de FEAT Estudio de los UC

SUPL, FEAT

n/a

todo

UC

nombre, breve descripción n/a

nombre, breve descripción todo

FEAT trazadas de STRQ Todos los TERM

UC trazadas de FEAT

CIBERTEC

UC, FEAT



199

Petición del Stakeholder 1. Introducción [Este documento describe las necesidades del o los stakeholder (s) de la organización a través de técnicas de recolección de captura de requisitos] 2. Perfil del Stakeholder Nombre: [Indicar el nombre del stakeholder] Compañía: [Indicar el nombre de la compañía] Cargo: [Indicar el cargo del stakeholder] • • •

3. Lista de requerimientos 3.1 [Descripción de una característica software, ámbito y propiedades de la misma] 3.2 [Descripción de una característica software, ámbito y propiedades de la misma]

CIBERTEC



200

Documento Visión 1. Introducción 1.1. Propósito [Breve descripción del propósito del presente documento, como puede ser servir de soporte a la especificación de las características software y de los atributos de las mismas, por ejemplo. También reflejar si el sistema que se modela está dividido en otros subsistemas o bien el propósito general de la empresa.] 1.2. Alcance [Definición del alcance del presente documento, es decir, todo ámbito del que recoge características o detalles.] 1.3. Definiciones, Acrónimos, y Abreviaciones [RUP: Son las siglas de Rational Unified Process. Se trata de una metodología para describir el proceso de desarrollo de software.] 1.4. Referencias - Glosario. - Plan de desarrollo de software. - RUP (Rational Unified Process). - Diagrama de casos de uso. 2. Posicionamiento Oportunidad de Negocio [Ventajas que obtendrá la empresa al implantar el sistema informático.] Sentencia que define el problema Sentencia que define la posición del Producto 3. Descripción de Stakeholders y Usuarios [Para proveer de una forma efectiva productos y servicios que se ajusten a las necesidades de los usuarios, es necesario identificar e involucrar a todos los participantes en el proyecto como parte del proceso de modelado de requisitos. También es necesario identificar a los usuarios del sistema y asegurarse de que el conjunto de participantes en el proyecto los representa adecuadamente. Esta sección muestra un perfil de los participantes y de los usuarios involucrados en el proyecto, así como los problemas más importantes que éstos perciben para enfocar la solución propuesta hacia ellos. No describe sus requisitos específicos ya que éstos se capturan mediante otro artefacto. En lugar de esto proporciona la justificación de por qué estos requisitos son necesarios.] 3.1. Resumen de Stakeholders [Hay varios stakeholders con un interés en el desarrollo. Presente una lista de estos stakeholders.] 3.2. Resumen de Usuarios [Hay varios usuarios con un interés en el desarrollo. Presente una lista de ellos.]

CIBERTEC



201

3.3. Entorno de usuario [Descripción del entorno de trabajo del usuario, características de los PC’s a utilizar, sistemas operativos, etc.] 3.4. Perfil de los Stakeholders [Describa cada stakeholder en el sistema rellenando la tabla siguiente para cada stakeholder. Recuerde que los tipos de stakeholder pueden ser usuarios, departamentos o diseñadores técnicos. Un perfil completo cubriría los temas siguientes para cada tipo de stakeholder.] 3.4.1 3.5. Perfiles de Usuario 3.5.1 4. Descripción Global del Producto 4.1 Perspectiva del producto [Ámbito de aplicación del sistema y expectativas del mismo] 4.2 Resumen de características [A continuación se mostrará un listado con los beneficios que obtendrá el cliente a partir del producto:] 4.3 Suposiciones y dependencias [Todas las suposiciones y dependencias deben ser definidas por el cliente] 4.4 Costo y precio [El costo y precio del sistema con todas las características software son decisión entre cliente y empresa de desarrollo software] 5. Características Globales del Producto 5.1 [Descripción de una característica software, ámbito y propiedades de la misma] 5.2 [Descripción de una característica software, ámbito y propiedades de la misma] 5.2.1 [Descripción de una característica software que deriva de una característica software jerárquicamente superior, ámbito y propiedades de la misma] 6. Requisitos de Documentación 6.1 Manual de Usuario [A definir por el cliente] 6.2 Ayuda en Línea [A definir por el cliente] 6.3 Guías de Instalación, Configuración, y Fichero Léame [A definir por el cliente]

CIBERTEC



202

Glosario de Términos

1. Introducción [Este documento es usado para definir la terminología específica para el dominio del problema, explicando términos que no pueden ser familiares para leer la descripción de un caso de uso u otro documento del proyecto. Frecuentemente este documento puede ser usado como un diccionario de datos informal, capturando definiciones de datos.] 2. Definiciones [Los términos definidos aquí son la escencia sustancial del documento. Se ordena en orden alfabético.] 2.1. [La definición de un término es presentado aquí, para entender el concepto.] 2.2. [La definición de otro término es presentado aquí, para entender el concepto.]

CIBERTEC



203

Especificación de Requisitos de Software 1. Introducción [La introducción de la Especificación de Requerimientos de Software debe ser un resumen del documento completo. Debe incluir el propósito, ámbito, definiciones, acrónimos, abreviaciones, referencias, y resumen ejecutivo de este documento] 1.1. Propósito [El propósito de este documento es capturar todos los requerimientos de software del sistema, o un subconjunto del sistema.] 1.2. Ámbito [Párrafo obligatorio.] [Una descripción del entorno afectado; qué proyectos se ven afectados o influenciados por esta Especificación de Requerimientos de Software.] 1.3. Definiciones, Acrónimos y Abreviaciones [Párrafo obligatorio si existen términos, definiciones acrónimos o abreviaciones.] [Esta subsección debe proporcionar las definiciones de todos los términos, acrónimos, y abreviaciones requeridas para interpretar correctamente la Especificación de Requerimientos de Software. Esta información puede ser entregada a modo de referencia al Glosario del proyecto.] [Recomendación: Se sugiere mantener solo un glosario para el proyecto.] 1.4. Referencias [Párrafo obligatorio si existen referencias.] [Esta subsección debe entregar una lista de todos los documentos referenciados en cualquier lugar de esta Especificación de Requerimientos de Software. Cada documento debe ser identificado por título, edición (si es aplicable), fecha, y editorial. Especificar las fuentes de donde se pueden obtener estas referencias, esta información puede ser entregada como referencia a un apéndice o a otro documento.] 1.5. Resumen Ejecutivo [Párrafo NO obligatorio.] [Esta subsección debe describir el resto del documento conteniendo y explicando como esta organizado.] 2. Descripción General [Se considera en esta parte la descripción de los factores principales que afectan al espacio de la solución. Incluya aquellos ítems como perspectiva del producto, funciones del producto, características de usuario, limitaciones, supuestos y dependencias. No se incluye en esta sección la descripción de los requerimientos.] 2.1. Especificación de Funcionalidades [Párrafo obligatorio.] [Si usa el modelado de casos de uso, esta sección debe contener la referencia de éste, y una descripción o resumen del modelo o del subconjunto más representativo del mismo. Esto incluye una lista de nombres y breves descripciones de los casos de uso, actores, diagramas aplicables y relaciones. En caso de no existir modelo de caso de uso se deben referenciar todas las descripciones existentes de las funcionalidades, ya sean minutas de reunión,

CIBERTEC



204

correos electrónicos, etc. Es necesario agregar esas descripciones en esta sección y en la sección 1.4 Referencias del documento se necesitan mencionar todos los fuentes de los requerimientos.] [Este punto se puede reemplazar con la plantilla Excel de Administración de Requerimientos haciendo referencia.] 2.2. Supuestos y Dependencias [Párrafo obligatorio.] [Esta sección describe cualquier factibilidad técnica clave, disponibilidad de componentes o subsistemas, u otros supuestos realizados en los cuales la viabilidad del software descrito en esta Especificación de Requerimientos de Software se base.] 2.3. Acuerdos con el Cliente para la Administración de Requerimientos [Párrafo obligatorio.] [En esta sección se define cómo se tratarán los cambios de los requerimientos. Normalmente, en la Orden de Servicio se define un porcentaje como cuota para realizar posibles cambios en los requerimientos. Este impacto se mide en la cantidad de horas/hombre que requiera esta modificación.] 3. Especificación de Requerimientos [Esta sección debe describir detalladamente todos los requerimientos de software, de forma de permitir a los analistas, diseñar el sistema para satisfacer los requerimientos como también a los testeadores diseñar un plan de testing adecuado para poder verificar el cumplimiento de los mismos. Cuando se usa el modelado de casos de uso, estos requerimientos se capturan en los casos de uso, y en las especificaciones adicionales aplicables, Si no se usa el modelado de casos de uso, la definición de especificaciones adicionales debe insertarse directamente aquí.] 3.1. Reportes de Casos de Uso [Párrafo obligatorio.] [En modelado de casos de uso, ellos definen la mayoría de los requerimientos funcionales del sistema y algunos requerimientos no funcionales. Para cada caso de uso en el modelo superior, o subconjunto del mismo, refiérase o cierre el reporte de caso de uso en esta sección. Asegúrese de que cada requerimiento esta claramente etiquetado.] [Para proyectos pequeños, de duración menor a un mes y un equipo de menos de 3 personas, este párrafo se puede reemplazar con una referencia a documento Análisis Preliminar.] 3.2. Requerimientos Funcionales [Párrafo obligatorio.] [En esta sección se deben describir todos los requerimientos funcionales en forma detallada, esta sección debe ser usada cuando las funcionalidades no son transacciones de algún framework transaccional. La descripción debe ser suficientemente clara para permitir a los diseñadores hacer un diseño apropiado, los programadores entender funcionalidad y a los testeadores elaborar un plan de testing apropiado.] [Este punto se puede reemplazar haciendo referencia a la plantilla Excel de Administración de Requerimientos.] 3.3. Requerimientos no Funcionales [Párrafo obligatorio.]

CIBERTEC



205

[En esta sección se describen los aspectos no funcionales, tales como tiempo de respuesta, estética de la aplicación, facilidad de navegación, etc.] [Este punto se puede reemplazar haciendo referencia a la plantilla Excel de Administración de Requerimientos.] 3.4. Requerimientos Técnicos [Párrafo obligatorio.] [En esta sección se describen los requerimientos técnicos, tales como sistema operativo, plataforma de arquitectura, por ejemplo WebSphere, .NET, etc.] [Este punto se puede reemplazar referenciando a la plantilla Excel de Administración de Requerimientos.] 3.5. Requerimientos de Proceso [Párrafo obligatorio.] [En esta sección se describen los requerimientos de proceso. Por ejemplo, para desarrollo se necesita usar proceso de desarrollo en cascadas, RUP, XP, ITDA- KP,… Este párrafo se puede relacionar con artefacto Configuración del Proceso o con el Plan del Proyecto.] [Este punto se puede reemplazar haciendo referencia a la plantilla Excel de Administración de Requerimientos.] 4. Administración de Requerimientos [Párrafo obligatorio.] [En esta sección se especifica cómo se realizará el seguimiento de los requerimientos, y los documentos asociados a este seguimiento, así mismo, en esta sección, se describen cómo se realizarán los posibles cambios o nuevas modificaciones existentes durante el proyecto. Esto normalmente se puede seguir con la plantilla Excel de Administración de Requerimientos al cual se debe referenciar en esta sección.]

CIBERTEC



206

Especificación de caso de uso: 1. Breve Descripción [Breve descripción en líneas generales de la funcionalidad del caso de uso, de los actores que intervienen y del entorno de invocación] 2. Actores [Indicar los actores que interactúan con el caso de uso] 3. Flujo de Eventos 3.1. Flujo Básico [Detallar la secuencia de pasos entre el actor (es) y el sistema. Aquí se pueden hacer referencia a casos de uso incluidos. Además que pueden invocarse a los subflujos.] 1. 2. 3.2. Sub Flujos [Detallar la secuencia de pasos entre el actor (es) y el sistema. Aquí se pueden hacer referencia a casos de uso incluidos. Además que pueden invocarse a los subflujos.] 1. … [Descripción del sub flujo, bifurcación del flujo básico y también detalla interacción entre el actor y el sistema.] 3.3. Flujos Alternativos [Descripción del flujo alternativo, en qué punto se puede producir, qué acciones se realizarán, mensajes, etc. Pueden generar casos de uso extendidos.] [Descripción del flujo alternativo, en qué punto se puede producir, qué acciones se realizarán, mensajes, etc. Pueden generar casos de uso extendidos.] 4. Precondiciones [Indica las condiciones del sistema en el pasado, antes que se ejecute el caso de uso Las precondiciones se pueden eliminar si no son relevantes] 5. Poscondiciones [Indica las condiciones a futuro, cómo quedará el sistema después que se ejecute el caso de uso. Las poscondiciones se pueden eliminar si no son relevantes] 6. Requerimientos especiales [Aquí se pueden indicar requerimientos no funcionales para el caso de uso.] 7. Puntos de Extensión [En este párrafo se hacen las referencias a los casos de uso extendidos. Las puntos de extensión se pueden eliminar si no son relevantes] 8. Prototipos [Aquí se diseñan las pantallas, reportes, etc. que permitirá la interacción del actor con el sistema y/o lo que se obtenga como resultado en pantallas o reportes.]

CIBERTEC



207

Especificación de Requisitos Suplementarios 1. Introducción [La introducción debe proporcionar una visión general del documento Requerimientos Suplementarios . Los Requerimientos Suplementarios capturan los requerimientos del sistema que no son prontamente capturados en los casos de uso del Modelo de Casos de Uso. Estos requerimientos incluyen los siguientes aspectos: Requerimientos legales y reguladores, incluyendo los estándares de la aplicación. Atributos de calidad del sistema a ser construido, incluyendo usabilidad, fiabilidad, performance y requerimientos de soporte. Requerimientos tales como sistemas operativos y entorno, compatibilidad y restricciones de diseño.] 1.1.Propósito [Esta sección debe indicar el propósito de los Requerimientos Suplementarios y la audiencia esperada para este documento.] 1.2.Alcance [Esta sección debe contener una breve descripción del alcance de los Requerimientos Suplementarios y todo lo que es afectado o influenciado por este documento.] 1.3. Definiciones, siglas y abreviaturas. [Esta sección debe proporcionar las definiciones de todos los términos, las siglas y abreviaciones requeridas para interpretar apropiadamente el documento Requerimientos Suplementarios . Esta información puede proporcionarse por la referencia al Glosario del proyecto.] 1.4.Referencias [Esta sección debe proporcionar una lista completa de todos los documentos a los que se hace referencia en el documento Requerimientos Suplementarios . Cada documento debe identificarse por el título, número del informe (si se aplica), fecha, y organización que lo publica. Especifique las fuentes de las que pueden obtenerse las referencias. Esta información puede proporcionarse por la referencia a un apéndice o a otro documento.] 1.5. Visión general [Esta sección describe qué contiene el resto del documento Requerimientos Suplementarios y explica cómo se organiza este documento.] 2. Funcionalidad [Esta sección describe los requerimientos funcionales del sistema que se expresan en lenguaje natural. Generalmente, se organiza por funcionalidad pero se puede organizar alternativamente por usuario, por subsistema. Los requisitos funcionales pueden incluir conjuntos de funcionalidades, capacidades y seguridad.] 2.1. [Requerimiento Funcional 1] [Descripción del requerimiento] 3. Usabilidad [Esta sección incluye los requerimientos que afectan la usabilidad. Por ejemplo: especificar el tiempo requerido para capacitación de usuarios normales y especializados para ser productivos en determinadas funciones. especificar tiempos mensurables para tareas típicas. especificar requerimientos para cumplir con los estándares comunes de usabilidad.] 3.1. [Requerimiento de usabilidad 1] [Descripción del requerimiento] •

• •

CIBERTEC



208

4. Fiabilidad [En esta sección se describen los requerimientos de fiabilidad. Por ejemplo: Disponibilidad: especifica el porcentaje de tiempo disponible, horas de uso, acceso para mantenimiento, etc. Tiempo medio entre fallas. Tiempo medio para reparación: cuánto tiempo es posible que el sistema esté inoperante después que falla. Exactitud: especificar la precisión y exactitud (según algún estándar conocido) que se requiere para las salidas del sistema. Cantidad máxima de errores o porcentaje de defecto: generalmente expresado en términos de errores por miles de líneas de código o errores por punto funcional. Errores o porcentaje de defecto: categorizados en términos de errores menores, significantes y críticos (se debe definir qué significa error “crítico”, por ejemplo, pérdida completa de dato o imposibilidad de uso de ciertas funcionalidades del sistema).] 4.1. [Requerimiento de Fiabilidad 1] [Descripción del requerimiento] •

• •

•

•

•

5. Performance [En esta sección se deben especificar las características de performance del sistema. Incluye tiempos de respuesta específicos. Si se aplica, haga referencia al Caso de Uso relacionado por su nombre. Un ejemplo de contenido de esta sección sería: Tiempo de respuesta para una transacción (promedio, máximo) Transacciones por segundo. Capacidad, como por ejemplo el número de clientes o transacciones que el sistema puede soportar. Modos de degradación, esto es, cuál es el modo aceptable de funcionamiento cuando el sistema ha sido degradado de alguna manera. Utilización de recursos: memoria, disco, comunicaciones, etc.] 5.1. [Requerimiento de Performance 1] [Descripción del requerimiento] • • •

•

•

6. Soporte [Esta sección incluye requerimientos que refuercen el soporte y mantenimiento del sistema que está siendo construido, incluyendo normas de codificación, convenciones de nombres, librerías, acceso para mantenimiento, utilidades de mantenimiento si las hay. Como requerimiento que ayuda al mantenimiento se debe hacer referencia al uso de nomenclatura común para el desarrollo del sistema, y a la metodología de desarrollo en lo que refiere a organización de Bases de Conocimiento y cómo se nombran organizan y denominan los objetos en cada Base de Conocimiento. Adjunte o haga referencia a los documentos de Metodología Genexus y Nomenclatura.] 6.1. [Requerimiento de Soporte 1] [Descripción del requerimiento] 7. Componentes comprados [Esta sección describe los componentes comprados que se usarán con el sistema, las licencias necesarias o restricciones de uso y todo lo asociado con compatibilidad o interoperabilidad o interfases estándares.] 8. Requerimientos de Autorización (licenciamiento) [Define requerimientos de autorización o restricción de uso que debe tener el software.]

CIBERTEC



209

9. Leyes, derechos de propiedad literaria y avisos [Esta sección describe cualquier restricción legal necesaria, garantías, avisos de propiedad literaria, aviso de patente, marca de fábrica o logotipo que deba incluir el software.] Estándares aplicables [Esta sección describe mediante referencia a todos los estándares que serán aplicados y las secciones específicas donde serán aplicados en el sistema que se describe.]

CIBERTEC



210

Glosario Abstracción Características esenciales de una entidad que la distingue de otros tipos de entidades. Define una frontera desde la perspectiva del observador. API Una API representa una interfaz de comunicación entre componentes de software. Se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los procesos y representa un método para conseguir abstracción en la programación, generalmente (aunque no necesariamente) entre los niveles o capas inferiores y los superiores del software. Artefacto Pieza discreta de información que es utilizada o producida por un proceso de desarrollo de software. Aspecto Módulo software que no puede ser encapsulado en un procedimiento. Los aspectos no son unidades funcionales en las que se pueda dividir un sistema, sino propiedades que afectan a la ejecución o semántica de los componentes. Son conocidos también como intereses transversales. Elemento Constituyente atómico de un modelo. Especificación Descripción textual de la sintaxis y la semántica de un bloque de construcción específico; descripción declarativa de lo que algo es o hace. Estereotipo Extensión del vocabulario de UML que permite crear nuevos bloques de construcción derivados a partir de los existentes pero específicos a un problema concreto. Gestión de Requisitos Actividad para gestionar los cambios en los requisitos del sistema. La gestión implica el control de cambios y el impacto de los cambios. Ingeniería de Requisitos Es un área de investigación que procura atacar un punto fundamental en el proceso, que es la definición de lo que se quiere producir. Ingeniería de Software Rama de la ingeniería que aplica los principios de la ciencia de la computación y las matemáticas para lograr soluciones costo-efectivas a los proyectos de desarrollo o mantenimiento de software de calidad. Notación

CIBERTEC


Manual 2011-II 04 Análisis y Diseño de Sistemas II (Adm Sist) Teoría (0654)

Recommend Documents