Propuesta para la documentación de la Ingeniería de Requisitos

UNIVERSIDAD DE LOS ANDES VENEZUELA

GRUPO DE INGENIERÍA DE REQUISITOSUD-DSIA

DIRECCIÓN DE SERVICIOS DE INFORMACIÓN ADMINISTRATIVA DE LA

ULA

Propuesta para el Documento de Ingeniería de Requisitos

de la DSIA Versión 1.0

Grupo de Ingeniería de Requisitos de la DSIA Porras C., Luis E.

Duran B., Norma E. Díaz B. Marisol del C. Sánchez B., Lena M.

Diciembre, 2011




ULA

Contenido Contenido ............................................................................................................................... 2 Introducción............................................................................................................................ 3 1. Estructura del Documento .............................................................................................. 3 2. Descripción de las estructuras del documento................................................................ 4

2.1. Portada del documento ........................................................................................... 4 2.2. Tabla de Contenido................................................................................................. 5 2.3. Sección 1 ................................................................................................................ 5

2.3.1. Introducción.................................................................................................... 5 2.3.2. Propósito del documento ................................................................................ 5 2.3.3. Alcance del proyecto ...................................................................................... 5 2.3.4. Definiciones, acrónicos y abreviaturas........................................................... 5 2.3.5. Referencias ..................................................................................................... 5 2.3.6. Estructura del documento ............................................................................... 5

2.4. Sección 2 ................................................................................................................ 7 2.4.1. Descripción General del Sistema.................................................................... 7

2.4.1.1. Objetivos del Sistema ............................................................................. 7 2.4.1.2. Funciones del Sistema ............................................................................ 8

2.5. Sección 3 ................................................................................................................ 9 2.5.1. Definición de Requisitos del Sistema............................................................. 9

2.5.1.1. Definición de Requisitos de Almacenamiento o Información................ 9 2.5.1.2. Definición de Requisitos Funcionales .................................................. 10 2.5.1.3. Definición de Requisitos no Funcionales ............................................. 11

2.6. Sección 4 .............................................................................................................. 13 2.6.1. Modelo Funcional......................................................................................... 13

2.6.1.1. Diagrama de Actores ............................................................................ 13 2.6.1.2. Diagramas de Casos de Uso ................................................................. 13 2.6.1.3. Especificación de los casos de uso ....................................................... 14

2.6.2. Modelo Estructural ....................................................................................... 15 2.6.2.1. Diagrama preliminar de clases ............................................................. 15

2.6.3. Modelo Dinámico ......................................................................................... 17 2.6.3.1. Diagramas de Estado ............................................................................ 17 2.6.3.2. Diagramas de Secuencia del sistema como caja negra......................... 18 2.6.3.3. Contratos............................................................................................... 19

2.7. Anexos .................................................................................................................. 23 2.7.1. Catálogo de Reglas de Negocios .................................................................. 23 2.7.2. Diagrama de rastreabilidad Requisitos Funcionales / Casos de Uso........... 24 2.7.3. Diagrama de trazabilidad procesos-requisitos.............................................. 25




ULA

Introducción La presente propuesta, presenta la estructura que debe llevar el Documento de Ingeniería de Requisitos (DIR) elaborado por el Grupo de Ingeniería de Requisitos adscrito a la Unidad de Desarrollo de la Dirección de Servicios de Información Administrativa (UD-DSIA) de la Universidad de Los Andes. Dicho documento constituye la unión de los 2 documentos producidos en esta etapa del desarrollo de software: El DDR (Documento de Definición de Requisitos) y el DER (Documento de Especificación de Requisitos).

El DIR será utilizado por los grupos de Diseño, Programación, Pruebas e Implantación de la UD-DSIA como una guía para los diseños y pruebas de construcción e implantación de sistemas y/o aplicaciones, que pudieran ser desarrollados para las unidades administrativas de esta institución universitaria.

Entre los objetivos que persigue esta propuesta para la definición y especificación de la ingeniería de requisitos de software tenemos:

1. Producir un documento técnico que describa todos los detalles de los requisitos funcionales y no funcionales que la conforman.

2. Servir de insumo para la elaboración del documento de Diseño del sistema.

3. Servir como insumo proporcionando todos los requisitos, definidos y detallados, para el Grupo de Programación, Grupo de Pruebas y el Grupo de Implantación; este último, con el objeto de constituir un soporte sólido para las pruebas de cada uno de los componentes de software de la aplicación o sistema.

4. Servir como material de guía o entrenamiento al nuevo personal que pueda ser incorporado a un proyecto, proporcionando la información necesaria de cómo un requisito debe ser definido y especificado.

1. Estructura del Documento Con la finalidad de producir un documento de ingeniería de requisitos que cumpla con los objetivos antes mencionados, presentamos aquí una propuesta inicial de la estructura de dicho documento, el cual se muestra a continuación:

Portada del Documento

Tabla de Contenido Sección 1 Introducción

1.1. Propósito del documento

1.2. Alcance del Proyecto

1.3. Definiciones, acrónimos y abreviaturas

1.4. Referencias

1.5. Estructura del documento

Sección 2 Descripción General del Sistema

2.1 Objetivos del Sistema




ULA

2.2 Funciones del Sistema

Sección 3 Definición de Requisitos del Sistema

3.1 Definición de Requisitos de Almacenamiento o Información

3.2 Definición de Requisitos Funcionales

3.3 Definición de Requisitos no Funcionales

Sección 4 Modelo Funcional

4.1 Diagrama de Actores

4.2 Diagramas de Casos de Uso

4.3. Especificación de los casos de uso

Modelo Estructural

4.4. Diagrama preliminar de clases

Modelo Dinámico

4.5 Diagramas de Estado

4.6 Diagramas de Secuencia

4.7. Contratos

Anexos Catálogo de Reglas de Negocios

Diagrama de rastreabilidad Requisitos Funcionales / Casos de Uso

Diagrama de trazabilidad procesos-requisitos

2. Descripción de las estructuras del documento

2.1. Portada del documento La portada del DIR contendrá los siguientes elementos:

Nombre del proyecto o sistema: señala el nombre del proyecto, sistema o subsistema que va a ser definido y especificado la ingeniería de requisitos.

Identificador del proyecto: corresponde a un número interno que la organización le asigna a un determinado proyecto.

Versión: es un número compuesto de dos dígitos que hace referencia a la versión del documento de ingeniería de requisitos elaborado para este proyecto. El primer dígito indica la versión del documento, puede ser incrementado cuando el grupo de ingeniería de requisitos considere que han sido realizado cambios importantes que ameriten una nueva versión. El segundo dígito señala que han ocurrido cambios en la versión de un documento, es por ello que éste número comienza en cero para una nueva versión y se incrementa en una unidad cada vez que se publique o entregue un nuevo documento con cambios. Ejemplos: 1.0, 1.3, entre otros.

Autores: lista de las personas que participan en la elaboración del documento de ingeniería de requisitos o el nombre del grupo de ingeniería de requisitos.




ULA

Fecha: índica la fecha en la que se publica está versión del documento entregada formalmente.

2.2. Tabla de Contenido La tabla de contenido del DIR, detalla las diferentes secciones y apartados del documento e indica la página en que cada una de ellas comienza.

2.3. Sección 1

2.3.1. Introducción Esta sección del DIR proporciona al lector una apreciación global de lo que se tratará en este documento. Describe el propósito y alcance de este documento y a quien va dirigido. (1-2 párrafos)

Presenta además, en los siguientes apartados, una visión general del sistema, subsistema o módulo a partir de la definición de los requisitos y su respectiva especificación, a través del modelo funcional, estructural y dinámico. Una lista con las principales definiciones de los términos, acrónimos y abreviaturas, una lista de los documentos que sirven de referencia y por último, un resumen de la estructura u organización de este documento de ingeniería de requisitos.

2.3.2. Propósito del documento Consiste en realizar una breve descripción de la finalidad del documento de ingeniería de requisitos, sin incluir detalles, especificado de manera general.

2.3.3. Alcance del proyecto Breve descripción de la aplicación de software, características u otros subsistemas que puedan asociarse, así como todo aquello que este documento afecte.

2.3.4. Definiciones, acrónicos y abreviaturas Provee la definición de todos los términos, acrónimos y abreviaturas requeridas para poder interpretar apropiadamente de este documento. Puede hacer referencia al Glosario del Proyecto.

2.3.5. Referencias Proporciona una lista de todos los documentos a que hace referencia este documento, identificando a cada documento por título, número de reporte (cuando aplica), fecha, organización que publica. Especificar las fuentes en donde se obtuvieron las referencias. Puede hacer referencia a un Apéndice u otro documento.

2.3.6. Estructura del documento Describa el contenido u organización del documento

Un ejemplo de la redacción de esta sección se muestra a continuación. “1. INTRODUCCIÓN El presente documento comprende la definición de los requisitos relacionados con la determinación de las necesidades y las condiciones a satisfacer para el nuevo Sistema de Control y Ejecución Presupuestaria, tomando en cuenta los distintos requisitos suministrados por los interesados/usuarios del actual Sistema Administrativo de Formulación y Ejecución Presupuestaria (SAFEP). El nuevo sistema deberá contener además de




ULA

las funciones desempeñadas por el SAFEP un conjunto de nuevas funcionalidades que permitirán mejoras del sistema actual y la actualización con respecto a la plataforma de desarrollo.

1.1. Propósito del Documento de Requisitos El presente documento tiene la finalidad de presentar las necesidades e inquietudes de los interesados/usuarios del sistema actual y de esta manera precisar la información relacionada con el descubrimiento, análisis, especificación y validación de los requisitos del sistema orientados al cliente. Una vez determinados y validados los requisitos se continúa con la fase siguiente que consiste en especificar los requisitos para el equipo de desarrollo.

1.2. Estructura general del documento El levantamiento de requisitos se desarrolla en tres fases principales. La primera fase relacionada con el “Descubrimiento de Requisitos (DR)”, en la que se determinan las necesidades que los clientes, usuarios y otros interesados tienen en relación a la aplicación. En la segunda fase, se detalla el “Análisis de Requisitos (AR)” que permite analizar las necesidades identificadas por los clientes y usuarios para la definición de requisitos del sistema. La última fase, “Especificación de requisitos (ER)” orientada a la elaboración del documento de requisitos que servirá de insumo al diseño del software. Para reflejar el trabajo realizado en las tres fases de levantamiento de requisitos, el presente documento se ha estructurado de la siguiente manera:

Sección 1: Introducción, corresponde a la sección actual, donde se especifica el alcance del presente documento.

Sección 2: Descripción general del sistema actual, presenta una visión del sistema existente en cuanto a su función, objetivos y plataforma.

Sección 3: Descripción general del sistema propuesto, presenta la visión general que se tiene sobre el nuevo sistema de control y ejecución presupuestaria.

Sección 4: Definición de Requisitos del Sistema, proporciona los requisitos funcionales y no funcionales del sistema

Sección 5: Especificación de Requisitos del sistema, orientado al desarrollo del sistema en donde se presenta el modelo funcional, estructural y dinámico.

Adicionalmente se tendrá un apartado para glosario de términos. Finalmente, la Bibliografía, que permite la documentación de las referencias e investigaciones en textos

y documentos para el desarrollo del presente documento.”

Otro ejemplo es el siguiente: “I Prólogo

El desarrollo del software es una de las actividades más complejas y más orientadas al cliente de las desarrolladas por la industria en nuestros días. Para poder resolver la complejidad creciente de los sistemas, y obtener la calidad demandada por los clientes, los desarrolladores de sistemas de información han de seguir métodos más rigurosos de ingeniería y dirección de los proyectos de software. El primer paso para la consecución del éxito en el desarrollo de software es una correcta especificación de los requisitos.

Es conveniente disponer de métodos y herramientas que soporten la ingeniería de requisitos. El método describirá una aproximación general para obtener la especificación de los requisitos. La herramienta permitirá la implementación del método. Parte del método tendrá que ser realizada manualmente.

Se propone un método de especificación de requisitos mediante el uso de escenarios obtenidos a partir de necesidades del cliente u objetivos de negocio. Los escenarios son modelados utilizando los conceptos de actores y casos de uso, definidos en el marco del estándar de UML. Los requisitos no funcionales son representados de forma textual pero no se permite una utilización ambigua del lenguaje ni de los términos utilizados.

La presente especificación de requisitos pertenece al desarrollo del "Sistema Integrado de información utilizado para el registro y control de la Relación de Cargos de la Universidad de Los Andes", siguiendo las directrices establecidas por la propuesta del método de desarrollo de software de la DSIA en la fase de Ingeniería de Requisitos y de la propuesta del documento de especificación de requisitos, ambos desarrollados por el grupo de Diseño de la DSIA.

II Introducción

II.1 Propósito del documento

El propósito del presente apartado es definir los requisitos de información, funcionales y no funcionales que debe tener el Sistema Integrado de información utilizado para el registro y control de la Relación de Cargos de la Universidad de Los Andes. Como su nombre indica abordará lo referente a la gestión de cargos y tabuladores.

El propósito de esta especificación de requisitos es formalizar funcionalidades del sistema junto al usuario.




ULA

II.2 Alcance del Proyecto

El sistema a desarrollar se relaciona con la administración de los cargos de la Universidad de Los Andes, interactuando con los sistemas de Recursos Humanos, Presupuesto (SAFEP) y Nómina (ULA-SIPNOM), de la Universidad. Del Sistema de Recursos Humanos, utiliza los datos personales y la situación administrativa del trabajador, conjuntamente con el manual de cargos del personal administrativo y obrero y del personal docente y de investigación; del sistema de Presupuesto, la estructura organizativa, la estructura por proyectos y el clasificador presupuestario de egresos de los movimientos tipo 2 y tipo M; del sistema de Nómina, los conceptos de nómina definidos y los tabuladores de sueldo.

II.3 Definiciones, acrónimos y abreviaturas

• Movimiento de personal es un acto administrativo que produce un documento escrito, el cual pasa por diferentes instancias formales de aprobación (Directores, Jefes de departamento, Director de personal, Coordinador de la OAP, Consejo Universitario, entre otros). Este documento, lleva por nombre “planilla de Asuntos Profesorales OAP Niro.”, cuando se trata de movimientos para personal DI, y “Decreto rectoral” cuando se trata de movimientos para personal AO; ambos, conllevan en su aplicación cambios para diferentes datos relacionados con el trabajador y su ocupación laboral en la Universidad.

… II.4 Referencias

1. Fernando Arango I. y Carlos Mario Zapata J., Un-método para la Elicitación de Requisitos de Software, 2006, Escuela de Sistemas, Universidad Nacional de Colombia Medellín, Colombia.

2. Amador Durán Toro y Beatriz Bernárdez Jiménez, Metodología para el Análisis de Requisitos de Sistemas Software Versión 2.2, 2001, Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica Superior de Ingeniería Informática, Universidad de Sevilla

3. Amador Durán Toro y Beatriz Bernárdez Jiménez, Metodología para la Elicitación de Requisitos de Sistemas Software Versión 2.3, 2002, Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica Superior de Ingeniería Informática, Universidad de Sevilla

4. Carlos Mario Zapata J., Sandra Milena Villegas S. y Fernando Arango I., Reglas de Consistencia entre Modelos de Requisitos de UN-METODO, 2006, Universidad Eafit, enero -marzo, año/Vol. 42, número 141 Universidad Eafit Medellín, Colombia pp. 40-59

5. Carlos Mario Zapata J., Alexander Gelbukh Fernando y Arango Isaza, UN–Lencep: Obtención Automática de Diagramas UML a partir de un Lenguaje Controlado, 2006, Universidad Nacional de Colombia.

6. Montilva, J. Curso Ingeniería de Requisitos. CEISoft, 2006.

7. Montilva , J. Desarrollo de Aplicaciones Empresariales, El Método WATCH, versión 2004. Mérida, 2004.

8. Montilva, J. y Barrios, J. WATCH: El Método del Reloj. Mérida, 2005.

9. Jacobson, I. y Booch, G y Rumbaugh, J. El Proceso Unificado de Desarrollo de Software. Addison Wesley. 1999.

10. Pressman, R. Ingeniería del Software. Un enfoque práctico. Sexta edición. Mc Graw Hill. 2006.

11. Schach, S. Análisis y Diseño Orientado a Objetos con UML y el Proceso Unificado. Mc Graw Hill. 2005.

12. Prieto C., Ramón E. Sistematización del área de los Recursos Humanos en la Universidad de Los Andes. Universidad de Los Andes. Vicerrectorado Administrativo. Dirección de Servicios de Información Administrativa (D.S.I.A.). Mérida. Venezuela. 2005.”

2.4. Sección 2

2.4.1. Descripción General del Sistema En esta subsección se realiza una descripción general del sistema, partiendo de los objetivos del sistema y sus funciones.

2.4.1.1. Objetivos del Sistema Se identifican la finalidad hacia la cual se deben dirigir los recursos y esfuerzos para dar cumplimiento al desarrollo del sistema de información, indicando entre otra cosas, la misión, visión, objetivos(s) general(es) y objetivo(s) especifico(s).




ULA

2.4.1.2. Funciones del Sistema Describa de manera general las funciones a realizar por el sistema, referidas a la captura, almacenamiento, procesamiento y distribución de la información.

Un ejemplo de la redacción de ésta sección se muestra a continuación: “III Descripción General del Sistema

III.1 Propósito general del sistema.

La Relación de cargos tiene por objeto, llevar el Control e Inventario de todos los cargos, conceptos y movimientos, tanto del Personal Docente y de Investigación (PDI) y del Personal Administrativo y Obrero (PAO), de la Universidad de Los Andes.

La función primordial de la relación de Cargos es la de servir de insumo a otros sistemas intra y extra universitarios. Así tenemos que para la Dirección de Programación y Presupuesto, la relación de cargos se utiliza como insumo, tanto para el sistema de Formulación Presupuestaria como para el sistema de Ejecución y Control Presupuestario.

En este proyecto se plantea la sistemización de los procesos que se llevan a cabo en la relación de cargos. Esto será de gran utilidad, debido a que permitirá agilizar los procesos con el propósito de: (1) hacer que el acceso de la información sea más rápido tanto para el personal usuario como para el personal que opera el sistema; y (2) hacer que las estadísticas y listado se realicen con mayor fluidez y exactitud; entre otros.

III.2 Alcance del sistema

Con la finalidad de producir la infraestructura tecnológica de información que sirva de apoyo a la toma de decisiones a nivel estratégico, táctico y operativo, este proyecto permitirá concebir el Sistema Integrado de Información de la Relación de Cargos, el cual está conformado por los siguientes subsistemas:

• Subsistema para la Administración de los Cargos de la Universidad de Los Andes, el cual parte desde la creación de un cargo y sus conceptos (antigüedad, titularidad y premio estímulo, entre otros) y su clasificador presupuestario de egreso asignado; seguidamente se debe llevar la permanencia del cargo, el cual se encuentra conformado por la asignación del cargo a un personal de la universidad y los distintos movimientos (cambios) de denominación que puedan ocurrir; y, por ultimo la finalización del ciclo de vida del cargo, que ocurre cuando el pensionado o jubilado fallece.

• Subsistema para la Formulación de los Cargos de la Universidad de los Andes, el cual parte de la proyección de cargos para el siguiente período fiscal, acordes a los lineamientos establecidos por la OPSU-CNU-ULA, mediante la previsión y provisión de cargos, asegurando de esta manera el presupuesto de los cargos ocupados y vacantes de la ULA.

• Portal de Información de la Relación de cargos.

III.3 Objetivos del Sistema

El Subsistema para la Administración de los Cargos de la Universidad de Los Andes, que sirve de soporte al proceso de “Ejecución y Control de la Relación de Cargos”, dará apoyo a los procesos y actividades llevados a cabo en el área de Ejecución y Control de la Dirección de Programación y Presupuesto de la ULA, con la finalidad de:

Realizar el seguimiento y control a los procesos de creación, permanencia y finalización de los cargos tanto fijos como temporales de la Universidad de Los Andes para el período fiscal vigente.

Aplicar la normativa para la permanencia de los cargos de la ULA.

Consolidar datos y presentar resultados sobre los movimientos de los cargos de la ULA.

Dar información sobre los cargos de la Universidad de Los Andes.

Servir de insumo para el procesamiento de los Pagos de Nómina.

Servir de insumo para el procesamiento de la Formulación Presupuestaria.

Servir de insumo para el procesamiento de la Ejecución Presupuestaria.

El Subsistema para la Formulación de los Cargos de la Universidad de Los Andes, que sirve de soporte al proceso de “Elaboración del Anteproyecto/Proyecto de la Formulación de la Relación de Cargos”, dará apoyo a los procesos y actividades llevados a cabo en el área de Formulación Presupuestaria de la Dirección de Programación y Presupuesto de la ULA, con la finalidad de:

Realizar la Previsión y Provisión de cargos para el siguiente período fiscal presupuestario.

Aplicar los lineamientos establecidos por la Oficina de Planificación Universitaria, el Consejo Nacional de Universidades y la Universidad de Los Andes.




ULA

Consolidar datos y presentar resultados sobre la previsión y provisión de los cargos de la ULA.

Dar información sobre los cargos proyectados de la Universidad de Los Andes.

Servir de insumo para la Ejecución Presupuestaria del siguiente período fiscal.

El Portal de Información de la Relación de Cargos ofrecerá a los Autoridades de la ULA (Equipo Rectoral, Consejo Universitario, entre otros), así como otras unidades organizativas dentro y fuera de la institución, la posibilidad de realizar consultas sobre toda la información disponible.”

2.5. Sección 3

2.5.1. Definición de Requisitos del Sistema Esta sección se divide en las siguientes subsecciones, que permiten describir los requisitos del sistema. Cada uno de los grandes grupos de requisitos, de información, funcionales y no funcionales

2.5.1.1. Definición de Requisitos de Almacenamiento o Información Se entiende por requisitos de información los datos que se deben capturar y almacenar.

Esta subsección debe contener la lista de requisitos de almacenamiento y de restricciones de información que se hayan identificado.

El objetivo fundamental consiste en la identificación de los requisitos de información, indicando las restricciones de información o reglas de negocio que deberán cumplir en el sistema software a desarrollar

Se debe definir estrategias que ayudan a los clientes y usuarios a responder a las preguntas "¿qué información, relevante para los objetivos de su negocio, debe ser almacenada por el sistema? "¿qué restricciones o reglas de negocio debe cumplir dicha información?"

Un ejemplo de la redacción de ésta subsección se muestra a continuación:

Código Nombre Descripción Tipo de requisito Prioridad Estado Riesgo Restricciones

El sistema deberá almacenar lainformación correspondiente a el tipode personal que existe en la ula. Enconcreto:

El tipo de personal es:

• Tipo de personal • Pdi personal docente y deinvestigación

• Descripción • Pao personaladministrativo y obrero

El sistema deberá almacenar lainformación correspondiente a laescla de los cargos en concreto:• Tipo de personal

• Escala

• DescripciónEl sistema deberá almacenar lainformación correspondiente a losniveles o categorias. En concreto:

• Para el personal pdi seutiliza el termino categoría

• Tipo de personal • Para el personal pao seutiliza el término nivel

• Escala • Una escala puedecontener 1 o más niveles.

• Nivelcategoria

• DescripciónEl sistema deberá almacenar lainformación correspondiente a eltabulador de cargos. En concreto: • Código del tabulador

• Descripción

• Tipo de personal

• Fecha de inicio

• Número de resolución

• Fecha del decreto

• Monto del tabulador

• Observación

Por aprobar Alto El tabulador esta definido portipo de personalRi-004 Tabulador de

cargos Información 5

Para cada tipo de personalexiste(n) su(s) escala(s)

Ri-003 Nivelcategoria Información 5 Por aprobar Alto

Por aprobar Alto

Ri-002 Escala Información 5 Por aprobar Alto

Ri-001 Tipo de personal Información 5




ULA

2.5.1.2. Definición de Requisitos Funcionales Un requisito funcional define el comportamiento interno del software: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que establecen los comportamientos del sistema.

Esta subsección debe contener la lista de requisitos funcionales, expresados de la forma tradicional o mediante casos de uso, que se hayan identificado

Se identifican los requisitos funcionales, expresados de forma tradicional que deberá cumplir el sistema software a desarrollar. Esto permite ayudar a los clientes y usuarios a responder a la pregunta "¿qué debe hacer el sistema con la información almacenada para alcanzar los objetivos de su negocio?".

La estrategia para descubrir (elicitar) esos requisitos depende de la capacidad del analista de software de utilizar adecuadamente herramientas que le permita la captura de esa información, entre éstas, tenemos entrevistas, cuestionarios (abiertos o cerrados), lluvia (tormenta) de ideas, entre otros, para extraer de usuarios y clientes la información adecuada. Además, de existir documentación (Manuales de Normas, Procesos y Procedimientos, Manuales de Modelados de Negocios, entre otros) para definir las actividades a automatizar como requisitos de información.





ULA

ID del Requisito

Nombre del Requisito

Descripción del Requisito UsuarioFuente

Requisito (P; S; U)

Documentos de Soporte

Reglas de Negocio

Medio Observación

RF-001Registrar usuarios.

El sistema debe permitir que el administrador/coordinador realice el registro de un usuario en el sistema de acuerdo a la labor que desempeña dentro del mismo.

Administrador del sistema

(U) Administración de usuarios

solicitud de apertura de cuenta a usuario

En Línea

RF-002Asignar Roles/Perfiles.

El sistema debe garantizar el ingreso de usuarios por medio de la definición de roles, por tanto debe solicitar el nombre de usuario y la contraseña; permitiendo el acceso solo a los usuarios registrados, de acuerdo al rol que desempeña dentro del sistema.



RNF-007 En Línea

RF-003Modificar datos de usuario.

El sistema debe permitir que el administrador/coordinador realice modificación de datos de usuario en el sistema.



solicitud de modificación de datos de usuario

En Línea

RF-004Eliminar usuarios consulta.

El sistema debe permitir que el administrador/coordinador elimine el registro de usuario consulta en el sistema.



solicitud de eliminación de cuenta a usuario

En Línea

2.5.1.3. Definición de Requisitos no Funcionales Los requisitos no funcionales no se refieren a funciones específicas que proporciona el sistema, son restricciones de los servicios o funciones ofrecidas por el sistema (fiabilidad, tiempo de respuestas, capacidad de almacenamiento, etc.)⎫, generalmente se aplican al sistema en su totalidad y surgen de las necesidades del usuario (restricciones de presupuesto, políticas de la organización, necesidad de interoperatividad, etc.)⎫

Esta subsección debe contener la lista los requisitos no funcionales del sistema que se hayan identificado del sistema software a desarrollar (explicar mejor que es un requisito no funcional)

Algunos tipos de requisitos que se suelen incluir en esta sección son los siguientes:

Restricciones de diseño: Se indica la plataforma tecnológica con la que se desarrollará la herramienta y la arquitectura lógica.




ULA

Interfaces de usuario: Se especifica el Diseño de interfaz gráfica, la Resolución y los Reportes

Requisitos del Sistema: Se define la Red de datos, los Requerimientos mínimos y la Base de datos

Requisitos de Desempeño: Se establece los Ingresos concurrentes, el Tiempo de respuesta, el Tiempo transacción y el Tiempo de falla

Documentación del sistema: Se documenta el Manual de usuario, el Manual de administrador, el código fuente y la Ayuda en línea

Atributos de calidad: Se refiere a requisitos de calidad que el sistema debe tener: Confiabilidad: Nivel de actuación, Confiabilidad: Tiempo disponible, Confiabilidad: almacenar errores, Confiabilidad: almacenar contenido de operaciones, Disponibilidad: accesible y usable siempre que se requiera, Seguridad: Control de acceso al sistema, Seguridad: Validación de acceso, Seguridad: Cambio de contraseña, Seguridad: Políticas de seguridad, Usabilidad: Facilidad de manejo, Usabilidad: Interfaces de usuario, Usabilidad: información de errores al usuario, Mantenibilidad: Facilidad de mantenimiento, Flexibilidad: incorporar mejoras o modificaciones, Interoperabilidad: acoplar el sistema con otros, Trazabilidad: Registro de histórico.


Tipo de RequisitoID del

RequisitoNombre del Requisito Descripción del Requisito Observación

RNF-001 Plataforma de desarrollo La aplicación se desarrollará con la herramienta Pendiente por definir

RNF-002 Arquitectura lógica

El sistema deberá considerar una arquitectura lógica de tres capas: Capa de presentación (cliente), capa de negocio (servidor de negocio) y capa de datos (servidor de base de datos).

RNF-003 Diseño de interfaz gráficaEl diseño de la interfaz gráfica del sistema se alineará a lasexigencias de la unidad de control presupuestario.

RNF-004 ResoluciónLa resolución mínima para una buena visualización yejecución del sistema será un tamaño de pantalla de800x600 píxel.

RNF-005 ReportesLos reportes mostrarán un encabezado con logotipo ynombre de la UCP, ULA.

Restricciones de diseño

Interfaces de usuario




ULA

2.6. Sección 4

2.6.1. Modelo Funcional Se presenta en esta sección los diagramas de actores, los diagramas de casos de uso y la especificación de los casos de uso, partiendo de una arquitectura lógica preliminar.

2.6.1.1. Diagrama de Actores Se le llama actor a toda entidad externa al sistema que guarda una relación con éste y que le demanda una funcionalidad. Esto incluye a los operadores humanos pero también incluye a todos los sistemas externos, además de entidades abstractas, como el tiempo.

En el caso de los seres humanos se pueden ver a los actores como definiciones de rol por lo que un mismo individuo puede corresponder a uno o más Actores. Suele suceder sin embargo, que es el sistema quien va a tener interés en el tiempo. Es frecuente encontrar que nuestros sistemas deben efectuar operaciones automáticas en determinados momentos; y siendo esto un requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho requisito en el modelo de caso de uso final

Aquí se identifican los actores del sistema conjuntamente con los roles que cumplen, considerando: cuáles requieren ayuda del sistema para ejecutar sus tareas, cuáles son necesarios para ejecutar las funciones del sistema, cuáles interactúan con hardware externo u otros sistemas de software, y cuáles ejecutan funciones secundarias para administración y mantenimiento.

Se debe organizar actores que son similares a algún otro en una herencia generalización/especificación.

Un ejemplo de la redacción de ésta subsección se muestra a continuación: Act-01 Administrador del sistema de ejecución presupuestaria (SEP) Descripción Este actor representa a la persona encargada de la gestión de los usuarios, configuración y

mantenimiento del sistema. Símbolo uc Actores

Act-01 Administrador del

SEP

2.6.1.2. Diagramas de Casos de Uso Los diagramas de caso de uso son uno de los cinco tipos de diagramas en UML para modelar aspectos dinámicos de sistemas (diagramas de actividad, diagramas de estados, diagramas de secuencia y diagramas de colaboración son otros cuatro tipos de diagramas en UML para modelar los aspectos dinámicos de un sistema). Los diagramas de casos de uso son importantes para modelar el comportamiento de un sistema, un subsistema o una clase. Cada uno muestra un conjunto de casos de uso, actores y sus relaciones.

Se aplican los diagramas de casos de uso para modelar las vistas de casos de uso de un sistema. Para la mayor parte, esto involucra el modelado el contexto de un sistema, subsistema, o clase, o modelar las necesidades del comportamiento de esos elementos.

Los diagramas de casos de uso son importantes para visualizar, especificar, y documentar el comportamiento de un elemento. Ellos hacen sistemas, subsistemas, y clases entendibles para presentar una vista exterior de cómo estos elementos pueden ser usados dentro del contexto. Los




ULA

diagramas de caso de uso son también importantes para probar sistemas ejecutables a través de ingeniería hacia adelante y para comprender sistemas ejecutables a través de ingeniería inversa.

Un ejemplo de ésta subsección se muestra a continuación: uc Administrar Usuarios

Sistema de Ejecución Presupuestaria

CU-001 Registrar Usuario

Act-01 Administrador del

SEP

CU-002 Modificar usuario

CU-003 Eliminar Usuario

CU-004 Consultar usuario

CU-005 Imprimir usuario

CU-006 Cambiar clav e de usuario

«extend»

«extend»

«extend»

«include»

2.6.1.3. Especificación de los casos de uso Partiendo de la premisa que ya se identificaron los actores y casos de uso apropiados del sistema, lo que corresponde es detallar los pasos necesarios para cumplir con dicho caso de uso.

Para especificar cada caso de uso deberíamos de tomar en consideración los siguientes aspectos:

Interacciones. Mencionar la participación del actor primario y la de cada actor secundario desde que inicia el caso de uso hasta que termina.

Eventos. Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos, capturas, cálculos, entre otros.)

Nivel de detalle. Los casos de uso y sus especificaciones son la base del contrato que establecemos con nuestro cliente, por lo que debemos de buscar especificarlo al máximo detalle. Recuerda que entre más sepamos de la funcionalidad del sistema más precisas serán las estimaciones de nuestro plan de trabajo.

Escenarios. Un caso de uso muestra diferentes escenarios posibles y no una sola forma de ejecutarlo. Debemos de explicar cada uno de esos escenarios, mediante un flujo principal y sus diferentes flujos alternos y excepcionales.

Claridad y Enfoque de Usuario. Busca claridad en la explicación de los casos de uso utilizando la jerga de negocio a la hora de redactarlo sin mencionar detalles técnicos a los que no está acostumbrado.

Generalmente, se recomiendan varios elementos adicionales para documentar los casos de uso. Pero lo esencial es lo que se mencionó en el párrafo anterior. A continuación se sugieren algunos elementos extras con los cuales se puede complementar la plantilla para documentar las especificaciones de casos de uso.

Propósito. Se definen los pasos más relevantes para ejecutar el caso de uso.




ULA

Precondiciones. Indica las condiciones o estados en que se debe encontrar el sistema antes de ejecutar el caso de uso. (Ejemplo: Algún catálogo debe estar actualizado, debe estar en conexión con otro sistema, el usuario debe estar conectado con cierto perfil específico)

Postcondiciones. Indica cómo queda el sistema después de ejecutar el caso de uso. Por ejemplo, un tester quiere comprobar si alguien acaba de ejecutar el caso de uso. ¿Qué cosas buscaría en el sistema? Seguramente datos nuevos, modificados, eliminados o la posibilidad de elegir nuevas opciones en el sistema.

Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso especificado.

Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una relación de <<extend>>.

Excepciones. Puntos que especifican qué acciones se realizarán para el manejo de condiciones erróneas.

Un ejemplo de ésta subsección se muestra a continuación:

CU-010 Crear un nuevo tipo movimiento Descripción CU-010 Permite que el Coordinador de la UCP pueda crear un nuevo tipo de movimiento presupuestario.

Actores CU-010 Coordinador de la UCP Requisitos Asociados CU-010 RF-012 PreCondición CU-010 Documento de aprobación de creación de un nuevo movimiento presupuestario.

Flujo Normal CU-010 1. El Coordinador de la UCP solicita al sistema iniciar el proceso de creación de un tipo de movimiento

presupuestario. 2. El sistema solicita los siguientes datos correspondientes a un nuevo tipo de movimiento presupuestario: Tipo de

movimiento, descripción y regla que aplica. 3. El Coordinador de la UCP suministra los datos y solicita al sistema se almacene el tipo de movimiento

presupuestario. 4. El sistema valida que el tipo de movimiento no se encuentre registrado. 5. Si no está registrado, el sistema almacena los datos del nuevo tipo de movimiento e informa al Coordinador de la

UCP que el proceso ha finalizado con éxito. Flujo Alternativo CU-010 3a. Si el Coordinador de la UCP solicita cancelar el proceso, el sistema cancela el proceso y termina el caso de uso. 5a. Si el tipo de movimiento presupuestario esta registrado, le informa al Coordinador de la UCP de la situación y

vuelve al paso 2. PostCondición CU-010 Tipo de movimiento presupuestario creado.

2.6.2. Modelo Estructural En esta sección se presenta el diagrama preliminar de clases, también denominado modelo de dominio o modelo conceptual.

2.6.2.1. Diagrama preliminar de clases En ésta subsección se desarrolla lo que podemos llamar diagrama preliminar de clases. Lo que importa es lograr el objetivo de comprender el dominio (contexto del problema) con el beneficio indirecto de estar estableciendo las posibles clases del sistema. Ya en el ciclo de diseño este diagrama preliminar será usado como una base a refinar para determinar las clases definitivas a implementar en el sistema.




ULA

Los elementos principales a mostrar en el diagrama preliminar de clases son:

Conceptos o clases. Elemento lógico o físico que ayuda a entender el problema, es parte del lenguaje utilizado por el cliente y generalmente se nombra como sustantivo. Se representan con el símbolo de una clase. Ejemplo: Cliente, Póliza y Domicilio.

Atributos. Información que caracteriza al concepto en el mundo real. Se muestra en el segundo compartimiento de las clases. Ejemplo: Nombre, apellidos y edad del cliente.

Asociaciones. Relaciones lógicas o físicas que existen en el mundo real entre dos conceptos. Si se puede armar una frase con dos conceptos significa que se pueden representar mediante una relación de asociación entre esos dos conceptos. Se puede colocar el verbo que se usa para relacionar los conceptos en la frase, indicándolo sobre la asociación con una punta de una flecha para indicar la dirección en que se debe leer la frase. Ejemplo: La Póliza cubre-a un cliente asegurado, el cliente vive-en un domicilio.

Rol. También permite aclarar la relación entre dos conceptos, indica el rol que juega un concepto con respecto a otro en una relación de asociación. Ejemplo: PlanesAplicables al cliente.

Multiplicidad. Indica número de instancias de un concepto relacionados con otro concepto. Ejemplo: Una póliza tiene una lista de uno a diez beneficiarios.

Generalización. En lugar de poner una asociación para armar la frase “es-un-tipo-de” se puede poner una generalización. Ejemplo: El Plan Oro es un tipo de plan de seguro de vida, al igual que el plan tradicional.

Agregación y composición. Indican una relación donde uno de los conceptos es el contenedor del otro. Ejemplo: la póliza contiene una ListaBeneficiarios.





ULA

class Diagrama de clases

«datos»Nómina de Pago

+ dep: char+ proy: char+ ff: char+ cpe: char+ id_personal: char+ cod_nomina: char+ monto: double

«información»Resumen de la Nómina Pagada

Mov imientoPresupuestario

+ dep: char+ num_cp: char+ concepto: char+ fecha: char

Conv ersiónNómina

+ id_personal: char+ cod_nomina: char+ descripcion: char+ tipo_cuenta: char+ dep: char+ proy: char+ ff: char+ cpe: char

Presupuesto

+ asignacion_inicial: double+ asignacion_actual: double

«id»+ ano: int

ClasificadorPresupuestarioEgreso

+ cod_cpe: char+ descripcion: char+ fecha_act: char+ fecha_fin: char

EstructuraOrganizativ a

+ cod_dep: char+ descripcion: char+ fecha_act: char+ fecha_fin: char

EstructuraProyecto

+ cod_proy: char+ descripcion: char+ fecha_act: char+ fecha_fin: char

FuentesFinanciamiento

+ cod_ff: char+ descripcion: char+ fecha_act: char+ fecha_fin: char

Usuario

+ nombre: char+ apell ido: char+ ced_ide: int+ ubicacion: char+ nom_usuario: char- contrasena: char+ rol_usuario: char+ estatus: char

TipoMov imiento

+ cod_mov: char+ descrip_mov: char

DetallesMov imientos

+ dep: char+ num_cp: char+ proy: char+ cpe: char+ concepto: char+ monto: double+ fecha: char

Diagrama Preliminar de Clases del Sistema de Ejecución Presupuestario

DetalleTraspaso

+ dep_orig: char+ proy_orig: char+ cpe_orig: char+ dep_dest: char+ proy_dest: char+ cpe_dest: char+ num_cp: char+ monto: double+ estado: char

ControlMov imientoLote

Afecta

1

Se-convierte-en

1

Esta-asociado

*

1

Está-compuesto

* *

Afecta

1Gestiona

1..*

2.6.3. Modelo Dinámico En esta sección se presenta el diagrama de estado y diagrama de secuencia.

2.6.3.1. Diagramas de Estado Los diagramas de estado describen gráficamente los eventos y los estados de los objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso.

Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condición de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transición es una relación entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.





ULA

stm DE mov imientos presupuestarios

Diagramas de estado: Movimientos presupuestarios

No Procesado "NP"

Inicio

Registro Web "RW"

Presupuesto afectado

Rechazado "RR"

Anulado "AN"

Fin

Donde

Result

[Ordenanular mov]

[No cumple reglas,rechazar mov]

[Cumple reglas,afectar presupuesto]

[Revisar]

[Confirmaciónen UCP]

[Desde UCP]

[Via Web]

[ingresarmovimientos]

2.6.3.2. Diagramas de Secuencia del sistema como caja negra El Diagrama de Secuencia de un sistema muestra gráficamente los eventos que fluyen de los actores al sistema. Se preparan durante la fase del análisis. Para su creación, debemos formular antes los Casos de Uso.

Antes de iniciar el diseño lógico de cómo funcionará una aplicación de software, es necesario investigar y definir su comportamiento como una “caja negra”. El comportamiento del sistema es una descripción de lo que hace, sin explicar la manera en que lo hace. Una parte de la descripción es un Diagrama de la Secuencia del sistema.

Los casos de uso indican cómo los actores interactúan con el Sistema de Software. Durante esa interacción un actor genera eventos dirigidos al sistema, solicitando alguna operación a cambio.

Conviene aislar y explicar gráficamente las operaciones que un actor solicita al sistema, porque ello contribuye a entender el comportamiento del sistema.

DIAGRAMA DE SECUENCIA => Representación que muestra, en un determinado Caso de Uso, los eventos generados por actores externos, su orden y los eventos internos del sistema.

A todos los sistemas se los trata como una caja negra; los diagramas se centran en los eventos que trascienden las fronteras del sistema y que fluyen desde los actores hacia los sistemas.

El Diagrama de Secuencia debe prepararse para el curso normal de los eventos de un caso de uso y los cursos opcionales más interesantes.

El Diagrama de la Secuencia de un sistema describe, en el curso de los eventos de un caso de uso, los actores externos que interactúan directamente con el sistema (caja negra) y con los eventos del sistema generados por esos actores.




ULA

sd 3.2.2 Diagrama de estado de Validar Acceso

sistema

Usuarios

Diagramas de secuencia: Validar acceso

solicita ingresar al sistema()

solicita datos de usuario()

introduce datos solicitados()

permite acceso al sistema()

solicita cambio de clave()

solicita nueva clave()

introduce nueva clave()

mensaje de clave cambiada()

2.6.3.3. Contratos Los Contratos contribuyen al definir el comportamiento de un Sistema: describen el efecto que sobre él tienen las operaciones.

Los Contratos de las Operaciones del Sistema se elaboran durante la fase de Análisis. Su preparación depende de contar antes con el Modelo Conceptual, de los Diagramas de Secuencia del Sistema y la identificación de sus Operaciones.

Antes de emprender el diseño lógico de cómo funcionará una aplicación de software, es necesario investigar y definir su comportamiento como una “caja negra”.

El comportamiento del sistema es una descripción de lo que hace, sin explicar la manera que (cómo) lo hace.

Los contratos son documentos muy útiles, que describen el comportamiento de un sistema a partir de cómo cambia el estado de un sistema cuando se llama una operación suya.

El Diagrama de Secuencia de un sistema muestra los eventos generados por un actor externo, pero no profundiza en los detalles del funcionamiento de las operaciones invocadas. No contiene los detalles necesarios para entender la respuesta del sistema, o sea su comportamiento.




ULA

Contrato => Documento que describe lo que una operación propone lograr. Se redacta en estilo declarativo, enfatizando lo que sucederá y no cómo se conseguirá. Los contratos suelen expresarse a partir de los cambios de estado de las poscondiciones.

El Contrato describe los cambios del estado del sistema total cuando se invoca a una de sus operaciones.


Ejemplo de un contrato para una operación llamada: introducirProducto

Nombre: introducirProducto(cup:numero, cant:entero)

Responsabilidades: Capturar (registrar) la venta de un producto y agregarla a la venta. Desplegar la descripción y el precio del producto.

Tipo: Sistema

Referencias Cruzadas: Funciones del Sistema: R1.1, R1.3, …

Casos de Uso: comprarProductos

Notas Utilizar el acceso super rápido a la Base de Datos.

Excepciones Si el CUP no es válido, indicar que se cometió un error.

Salida

Precondiciones El sistema conoce el CUP.

Postcondiciones: · Si se trata de una nueva venta, se creó una Venta (creación de instancia).

· Si se trata de una nueva venta, la nueva Venta fue asociada a TPDV (asociación formada).

· Se creó una instancia VentasLineasdeProductos (creación de una instancia).

· Se asoció una instancia VentasLineasdeProductos a la Venta (asociación formada).

· Se asignó cantidad a VentasLineadeProducto.cantidad (modificación de atributo).

· Se asoció una instancia VentasLineadeProducto a la instancia EspecificacióndeProducto, basado esto en la correspondencia del CUP (asociación formada).

Otro ejemplo de ésta subsección se muestra a continuación: Para el caso de un Videoclub se realizarán estas tareas:

1. Por cada Curso Normal de Eventos, se realizará el correspondiente Diagrama de Secuencia.

2. A partir de los Diagramas de Secuencia, se identificarán a las Operaciones del Sistema y se confeccionará un Contrato.

Sistema

introducirProducto()terminarVenta()efectuarPago ()

Se redactan contratos para cada operación del sistema, con el fin de describir su comportamiento.

Se redactan contratos para cada operación del sistema, con el fin de describir su comportamiento.




ULA

Caso de Uso: Alquiler de Video

Actores: Empleado (Iniciador)

Propósito: Dejar registrado que un socio alquiló X película

Resumen: : Un socio llega a la CAJA con los videos que quiere alquilar. El Empleado ingresa los videos y cobra el importe. Al terminar la operación, el socio se marcha con los videos y el comprobante.

Tipo: Primario y Esencial

Referencias

Cruzadas

Funciones: R1.1., R1.2., R1.3., R1.6., R1.7.

Acción del actor Respuesta del sistema 1. Este caso de uso comienza cuando un Socio llega a la caja con videos para alquilar

2. El Empleado introduce el código del Socio.

3. Completa el nombre y domicilio del socio. Informa de multas pendientes.

4. El Empleado captura el código de video de cada video.

5. Confirma el precio del video y agrega el título de éste a la transacción.

6. El Socio confirma que no quiere mas videos.

7. El Empleado le indica al sistema que no se cargarán más videos.

8. Calcula el total y registra el alquiler.

9. El Socio ofrece un pago quizás mayor que el total.

10. El empleado ingresa el monto ofrecido.

11. Calcula el saldo, registra el pago y emite el ticket.

Curso normal de los eventos:

12. El Socio recibe los videos, el ticket y se retira.

Curso alterno de los eventos: Línea 2: El Cliente no es socio. Error. Ver Caso de Uso: Alta de Socio. Línea 3: El Socio tiene una multa no pagada. Ver Caso de Uso: Multas. Línea 4: Código de video inexistente. Indicar Error. Línea 8: El Cliente no tiene el dinero necesario para pagar. Se cancela la operación.

Diagrama de la secuencia para el caso de uso Alquiler de Video.

Cajero :Sistema

introducirSocio (codigo)

terminarTransacción()

efectuarPago (monto)

introducirVideo (codigo)


Curso Normal de los eventos

1. Este caso de uso comienza cuando un Socio llega a la caja con videos para alquilar.

2. El Empleado ingresa el código del Socio.


4. El Empleado ingresa el código cada video.


6. Y así sucesivamente...

CajeroCajero :Sistema

introducirSocio (codigo)

terminarTransacción()

efectuarPago (monto)

introducirVideo (codigo)


Curso Normal de los eventos

1. Este caso de uso comienza cuando un Socio llega a la caja con videos para alquilar.

2. El Empleado ingresa el código del Socio.


4. El Empleado ingresa el código cada video.


6. Y así sucesivamente...




ULA

Contrato para introducirVideo

Nombre: introducirVideo (codigo: número)

Responsabilidades: Capturar (registrar) el alquiler de un video y agregarlo al alquiler. Desplegar el título y el precio del video.

Tipo: Sistema

Referencias Cruzadas: Funciones del sistema: R1.1, R1.3,....

Casos de uso: Alquiler de Videos.

Notas Utilizar el acceso super rápido a la Base de Datos.

Excepciones Si el código no es válido, indicar que se cometió un error..

Salida

Precondiciones El sistema conoce el código de video.

Postcondiciones: • Se creó una instancia AlquilerLineadeVideo (creación de una instancia).

• Se asoció una instancia AlquilerLineasdeVideo al Alquiler (asociación formada).

• Se asoció una instancia AlquilerLineadeVideo a la instancia EspecificacióndeVideo, basado ésto en la correspondencia del código (asociación formada).

• Se modificó el atributo Video.Estado = alquilado (modificación de atributo)




ULA

2.7. Anexos

2.7.1. Catálogo de Reglas de Negocios En este anexo se definen y especifican el inventario de reglas de negocios del sistema.

N° RN Nombre de la Regla Descripción Fuente Proceso que Regula Fórmula

Rn-01 Admisión de los Aspirantes - Artículo 3

Los aspirantes a ingresar al PAI deberán haber cursado al menos el equivalente al 60% del total de las Unidades Crédito (UC) requerida por la carrera de adscripción incluyendo el trabajo especial de grado y haber logrado un rendimiento académico (RA) superior al 75%. Para optar al PAI, el interesado efectuará una solicitud por escrito de acuerdo al formato diseñado para tal fin.

Normativa del Programa Académico

Interdisciplinario

PF-1: “Admisión del Estudiante al Programa”

UCA ≥ 60

RA > 75

Rn-02 Permanencia del Estudiante PAI:

Artículo 5

El estudiante del programa deberá presentar al finalizar cada período lectivo la constancia de notas aprobatorias de las materias u otras actividades académicas cursadas de manera tal de garantizar su permanencia en el programa.


Interdisciplinario

PF-2: “Permanencia en el

Programa”

Rn-03 Permanencia del Estudiante PAI -

Artículo 6

El estudiante deberá respetar la secuencia del programa académico acordado y asignado por el Comité de acuerdo al diseño establecido.


Interdisciplinario


Programa”

Rn-04 Permanencia del Estudiante PAI -

Artículo 8

El programa académico diseñado para un estudiante PAI sólo podrá ser modificado en una oportunidad. Modificaciones posteriores requerirán haber aprobado el 80% de las U.C. del plan de estudio de la carrera respectiva.


Interdisciplinario


Programa”

UCA ≥ 80

Rn-05 Nota Mínima

Aprobatoria Artículo 152

Para evaluar el aprovechamiento del alumno de calificarán los trabajos; exámenes y pruebas, con un número comprendido entre 0 y 20 (cero y veinte) puntos. Para ser aprobado se necesita un mínimo de 10 (diez) puntos.

Ley de Universidades PF-2:

“Permanencia en el Programa”




ULA

2.7.2. Diagrama de rastreabilidad Requisitos Funcionales / Casos de Uso

En este anexo se muestra la relación que existe entre los casos de usos y los requisitos funcionales

analysis Diagrama de trazabilidad

Validar Acceso al sistema

Administración de Usuarios del Sistema

CU-006 Cambiar clav e de usuarioRF-007 Cambiar clave de

usuario

RF-001 Registrar usuarios

RF-002 Asignar roles

RF-003 Modificar datos de usuarios

RF-004 Eliminar usuario

RF-005 Consultar usuario

RF-006 Imprimir usuario

RF-008 Ingresar al sistema

CU-001 Registrar Usuario

CU-002 Modificar usuario

CU-003 Eliminar Usuario

CU-004 Consultar usuario

CU-005 Imprimir usuario

CU-007 Ingresar al sistema

Casos de usoRequisitos Funcionales

«include»

«extend»

«extend»

«extend»

«include»




ULA

2.7.3. Diagrama de trazabilidad procesos-requisitos Mediante este diagrama, se muestra la relación entre los procesos y los requisitos funcionales

analysis Modulo 1

PF-1.1 Adjudicacion de la

Empresa

PF-1.2 Gestion de los Puntos de

Entrega

PF-1.3 Actualizacion del

monto de la Unidad Tributaria

1. Inicializacion del beneficio

+ RF-001 T ipos de reclam o+ RF-002 Origen de los recursos+ RF-003 Ubicación física del personal+ RF-004 T ipo de personal y condicion+ RF-005 M odal idad de pago del beneficio+ RF-006 Puntos de entrega+ RF-007 Responsables por puntos de entrega+ RF-008 Asignación de responsables a puntos+ RF-009 Grupos de puntos por m es+ RF-010 T ipos de nóm ina+ RF-011 M antener l ici taciones+ RF-012 Cantidad de días por turno por m es+ RF-013 Configuración de períodos de unidad tributaria en el año+ RF-014 Acceso a otros sistem as+ RF-015 Configuración de la Ejecución del gasto

Documents

Propuesta para la documentación de la Ingeniería de Requisitos