Anda di halaman 1dari 48

ANLISIS

Y DISEO DE SISTEMAS

75

UNIDAD DE
APRENDIZAJE

2
TEMA

9
INTRODUCCIN AL MANEJO DE REQUISITE PRO
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.
2.
3.

Herramientas CARE
Fundamentos RequisitePro
Integracin del Rational Software Architect con RequisitePro

ACTIVIDADES PROPUESTAS
1.

Los alumnos realizan el Modelo de casos de uso de un caso propuesto.

76

1.

HERRAMIENTAS CARE
CARE es un acrnimo en ingls que significa Computer Aided Requirements
Engineering y en espaol es Ingeniera de Requisitos Asistido por Computador.
Existe un grupo de herramientas CARE para el campo de la ingeniera de
requisitos, las cuales se concentran en capturar requisitos, administrarlos y
producir una especificacin de requisitos. Las herramientas ms utilizadas para
este propsito son Rational RequisitePro de IBM y DOORS de Telelogic
(compaa de IBM).

RequisitePro
La herramienta de Rational RequisitePro es una solucin poderosa si bien
fcil de usar que promueve una mejor comunicacin, mejorala
colaboracin de los equipos y reduce el riesgo de los proyectos.

La solucin de IBM Rational RequisitePro promueve la herramienta


ampliamente usada y conocida de Microsoft Word para facilitar la captura
de requisitos. Aunque tiles para la captura de requisitos, los documentos
no son un entorno ptimo para priorizar y organizacin la informacin,
actividades que se realizan mejor usando una base de datos. Vinculando
documentos de requisitos a una base de datos, el producto RequisitePro
une lo mejor de ambos mundos.

DOORS
Telelogic DOORS, la familia de soluciones para la Gestin de Requisitos,
mejora la calidad optimizando la comunicacin y la colaboracin, y
promoviendo la conformidad con las normas y estndares y la validacin
mediante las capacidades siguientes:

ANLISIS

2.

Interfaces intuitivas que promueven la adopcin de la Gestin de


Requisitos.
Escalabilidad para cualquier tamao de proyecto con cualquier
nmero de usuarios.
Una matriz de trazabilidad de requisitos fcil de usar, actualizada y
flexible.
El soporte ms completo para el registro, estructuracin, gestin y
anlisis de requisitos y su trazabilidad.
Integracin sin precedentes con otras soluciones de Telelogic y
herramientas de terceros para tener una mejor visin de los
requisitos y controlar su trazabilidad a lo largo del ciclo de vida del
proceso de desarrollo.

Y DISEO DE SISTEMAS

77

FUNDAMENTOS REQUISITE PRO


IBM Rational RequisitePro es una herramienta que facilita la gestin de los
requisitos. Permite el registro, actualizaciones, seguimiento y revisin de los
requisitos durante el ciclo de vida del proyecto.
RequisitePro se integra con Microsoft Word (un entorno familiar para el
procesamiento de documentos) y una infraestructura de base de datos de gran
alcance. Mediante la combinacin de enfoques centrado en documentos y en
bases de datos, RequisitePro proporciona una potente framework fcil de usar
para la gestin de requisitos.
La navegacin entre los documentos y la base de datos es fcil e intuitiva. Puede
crear, organizar, priorizar y rastrear los requisitos. La herramienta permite la
personalizacin detallada de documentos, tipos de requisitos y atributos. La
gestin del cambio se ve facilitada por el seguimiento de la trazabilidad entre los
requisitos.
RequisitePro fue desarrollado por Requisite, Inc. en 1996. Requisite fue
adquirida por Rational Software Corp. en 1997 y posteriormente por IBM en
2003.
Actualmente, RequisitePro se encuentra en la versin 7.1 de. Las diferencias
entre las versiones 2003 y 2007 son en relacin a las nuevas plantillas para crear
proyectos. En la siguiente seccin describiremos las plantillas ms utilizadas.

Entorno de RequisitePRO
La interfaz del RequisitePRO contiene las siguientes reas principales: un
explorador, vistas y una barra de herramientas. (Vase figura 9.1).

Explorador
El explorador es la ventana principal de navegacin, que muestra
los componentes del proyecto en una estructura de rbol. Los
documentos, requisitos y vistas se organizan en paquetes.

Proyecto
Paquete
Vista
Requisito
Documento

Figura 9.2. Explorador

Explorador

Barra de herramienta
Barra de men

Vista

Descripcin de la
vista

Figura 9.1. reas principales del RequisitePRO

Los conos para vistas pueden ser cualquiera de los siguientes tres
tipos:
Matriz de atributos
Matriz de trazabilidad

rbol de trazabilidad
Vistas
Una vista es un rea en la que se puede analizar la informacin de
un requisito. Una vista muestra los atributos de requisito o las
relaciones entre los requisitos. Las relaciones entre requisitos se
pueden mostrar en una matriz o en forma de rbol. En una vista
tambin puede crear y actualizar los requisitos, establecer
relaciones entre ellas (como la jerarqua y trazabilidad), ordenar o
filtrar los requisitos, y el estado del proyecto de consulta.
Como se indic anteriormente, existen tres tipos de vistas, los
cuales se describen a continuacin:

La Matriz de Atributos muestra requisitos de un tipo


especfico y sus atributos. Algunas veces se utiliza para
mostrar descripciones de requisitos.

Figura 9.3. Matriz de Atributos


80

La Matriz de Trazabilidad muestra las relaciones entre dos


tipos de requisitos en la forma de una matriz.

Figura 9.4. Matriz de Trazabilidad

El rbol de Trazabilidad muestra las relaciones entre dos


tipos de requisitos en la forma de una rbol.

Figura 9.5. rbol de Trazabilidad


ANLISIS

Y DISEO DE SISTEMAS

81

Barra de herramientas
La barra de herramientas RequisitePro, que se muestra en la figura
9.6, proporciona acceso rpido a informacin de proyectos y
operaciones principales.

Establecer/modificar
trazabilidad
Filtrar requisitos por algn criterio
Ir al documento del requisito seleccionado
Buscar un elemento
Ver propiedades del requisito seleccionado
Crear nuevo requisito
Figura 9.6. Barra de herramientas

Entorno de trabajo con WORD


El lugar de trabajo Word es el ambiente en el cual se crea, visualiza y
modifica documentos. Se abre como una ventana de Microsoft Word en
RequisitePro al dar doble clic sobre un documento y proporciona la misma
funcionalidad como Microsoft Word. Una barra de herramientas de
RequisitePro adicional permite las operaciones concretas en los
documentos y los requisitos de RequisitePro, tal como se muestra en la
figura 9.7.

Ayuda
Explorador RequisitePRO
Ir al Requisito
Buscar Requisito
Pegar Requisito
Copiar Requisito
Cortar Requisito
Eliminar Requisito
Propiedades del Requisito
Nuevo Requisito
Guardar Documento
Abrir Documento
Nuevo Documento
Figura 9.7. Barra de herramientas para el entorno de trabajo con Word
82

Plantillas de proyectos
Un proyecto en RequisitePRO con una de las plantillas mostradas en la
figura 9.8. Cada proyecto se crea en un directorio por separado. La plantilla
elegida depender de los documentos y tipos de requisitos utilizados en el
proyecto.

Figura 9.8. Plantillas de proyectos


Las plantillas que comnmente se utilizan se describen a continuacin.
Modelado de Negocio (Business Modeling)
Esta plantilla es ms adecuada para las organizaciones que
realizan modelado de negocios. Incluye los tipos de documentos y
tipos apropiados requisito para el modelado de negocios.
Caso de Uso (Use-Case Template)
Ideal para usuarios de la suite Rational que utilizan RUP como
metodologa de desarrollo. Esta plantilla est diseada para los
proyectos de RequisitePro que utilizan la integracin de los casos
de uso RequisitePro con una herramienta de modelado IBM
Rational y solicitudes de mejora con ClearQuest. Los casos de uso
son particularmente aplicables a los objetos de diseo de software
orientado a utilizar el UML y para las aplicaciones que son de uso
intensivo.
ANLISIS

Y DISEO DE SISTEMAS

83

Compuesta (Composite Tmplate)


Esta plantilla le permite combinar las mejores cualidades que
utilizan el modelado de casos y las tcnicas de especificacin de
requisitos tradicionales, proporcionando un esquema moderno de
especificacin de paquetes de software tanto en la aplicacin de
tcnicas basadas en el documento y modelado de casos de uso.
Tradicional (Tradicional Template)
Esta plantilla es la ms adecuada para aquellas organizaciones que
estn ms acostumbrados a un enfoque tradicional declarativo de
requisitos.
RUP (RUP Template)
Esta plantilla es para proyectos que siguen la metodologa RUP.
Incluye los tipos de documentos y tipos apropiados de requisito para
los resultados finales.
SAP (SAP Template)

Esta plantilla proporciona requisitos y tipos de documento para


capturar, analizar y gestionar los requisitos de negocio y otros
requisitos relacionados con el desarrollo SAP.
El nombre de SAP proviene de: Sistemas, Aplicaciones y Productos
en Procesamiento de datos. El nombre SAP es al mismo tiempo el
nombre de una empresa y el de un sistema informtico. Este
sistema comprende muchos mdulos completamente integrados,
que abarca prcticamente todos los aspectos de la administracin
empresarial. Cada mdulo realiza una funcin diferente, pero esta
diseado para trabajar con otros mdulos.
SAP establece e integra el sistema productivo de las empresas. Se
constituye con herramientas ideales para cubrir todas las
necesidades de la gestin empresarial -sean grandes o pequeasen torno a: administracin de negocios, sistemas contables, manejo
de finanzas, contabilidad, administracin de operaciones y planes
de mercadotecnia, logstica, etc. SAP proporciona productos y
servicios de software para solucionar problemas en las empresas
que surgen del entorno competitivo mundial, los desarrollos de
estrategias de satisfaccin al cliente, las necesidades de innovacin
tecnolgica, procesos de calidad y mejoras continuas, as como, el
cumplimiento de normatividad legal impuesta por las instituciones
gubernamentales.
Crear a partir de una lnea base (Create from Baseline)
til si usted tiene una lnea base de ClearQuest integrado con
RequisitePro.
84

3.

INTEGRACIN DEL RSA CON REQUISITE PRO


Desde IBM RSA se puede acceder a un proyecto RequisistePRO. Esta
integracin del Requisite PRO e IBM RSA ofrece la perfecta gestin de los
requisitos funcionales traducidos a casos de uso.

Cmo visualizar el explorador de Requisite PRO desde IBM RSA?


1.

Cambie la perspectiva Modeling a Requirement.

2.

Abrir un proyecto Requisite PRO.

3
ANLISIS

3.

Y DISEO DE SISTEMAS

85

A continuacin se muestran las vistas


RequisistePRO cargado en el IBM RSA.

disponibles para

el

proyecto

Explorados de Requisitos

Vista de Trazabilidad de un Requisito


rbol de Trazabilidad
86

CASO DE ESTUDIO
A continuacin se explicar como crear un proyecto para el caso Agencia de Viajes
Forneo. En esta sesin aprender a crear el primer documento que se utiliza en un

proceso de gestin de requisitos: Plan de Gestin de Requisitos.


El Plan de Gestin de Requisitos describe el enfoque de la gestin de requisitos en el
proyecto. Este documento especifica cmo los requisitos son creados, organizados,
modificados, y rastreados durante el ciclo de vida del proyecto. Tambin se describen
todos los tipos de requisitos y sus atributos utilizados en el proyecto. Estas son las
preguntas que pueden ser contestadas en el plan:

Se utilizar alguna herramienta de gestin de requisitos?


Qu tipos de requisitos sern rastreados en el proyecto?

Cules son los atributos de estos requisitos?

Dnde se crearn 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 que se utilizarn como un contrato con los


clientes?
Si una parte del proyecto se subcontrata, qu requisitos y documentos sern
utilizados como un contrato con un vendedor?
Vamos a seguir la metodologa RUP o alguna otra?

El cliente necesita documentos especficos para cumplir con su proceso de


desarrollo?
Cmo la gestin de cambios se llevar a cabo?
Suponiendo que se utiliza Requisite Pro, todo el sistema se almacenar en
un Proyecto Requisite Pro o se crearn varios proyectos?
Qu proceso garantizar que todos los requisitos sern implementados y
verificados?
Para qu requisitos o vistas tenemos que generar informes?

ANLISIS

Y DISEO DE SISTEMAS

87

Creacin de un proyecto
1.

Al ejecutar RequisitePRO se cargar un cuadro de dilogo con plantillas de


proyectos. Seleccione la plantilla de Casos de Uso.

1
2

2. A continuacin edite el nombre del proyecto. Puede utilizar un acrnimo haciendo


referencia a la empresa. Por defecto todos los requisitos se almacenarn
utilizando MS Access.

2
Ubique el
directorio
donde
guardar su
proyecto.

88

3.

Luego confirme la creacin del directorio para el proyecto configurado.

4.

A continuacin abra el documento Plan de Gestin de Requisitos para editarlo.

De doble clic sobre


el documento

2
ANLISIS

5.

Y DISEO DE SISTEMAS

89

En el entorno de Word que se muestra, abra la ventana de propiedades del


documento.

2
3
4

5
90

6.

Ahora, actualice los cambios de las propiedades sobre el documento.

1
Ubique el cursor
sobre el nombre
del proyecto.
Luego presione F9.

2
Ubique el cursor
sobre el nombre
del documento.
Luego presione F9.

3
Ubique el cursor
sobre el ttulo del
documento (pgina
5). Luego presione
F9.
ANLISIS

7.

Y DISEO DE SISTEMAS

91

El mismo procedimiento realice sobre los nombres del proyecto y del documento
ubicados en la cabecera. Al final, guarde los cambios.

ACTIVIDAD PROPUESTA
Siga las instrucciones de su profesor para completar el documento utilizando el idioma
espaol. Para nuestro proyecto crearemos las siguientes secciones:

1.

2.
3.

Introduccin
Propsito
Alcance
Descripcin General
Herramientas, Entorno e Infraestructura
Documentos y Tipos de Requisitos
Documentos
Tipos de Requisitos
Trazabilidad
Atributos de Requisitos
Atributos para Necesidades de Stakeholders (STRQ)
Atributos para Caractersticas (FEATURES)
Atributos para Casos de Uso (UC)
Atributos para Requisitos Suplementarios (SUPL)
Reportes

92

Resumen

Existe un grupo de herramientas CARE para el campo de la ingeniera de


requisitos, las cuales se concentran en capturar requisitos, administrarlos y
producir una especificacin de requisitos. Las herramientas ms utilizadas para
este propsito son Rational RequisitePro de IBM y DOORS de Telelogic (compaa

de IBM).
IBM Rational RequisitePro es una herramienta que facilita la gestin de los
requisitos. Permite el registro, actualizaciones, seguimiento y revisin de los
requisitos durante el ciclo de vida del proyecto.

Plantillas
Documento

Tipo de Requisito

Caso
de Uso

Compuesto

Tradicional

Plan de gestin de
requisitos
Peticiones de
stakeholders

Necesidades de
stakeholders

Visin

Caractersticas

Glosario

Trmino

Especificacin de
Requisitos de Software
Especificacin de
Caso de Uso
Especificacin
Suplementaria
El

Requisitos de
Software

Caso de Uso

Requisito
Suplementario

Plan de Gestin de Requisitos es un documento que establece los


lineamientos para el establecimiento de los documentos de requisitos, tipos,
caractersticas, y la trazabilidad con el fin de gestionar los requisitos del proyecto.
Si

desea saber ms acerca de Rational RequisitePRO, puede consultar el


siguiente enlace en el cual se presenta un tutorial:
http://www.se.fhheilbronn.de/usefulstuff/Rational%20Rose%202003%20Documentation/ReqPro%2
0help/Tutorial.html

1.

Los alumnos crear los documentos y requisitos a partir de un caso propuesto.

94

1.

DOCUMENTOS Y REQUISITOS EN REQUISITE PRO

Como anteriormente se indic, al crear el proyecto en RequisitePro, es necesario


especificar cules son los documentos necesarios, y qu tipos de requisitos sern
utilizados en el proyecto y qu atributos se le asignar a los requisitos.
La tabla 10.1 resume qu tipos de documentos y requisitos se incluyen en las tres

principales plantillas en RequisitePRO: Tradicional, Caso de Uso y Compuesto.

Tabla 10.1. Documentos y Tipos de Requisitos incluidos en las Tres


Principales Plantillas en RequisitePRO

Aqu se presenta una breve descripcin de los documentos.

Plan de Gestin de Requisitos. Este documento establece los lineamientos


para el establecimiento de los documentos de requisitos, tipos,
caractersticas, 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.

Visin. Este documento da la visin total del sistema: principales


caractersticas, necesidades de los stakeholders y servicios esenciales
proporcionados.

Glosario. Es importante que todos los stakeholders utilicen trminos


consistentes para expresar sus necesidades. El glosario es una herramienta
para capturar y definir los trminos utilizados en el proyecto.

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

ANLISIS

Y DISEO DE SISTEMAS

95

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

Especificacin Suplementaria. Este documento captura los requisitos que


no puede vincularse directamente a cualquier caso de uso especfico, y sobre
todo si se trata de los requisitos no funcionales y restricciones de diseo.

CASO DE ESTUDIO
En esta sesin se explicar cmo derivar caractersticas del sistema a partir de las
necesidades de los stakeholders. Empezaremos con la importacin del documento
Solicitudes de stakeholders al proyecto creado para el sistema de Agencia de Viajes
FORNEO.
NOTA: Se debe crear el documento Solicitudes de stakeholders para cada
stakeholder del sistema. Para el ejemplo, se utilizar este documento creado para las
necesidades presentadas por el Gerente General de la agencia.

Importacin del documento Solicitudes de Stakeholders


1.

Desde el explorador de windows, abra el proyecto AVF_Requisitos creado en la


sesin anterior. Para ello, de doble clic sobre el archivo del proyecto.

2.

Luego, seleccione el paquete Stakeholder Requests para importar el archivo.

3
96

3.

En este cuadro de dilogo seleccione el tipo de archivo a importar.

Seleccione el
directorio donde
se encuentra el
archivo

3
4.

Aqu se selecciona el contenido a importar. En este caso, seleccione Requisitos


y documento porque el documento que vamos a importar contiene requisitos del
tipo Necesidades.

5.

En este cuadro de dilogo especifique las propiedades del documento.

1
2
4

ANLISIS

Y DISEO DE SISTEMAS

97

6.

Aqu confirme la importacin del documento. De clic al botn S.

7.

Aparece este cuadro de dilogo para especificar palabras claves, textos


delimitadores o estilos de word significativos que identifiquen a los requisitos del
documento.

8.

Como los requisitos del documento utilizan el estilo Titulo 1, realice lo siguiente:

98

9.

En este cuadro de dilogo se muestra el primer bloque con estilo Ttulo 1


encontrado en el documento. Para continuar seleccione Yes to All.

10. Espere hasta que se termine de identificar a todos los requisitos. Luego, confirme
la operacin de grabar los requisitos y a continuacin se abrir el documento.
ANLISIS

Y DISEO DE SISTEMAS

99

11. Cierre el entorno de Word y visualice en el explorador del RequisitePRO todos los
requisitos identificados.

12. A continuacin asigne un nombre corto y significativo a cada requisito. Para ello
utilice la ventana de propiedades.

1
100

13. Edite un nombre para el requisito seleccionado.

2
14. Asigne un nombre corto y significativo a los dems requisitos. Al final debe tener
la siguiente lista de necesidades.
ANLISIS Y DISEO DE SISTEMAS

101

Creacin de un requisito en el documento Visin


1.

Desde el explorador, abra el documento con doble clic sobre Vision.

2.

Especifique las propiedades del documento utilizando el men del entorno Word.
Luego actualcelos en el documento con F9, tal como se hizo con el documento
del Plan de Gestin de Requisitos.

1
2

4
102

3.

A continuacin, ubquese en la seccin 5 y sobrescriba el ttulo por


Caractersticas del Producto. Luego distribuya las ventanas de los entornos
RequisitePRO y Word, tal como se muestra a continuacin.

4.

La distribucin indicada permitir crear las caractersticas de forma fcil y rpida.


A continuacin por cada necesidad de stakeholder debe derivar una o ms
caractersticas expresadas con ms nivel de detalle. Por ejemplo:

Seleccione

1
3

requisito.

requisito.

Escriba con ms
detalle, el
enunciado de la
caracterstica.

Lea la
descripcin
completa del
ANLISIS Y DISEO DE SISTEMAS

5.

103

Para crear el requisito, a partir del texto editado, siga los pasos que se muestran.
Seleccione el texto
que define el
requisito.

6.

La etiqueta FEATpending1 es asignado al nuevo requisito para referirse a un


requisito pendiente. Para eliminar la palabra pending, grabe el documento.

1
104

7.

Como puede observar, la etiqueta ahora es llamada FEAT1.

8.

Asimismo, el nuevo requisito se ha agregado en el explorador de RequisitePRO.

9.

Repita estos pasos para cada requisito descrito tanto en la


Caractersticas del Producto como en Requisitos de Documentacin.

ANLISIS Y DISEO DE SISTEMAS

seccin
105

Creacin de un requisito en el documento Glosario

Desde el explorador, abra el documento con doble clic sobre Glossary.

Especifique las propiedades del documento utilizando el men del entorno Word.
Luego actualcelos en el documento con F9, tal como se hizo con el documento
del Plan de Gestin de Requisitos.

2
3

4
106

A continuacin, ubquese en la seccin 2 (Definiciones) para editar un requisito


del tipo Trminos en RequisitePRO.

Para crear el requisito, a partir del texto editado, siga los pasos que se muestran.
Seleccione el texto
que define el
requisito.

4
ANLISIS Y DISEO DE SISTEMAS

107

La etiqueta TERMpending1 es asignado al nuevo requisito para referirse a un


requisito pendiente. Para eliminar la palabra pending, grabe el documento.

Como puede observar, la etiqueta ahora es llamada TERM1.

Asimismo, el nuevo requisito se ha agregado en el explorador de RequisitePRO.

Repita estos pasos para cada requisito descrito en la seccin Definiciones.

108

ACTIVIDADES PROPUESTAS

1.

Siga las instrucciones de su profesor para completar el documento Visin. Para


nuestro proyecto este documento incluye las siguientes secciones:

1.

Introduccin

2.

Posicionamiento

3.

Descripcin de Stakeholders

4.

Descripcin del Producto

5.

Caractersticas del Producto

6.

Otros Requisitos del Producto

7.

Requisitos de Documentacin

Aqu se ubican los


requisitos del tipo
CARACTERSTICAS.

NOTA: Para crear uno o varios requisitos FEAT (Features) a partir de los
requisitos STRQ (Stakeholders request) se aplica alguna de las siguientes
estrategias de transformacin:

Copiar: Si no se requieren cambios, el STRQ puede ser copiado a FEAT


exactamente como es.

Dividir: Si el requisito no es atmico, podemos dividir en dos o ms


requisitos.

Aclaracin: Aclaracin o explicacin, se puede aplicar cuando el requisito


original es poco claro o ambiguo.

Cualificacin: Logramos cualificar mediante la adicin de restricciones o


condiciones al requisito. Puede ayudar a resolver las necesidades
contradictorias.

Combinacin: Si los requisitos son redundantes o se superponen se


pueden combinar en uno solo.

Generalizacin: Si la necesidad no es abstracta, e incluye algunos detalles


innecesarios, podemos aplicar la generalizacin.

Cancelacin: A veces el requisito debe ser eliminado. Esto puede suceder


cuando el requisito es no viable, innecesaria, o incompatible con otro
requisito.

Completar: Si el conjunto de requisitos es incompleta, puede ser necesario


aadir requisitos en esta etapa.

Correccin: Correccin puede significar una nueva redaccin del requisito


para corregir la gramtica, ortografa o puntuacin; o cambiar una parte de la
necesidad que no es cierta.

Unificacin: Los requisitos que usan un vocabulario inconsistente pueden


ser unificadas (estandarizadas).

Adicin de detalles: Si el requisito no es lo suficientemente preciso,


podemos aadir ms detalles. Esta tcnica se utiliza a menudo para obtener
requisitos verificables de los que no han sido especificados como tal.

ANLISIS Y DISEO DE SISTEMAS

2.

109

Siga las instrucciones de su profesor para completar el documento Glosario.


Para nuestro proyecto este documento incluye las siguientes secciones:

1.

Introduccin
1.1.

Propsito

2.

1.2.

Alcance

1.3.

Referencias

Aqu se ubican los


requisitos del tipo
TRMINOS.

Definiciones

NOTA: Las definiciones de los trminos en el glosario pueden estar formadas por
una palabra o frase.
3.

4.

Importe las especificaciones de casos de uso del Sistema de Agencia de Viajes.


Luego, cree los requisitos del tipo Caso de Uso derivados de las Caractersticas
del Producto.
Derive los requisitos suplementarios a partir de las Caractersticas del Producto.

110

Si

Resumen

Para el proyecto Agencia de Viajes FORNEO, a partir del documento Peticiones


de stakeholders, se crearon los siguientes documentos:

Visin
Glosario de trminos

desea saber ms acerca de Rational RequisitePRO, puede consultar el


siguiente libro:
REQUIREMENTS

MANAGEMENT USING IBM RATIONAL REQUISITE PRO


de Peter Zielczynski.

El cuarto captulo trata la configuracin de proyectos en RequisitePRO.


El sexto captulo explica cmo a partir de las necesidades de stakeholders
se derivan las caractersticas del sistema.

ANLISIS Y DISEO DE SISTEMAS

111

UNIDAD DE
APRENDIZAJE

2
TEMA

11

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

Tipo de
Requisito

Descripcin

Atributos
Prioridad de Stakeholder, Origen

Necesidades de
stakeholders
(STRQ)

Una solicitud de cualquier


tipo por parte de un
stakeholder, por ejemplo un
cambio de requisito, un
requisito adicional un
defecto.

Caractersticas
(FEAT)

Una servicio externamente


observable proporcionado
por el sistema que satisface
las necesidades del usuario.

Prioridad, Tipo, Estado, Dificultad,


Estabilidad, Riesgo, Iteracin Planeada,
Iteracin Actual, Origen, Nombre de
Contacto, Requisito de mejora, Defecto,
Obsoleto

Trmino
(TERM)

Un trmino usado como


vocabulario comn a un
proyecto.

Caso de Uso
(UC)

Una descripcin del


comportamiento del sistema,
en trminos de secuencias y
acciones.

Requisito
Suplementario
(SUPL)

Una descripcin de un
requisito no funcional.

Propiedad, Prioridad, Estado, Dificultad,


Estabilidad, Riesgo, Afecta a la
arquitectura, Nombre de Contacto,
Iteracin Planeada, Iteracin Actual,
Requisito de mejora, Defecto, Obsoleto
Prioridad, Estado, Dificultad, Estabilidad,
Riesgo, Requisito de mejora, Defecto,
Nombre de Contacto, Obsoleto

1. Organizacin de requisitos: vistas, tipos y atributos.

ACTIVIDADES PROPUESTAS
1.
2.

1.
112

Los alumnos rinden su Evaluacin Continua 3.


Los alumnos crean los atributos de los requisitos propuestos.

ORGANIZACIN DE REQUISITOS

TE
MA
RI
O

ObsoletoAtributo
Afecta a la arquitectura
Prioridad
Prioridad para
Stakeholder
Tipo

Estado

Riesgo
Iteracin Planeada

Es asignado por el analista


y equipo de desarrollo, y est
Descripcin
Tipo
Para
especificar
si
un
requisito
ya no
ser utilizado.pueda List
basado sobre la probabilidad que
la caracterstica
Esteasignado
atributo
es
por el Gerente
del
proyecto
o el
cambiar
o que
la desarrollador
comprensin
de que
el equipo
Es
porasignado
el
para
especificar
si
el de
List
analista
de
negocio.
Determina
la
importancia
relativa
a
proyecto cambie.
pueden ser:
requisito
afecta o Sus
no avalores
la arquitectura
del sistema.
las caractersticas
Permite manejar el List
Alto
si el requisitode
noimplementacin.
cambia
List
alcance sidelel proyecto
determinar
la prioridad
Medio
requisito y puede
cambiar,
pero es de
lo
El nivel de prioridad que un stakeholder asigna a suList
desarrollo.
suficientemente
estable para iniciar el trabajo
necesidad.
Bajo
si
es
muy
probable
el cambio
del requisito, por lo
List
Para
a qu
tipo
de requisito
Este especificar
atributo es
asignado
por el corresponde.
equipo de calidad
que es necesario realizar un estudio adicional para ser
mientras se en
evalan
las solicitudes de los stakeholders.
considerado
el trabajo.
Sus valores pueden ser:
Propuesto a travs de una solicitud de stakeholder
List
Aprobado por el Gerente del proyecto y/o Aseguramiento
de la Calidad
Incorporadoelpara
Especifica
nivelsudeejecucin
ocurrencia de una amenaza sobre
List
Validado
por Aseguramiento de la Calidad
un
requisito
Asignado por el lder del equipo y describe el nmero de Integer
iteraciones necesarios para terminar el requisito.
Describe la iteracin actual del requisito, permitiendo Integer
tener un seguimiento de acuerdo al calendario.

Iteracin Actual

Funcional
Lista de Valores
True/False
Facilidad
de Uso
Alto
Alto
True/False
Confiabilidad
Medio
Alto
Rendimiento
Medio
Medio
Bajo
Soporte
Bajo
Propuesto
Restricciones de
Bajo
Diseo
Aprobado
Cronograma-Alto
Requisitos
de
Incorporado
Implementacin
Cronograma -Medio
Requisitos Fsicos
Cronograma -Bajo
Validado
Requisitos de Interfaz
Tecnologa-Alto
n/a
Nombre
Tecnologa -Medio
Breve Descripcin
Tecnologa -Bajo
n/a Bsico
Flujo
Help Desk
Sub flujo
Socios
Alto
Flujo Alternativo
Competidores
Requisito Especial
Grandes Consumidores
Pre-Condicin
Medio
Usuarios finales
Post-Condicin
n/a
Punto de Extensin
n/a
Bajo

Asignado por el equipo de desarrollo para especificar que


un requisitoa necesita
tiempo
y recursos
que otros,
Especfico
un caso ms
de uso,
utilizado
para elaborar
el
Utilizado
para
especificar
quino solicit
el requisito. List
estimando
el
nmero
del
equipo
de
persona-semanas,
List
texto de un caso de uso
Debe
junto conolapuntos
prioridad.
lneas ser
deconsiderado
cdigo requeridas
de funcin. Este
atributo es utilizado para manejar el alcance y determinar List
la complejidad de desarrollo. Sus valores pueden ser:
Alto o muy difcil porque es probable que sea costoso en
Text
trminos responsable
de recursos odedinero
Persona
este requisito
Medio o difcil pero puede ser realizado sin riesgos
Text
Usado
Bajo o para
fcil integrarse con ClearQuest
Text
n/a
Usado para integrarse con ClearQuest
Cuanto mejor sea la comunicacin y administracin de requerimientos, mayor
ser la oportunidad de que los proyectos se entreguen a tiempo y dentro de
presupuesto.

Propiedad
Origen
Dificultad
Nombre de Contacto
Requisito de mejora
Defecto

Los cambios en tiempo real que impactan el anlisis permiten que cada miembro
del equipo comprenda como afecta otras partes del proyecto. (Quin, Qu, Por
qu y Cundo).
La estructura para administrar los requerimientos esta basada en: documentos,
requisitos y sus atributos.
La tabla 11.1 muestra qu atributos son normalmente usados para cada tipo de
requisito. Como se observa en la tabla, algunos atributos se repiten para varios
requisitos tales como estado, costo, dificultad, entre otros.

Tabla 11.1. Atributos por Tipo de Requisito

Para tener ms claro qu especifica cada atributo, a continuacin se muestran


en la siguiente tabla: una breve descripcin, tipo, lista de valores y qu requisito
considera a cada atributo.
114
ANLISIS Y DISEO DE SISTEMAS II - LABORTORIO
116

115

Tipo de

FEAT,
UC, SUPL
Requisito
UC
FEAT,
SUPL
FEAT, UC,
SUPL,
UC
STRQ
FEAT

FEAT, UC, SUPL

FEAT, SUPL, UC
FEAT, UC
FEAT, UC

UC
FEAT, STRQ
FEAT, SUPL, UC
FEAT, SUPL, UC
FEAT, SUPL, UC
FEAT, SUPL, UC

Tabla 11.2. Atributos de requisitos

Los valores de los atributos pueden ser elegidos desde una lista o ingresados desde un
campo de texto. Usted puede agregar, editar o
eliminar atributos de un requisito en cualquier momento durante el proyecto. A continuacin
se describen algunos tipos de datos:

List (valor nico): Un conjunto de valores de los que un nico valor se puede

seleccionar, por ejemplo, alto, medio o bajo.

List (valor mltiple): Un conjunto de valores de los que ms de un valor puede s

er seleccionado, por ejemplo, Cronograma-Alto,


Tecnologa-Alto.

Text: Una cadena de texto de hasta 255 caracteres, por ejemplo, John Smith.

Integer: Nmeros enteros, por ejemplo, 5 o 1500.

Los atributos permiten gestionar la toma de decisiones. Los valores que se asigne
a cada atributo ayudar a organizar, analizar y
priorizar los requisitos del proyecto.

Agregacin de atributos para un requisito


En general, para cualquier requisito se siguen los mismos pasos.
1.

Seleccione un requisito desde el explorador para abrir su ventana de propiedades.

1
Clic derecho
sobre el requisito

2
3
118

Tipo de
Requisito

Descripcin

2.

Atributos
Prioridad de Stakeholder, Origen

Necesidades de
stakeholders
(STRQ)

Una solicitud de cualquier


tipo por parte de un
stakeholder, por ejemplo un
cambio de requisito, un
requisito adicional un
defecto.

Caractersticas
(FEAT)

Una servicio externamente


observable proporcionado
por el sistema que satisface
las necesidades del usuario.

Prioridad, Tipo, Estado, Dificultad,


Estabilidad, Riesgo, Iteracin Planeada,
Iteracin Actual, Origen, Nombre de
Contacto, Requisito de mejora, Defecto,
Obsoleto

Trmino
(TERM)

Un trmino usado como


vocabulario comn a un
proyecto.

Caso de Uso
(UC)

Una descripcin del


comportamiento del sistema,
en trminos de secuencias y
acciones.

Requisito
Suplementario
(SUPL)

Una descripcin de un
requisito no funcional.

Propiedad, Prioridad, Estado, Dificultad,


Estabilidad, Riesgo, Afecta a la
arquitectura, Nombre de Contacto,
Iteracin Planeada, Iteracin Actual,
Requisito de mejora, Defecto, Obsoleto
Prioridad, Estado, Dificultad, Estabilidad,
Riesgo, Requisito de mejora, Defecto,
Nombre de Contacto, Obsoleto

A continuacin, con la barra de desplazamiento podr acceder a todos los


atributos del requisito para asignarle el valor correspondiente. Para hacerlo, debe
revisar las descripciones de los atributos descritos en la tabla 11.2.
A N L I S I S Y D I S E O DE S I S T E M A S

119

CASO PRCTICO
1.

Sobre la base del proyecto de Agencia de Viajes agregue los atributos para todas
las Caractersticas identificadas en el documento Visin.

120

Resumen
Los atributos por tipo de requisito se muestran en la tabla adjunta.
ANLISIS Y DISEO DE SISTEMAS

121

UNIDAD DE
APRENDIZAJE

2
TEMA

12
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 de requisitos (Parte I).

ACTIVIDADES PROPUESTAS
1.

Los alumnos realizan las matrices de trazabilidad de un caso propuesto.

122

1.

TRAZABILIDAD DE REQUISITOS
Los estados de un requisito pueden ser:
a.
b.
c.
d.

Trace to Traza a
Trace from Trazado de
Trace to suspect Traza a, con estado sospechoso (un cambio por revisar)
Trace from suspect Trazado de, con estado sospechoso (un cambio por
revisar)

Los estados trace to y trace from representan una relacin de dependencia


bidireccional entre los requisitos.
Los estados trace to y trace from son mostrados en una matriz de trazabilidad o
en una jerarqua de trazabilidad al crearse la relacin entre los requisitos.
En una matriz de trazabilidad, la relacin trace to es dibujada
trace from

y la relacin

Por ejemplo, si se tiene el Requisito A que solicita a un nuevo comando para ser
adicionado a un men particular de la aplicacin. Esto significara crear un nuevo
Requisito B asociado con este men. Entonces sera recomendable crear una
realizacin en donde el Requisito B sea trazado del (from) Requisito A.
Solamente puede existir una relacin de trazabilidad entre dos requisitos. La

diferencia entre las relaciones trace to y trace from es cuestin de perspectiva.


Por ejemplo:
Requisito A is trace to Requisito B
Requisito B is trace from Requisito A
La interpretacin es la siguiente:
Requisito fuente trace to Requisito derivado
Requisito derivado trace from Requisito fuente

Los estados sospechosos trace to suspect y trace from suspect son mostrados
en una matriz de trazabilidad cuando se modifica el nombre del requisito, texto,
tipo de requisito, o los atributos asociados con uno o ambos requisitos, con el
propsito de causar atencin sobre la relacin entre ambos requisitos.
En una matriz de trazabilidad, la relacin trace to suspect es dibujada y la
relacin trace from suspect
Solamente en las relaciones de trazabilidad directa se modifica el estado a
suspect, en las relaciones indirectas no.
Por ejemplo, si la relacin de trazabilidad existe entre el Requisito A y el
Requisito B, y se modifica el A, la relacin entre A y B se convierte en suspect.
Esto significa que B puede necesitar ser actualizado para reflejar
las
modificaciones hechas a A.
ANLISIS Y DISEO DE SISTEMAS

123

Una relacin de trazabilidad es indirecta si entre dos requisitos existe un requisito


intermediario.
Por ejemplo, si Requisito A es trace to al Requisito B, y el Requisito B es
trace to al Requisito C, entonces la relacin entre A y B y entre B y C son
directos. La relacin entre A y C es indirecta.

Estructura de trazabilidad
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.
Cada vez que se crea o cambia un nuevo artefacto (un objetivo, un
requisito, un elemento de modelado, un mdulo, un fichero de cdigo
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 anlisis de impacto cuando se solicita un cambio, pues
todos los que dependen del artefacto, tanto directa como indirectamente,
estn expuestos a posibles cambios. La figura 12.1 muestra la estructura
de trazabilidad usado en un proyecto.

Figura 12.1. Estructura de Trazabilidad


De acuerdo a la estructura mostrada en la figura, las relaciones de traza
son las siguientes:

STRQ trace to FEAT

FEAT trace from STRQ

FEAT trace to UC

UC trace from FEAT

FEAT trace to SUPL

SUPL trace from FEAT

124

Matrices de trazabilidad en RequisitePRO


En RequisitePRO, para un proyecto creado a partir de la plantilla de casos
de uso, hay tres matrices de trazabilidad:

Matriz de Caractersticas vs. Necesidades


Matriz de Casos de Uso vs. Caractersticas
Matriz de Requisitos Suplementarios vs. Caractersticas

1.2.1. Matriz de Caractersticas vs. Necesidades


Esta matriz se ubica en el paquete Features and Vision y se utiliza
para mostrar los enlaces de trazas del tipo trace from que existen
entre las caractersticas del sistema y necesidades de
stakeholders.
1.2.2. Matriz de Casos de Uso vs. Caractersticas
Esta matriz se ubica en el paquete Supplementary Requirements
y se utiliza para mostrar los enlaces de trazas del tipo trace from
que existen entre los casos de uso y las caractersticas del sistema.
1.2.3. Matriz de Requisitos Suplementarios vs. Caractersticas
Esta matriz se ubica en el paquete Use Cases y se utiliza para
mostrar los enlaces de trazas del tipo trace from que existen entre
los requisitos suplementarios y las caractersticas del sistema.

Figura 12.2. Matrices de Trazabilidad en el explorador del RequisitePRO


ANLISIS Y DISEO DE SISTEMAS

125

Agregacin de estados de traza entre requisitos


En general, para cualquier requisito se siguen los mismos pasos.
1.

Seleccione un requisito desde el explorador para abrir su ventana de propiedades.

1
Clic derecho
sobre el requisito

En esta seccin usted podr crear


las trazas que le corresponde al
requisito, tanto para trace from
como para trace to.

126

2.

Para esta caracterstica agregue en trace From la necesidad de stakeholder de la


cual fue derivada.

3
ANLISIS Y DISEO DE SISTEMAS

3.

127

A continuacin visualice la Matriz de Caractersticas vs. Necesidades. All se


mostrar el enlace de la traza que se cre.

128

Historial de revisiones de trazas sospechosas


1.

En el caso se cambie la descripcin de algn requisito, el enlace de traza cambia


a sospechoso. Por ejemplo, modifique el enunciado de la primera caracterstica
ubicada en el documento Visin.

2.

A continuacin RequisitePRO solicita una descripcin


conserva el historial de todos los cambios.

del cambio,

ya

que

2
ANLISIS Y DISEO DE SISTEMAS

129

3.

Luego, en la Matriz de Caractersticas vs. Necesidades se habr cambiado el


enlace de traza a sospechoso. El indicador de sospecha ayuda a coordinar
actualizaciones.

4.

Puede utilizar el cuadro de dilogo propiedades / historial de revisiones para


rastrear el cambio.

3
130

5.

Luego, abra el cuadro de dilogo de historial de revisiones para revisar los


cambios que se hicieron sobre el requisito.

En esta vista podr ver todos los cambios que se hicieron


sobre este requisito, el cual permitir gestionar los cambios.

3
A N L I S I S Y D I S E O D E S I S T E M A S I I - L AB O R TOR I O

131

6.

Si no hay problema con este cambio, puede eliminar el estado sospechoso.

1
Clic derecho
sobre el vnculo
sospechoso

2
7.

Por ltimo, en la matriz se habr eliminado el estado de sospecha sobre la traza


de la caracterstica modificada.

132

Creacin de vistas de trazabilidad


En caso de que se haya creado un proyecto que no tenga vistas de trazabilidad, usted
puede crearlos siguiendo los pasos que se indican a continuacin:
1.

Seleccione un requisito desde el explorador para abrir su ventana de propiedades.

2.

Aparece un cuadro de dilogo para especificar las propiedades de la vista a crear.

A N L I S I S Y D I S E O DE S I S T E M A S

3.

133

Se completa las propiedades para crear la vista de una matriz de trazabilidad.

2
3
4
5

4.

A continuacin se muestra la matriz.

134

5.

Sobre la matriz tambin puede crear los estados de trazas entre requisitos segn
sea el caso.

6.

Clic derecho
sobre la
interseccin
de una fila y
columna.

Seleccione el
estado de traza
correspondiente

A continuacin, se mostrar el enlace de trazabilidad entre los dos requisitos.


Repita el paso anterior para agregar las trazas que faltan.

ANLISIS Y DISEO DE SISTEMAS

135

CASO PRCTICO
Sobre la base del proyecto de Agencia de Viajes cree las siguientes matrices de
trazabilidad:
1.

Matriz de Caractersticas Vs. Necesidades

2.

Matriz de Casos de Uso Vs. Caractersticas

136

Resumen
En la prctica, a medida que se van creando los requisitos a partir de otros, las
trazas tambin se van asignando.
Los estados de un requisito pueden ser:

Trace
Trace
Trace
Trace

to Traza a, Deriva a
from Trazado de, Derivado de
to suspect Traza a, con estado sospechoso (un cambio por revisar)
from suspect Trazado de, con estado sospechoso (un cambio por revisar)

En una matriz de trazabilidad, la relacin trace to es dibujada


trace from
En una matriz de trazabilidad, la relacin trace to suspect es dibujada
relacin trace from suspect

y la relacin
y la

De acuerdo a la estructura de trazabilidad entre requisitos, las relaciones de traza


son las siguientes:

Si

STRQ trace to FEAT

FEAT trace from STRQ

FEAT trace to UC

UC trace from FEAT

FEAT trace to SUPL

SUPL trace from FEAT

desea saber ms acerca de Rational RequisitePRO, puede consultar el


siguiente libro:
REQUIREMENTS MANAGEMENT USING IBM RATIONAL REQUISITE PRO
de Peter Zielczynski.
El captulo 6, pg. 116-126, explica cmo crear matrices de trazabilidad entre
necesidades de stakeholders y caractersticas del producto.
El captulo 8, pg. 181-189, explica cmo crear matrices de trazabilidad entre

caractersticas del producto y requisitos suplementarios.


ANLISIS Y DISEO DE SISTEMAS

137

UNIDAD DE
APRENDIZAJE

2
TEMA

13
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 de requisitos (Parte II).

ACTIVIDADES PROPUESTAS
1.

Los alumnos realizan las matrices de trazabilidad de un caso propuesto.

138

CASO PRCTICO
Sobre la base del proyecto de Agencia de Viajes cree la siguiente matriz de
trazabilidad:
1. Matriz de Requisitos Suplementarios Vs. Caractersticas
ANLISIS Y DISEO DE SISTEMAS

139

UNIDAD DE
APRENDIZAJE

TEMA

14
CASO PRCTICO
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.

Caso Prctico.

ACTIVIDADES PROPUESTAS
1.

Los alumnos rinden su Evaluacin Continua 4.

140

CASO PRCTICO
A partir del caso descrito y la lista de requisitos adicionales que su profesor le
entregue, identifique las necesidades de stakeholders y caractersticas del producto.
Luego, realice la Matriz de Caractersticas vs. Necesidades

CONTROL LOGSTICO
La Empresa XYZ, cuyo giro es la venta de equipos y suministros informticos, busca
lograr las mejores condiciones comerciales para negociar con el proveedor, es decir,
pactar montos, fechas de pagos y formas de pago; y de esta manera, definir su cartera
de proveedores. Toda negociacin queda pactada con un documento firmado por el
jefe de Logstica y el representante del proveedor.
El jefe de Logstica solicita cotizaciones a los proveedores y los proveedores emiten
la cotizacin y se la envan. El jefe de Logstica analiza la cotizacin y si la aprueba,
genera una orden de compra al proveedor, de lo contrario, la archiva.
El proveedor enva el producto con su respectiva factura y gua. El asistente de
logstica recibe el producto, factura y gua; asimismo, revisa los productos, y si est
conforme, emite la orden de internamiento. En caso contrario, hace la devolucin del
producto informando el motivo de la devolucin. Se requiere reducir el tiempo al
momento de generar la orden de internamiento.
El Gerente General y el Gerente Financiero de XYZ desean que el registro de cada
una de las obligaciones generadas junto a su liquidacin sean realizadas
puntualmente.
El jefe de Logstica enva la orden de internamiento y factura al tesorero. El tesorero

registra la orden de internamiento y factura. El tesorero registra los documentos


pendientes de pago. Para este caso, se mencionan los documentos por pagar a
proveedores, aunque, tambin es importante registrar los documentos pendientes de
pago al gobierno y empleados. El tesorero enva los documentos al asistente de
Contabilidad.
Para llevar a cabo la liquidacin o pago, el tesorero emite los documentos pendientes
de pago y los enva al Gerente Financiero para que los analice y apruebe. El Gerente
Financiero emite los cheques, los mismos que son enviados a la Gerencia General
para su firma. Luego, se envan los cheques a los proveedores. Las copias de los
documentos de pago se envan al rea de Contabilidad para que registre la obligacin
como pagada en los asientos contables. Por cada obligacin que se va a registrar, se
debe buscar a los proveedores.
A N L I S I S Y D I S E O D E S I S T E M A S I I - L AB O R TOR I O

141

Glosario
Abstraccin
Caractersticas esenciales de una entidad que la distingue de otros tipos de entidades.
Define una frontera desde la perspectiva del observador.
AORE Aspect-Oriented Software Requirement
Ingeniera de requisitos orientada a aspectos, la cual provee un conjunto de enfoques
para gestionar intereses y requisitos transversales que podran modularizarse para
luego componerlos con otros intereses.
API
Una API representa una interfaz de comunicacin 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 mtodo para conseguir abstraccin en la
programacin, generalmente (aunque no necesariamente) entre los niveles o capas
inferiores y los superiores del software.
Artefacto
Pieza discreta de informacin que es utilizada o producida por un proceso de
desarrollo de software.
Aspecto
Mdulo 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 ejecucin o semntica de los componentes. Son conocidos tambin
como intereses transversales.
Elemento
Constituyente atmico de un modelo.
Especificacin
Descripcin textual de la sintaxis y la semntica de un bloque de construccin
especfico; descripcin declarativa de lo que algo es o hace.
Estereotipo
Extensin del vocabulario de UML que permite crear nuevos bloques de construccin
derivados a partir de los existentes pero especficos a un problema concreto.

Framework
En el desarrollo de software es una estructura de soporte definida en la cual otro
proyecto de software puede ser organizado y desarrollado. Tpicamente, puede incluir
soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para
ayudar a desarrollar y unir los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones generales de las
entidades del dominio. Provee una estructura y una metodologa de trabajo la cual
extiende o utiliza las aplicaciones del dominio.
142

Gestin de Requisitos
Actividad para gestionar los cambios en los requisitos del sistema. La gestin implica
el control de cambios y el impacto de los cambios.
Heurstica
Capacidad de un sistema para realizar de forma inmediata innovaciones positivas para
sus fines. La capacidad heurstica es un rasgo caracterstico de los humanos, desde
cuyo punto de vista puede describirse como el arte y la ciencia del descubrimiento y de
la invencin o de resolver problemas mediante la creatividad y el pensamiento lateral o
pensamiento divergente.
Ingeniera de Requisitos
Es un rea de investigacin que procura atacar un punto fundamental en el proceso,
que es la definicin de lo que se quiere producir.
Intereses (concerns)
Todo aquello que resulta importante para una aplicacin (requisitos, infraestructura,
cdigo, etc.).
Ingeniera de Software
Rama de la ingeniera que aplica los principios de la ciencia de la computacin y las
matemticas para lograr soluciones costo-efectivas a los proyectos de desarrollo o
mantenimiento de software de calidad.
Notacin
Sistema de signos convencionales que se adoptan para expresar un conjunto de
conceptos sobre el sistema de software por desarrollar.
OMG Object Management Group
Consorcio del cual forman parte las empresas ms importantes que se dedican al
desarrollo de software.
Refinamiento
Relacin que representa una especificacin ms completa de algo que ya ha sido
especificado a cierto nivel de detalle.
Requisito
Caracterstica, propiedad o comportamiento deseado de un sistema.
RUP Rational Unified Process
Proceso Unificado de Rational, metodologa del proceso de ingeniera de software que
proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de
una organizacin del desarrollo.
Stakeholder
Persona, grupo u organizacin que tenga directa o indirecta participacin en una
organizacin, ya que puede afectar o ser afectados por la organizacin de acciones,
objetivos y polticas. Actores claves en una organizacin de negocios incluyen los
acreedores, clientes, directores, empleados, gobierno (y sus organismos), los

propietarios (accionistas), los proveedores, los sindicatos y la comunidad en la que se


basa el negocio de sus recursos.

ANLISIS Y DISEO DE SISTEMAS

143

UML Unified Modeling Language


Lenguaje Unificado de Modelado, notacin estndar para el modelado de sistemas
Software.
Validacin de los requisitos
Proceso de confirmacin, por parte de los usuarios o del cliente, de que los requisitos
especificados son vlidos, consistentes, completos, etc.
Verificacin de los requisitos
Proceso de comprobacin de que los requisitos realmente cubren las necesidades del
cliente.
Vista
Proyeccin de un modelo, que se ve desde una perspectiva o un punto de vista dado,
y que omite entidades que no son relevantes desde esa perspectiva.
Workspace
Es un directorio que representa el espacio de trabajo y el cual contendr los proyectos
que se crean en la herramienta RSA.