Anlisis Anlisis Anlisis Anlisis de Requisitos de Requisitos de Requisitos de Requisitos C CC Co oo omunicativos municativos municativos municativos

i


1- REQUISITOS........................................................................................................ 1
1.1 LA MOTIVACIN ___________________________________________________ 1
1.1.1 The Chaos Report (1995) __________________________________ 1
1.1.2 The Robbins-Gioia Survey (2001) ____________________________ 2
1.1.3 The Conference Board Survey (2001) _______________________ 3
1.1.4 The KPMG Canada Survey (1997) ___________________________ 3
1.1.5 The OASIG Study (1995) __________________________________ 3
1.1.6 IT Cortex Conclusion _____________________________________ 4
1.2 EL ESTADO ACTUAL ________________________________________________ 5
1.3 REQUISITOS SOFTWARE _____________________________________________ 6
1.3.1 Estructura de los requisitos________________________________ 7
1.3.2 Tipos de requisitos ______________________________________ 8
1.3.3 Necesidades y caractersticas ____________________________ 13
1.4 DONDE EST EL PROBLEMA? _______________________________________ 13
1.5 SOLUCIONES? __________________________________________________ 16
2- REQUISITOS EN SISTEMAS DE INFORMACIN........................................... 17
2.1 ENTRADAS Y SALIDAS______________________________________________ 18
2.1.1 El SI como sistema de comunicaciones _____________________ 18
2.2 EVENTOS Y OBJETOS ______________________________________________ 20
2.2.1 Percepcin de Eventos e individuos. _______________________ 21
2.3 MBITOS DE LOS REQUISITOS ________________________________________ 22
2.3.1 El mbito sistema______________________________________ 23
2.3.2 El mbito de proceso. ___________________________________ 23
2.3.3 El mbito de las interacciones comunicativas. ________________ 24
2.3.4 El mbito de uso _______________________________________ 25
2.3.5 El mbito de la infraestructura tecnolgica ___________________ 26
3- INTERACCIONES EXTERNAS ......................................................................... 27
3.1 LAS INTERACCIONES COMO BASE DEL ANLISIS___________________________ 27
3.2 LA EXTERNALIDAD ________________________________________________ 27
3.2.1 Refinamientos _________________________________________ 28
3.2.2 Confusin externa/interna ________________________________ 28
3.2.3 Refinamientos de interacciones externas e internas. ___________ 29
3.3 LA UNIDAD ______________________________________________________ 30
3.3.1 Comunicaciones _______________________________________ 30
3.3.2 Sucesos______________________________________________ 32
3.3.3 Sucesos comunicativos__________________________________ 33
3.3.4 Criterios de unidad _____________________________________ 34
3.3.5 Criterios de unidad en los sucesos comunicativos _____________ 35
3.3.6 Estructuras de comunicacin _____________________________ 39
3.3.7 Un ejemplo trivial _______________________________________ 39
3.3.8 Completando la visin comunicativa________________________ 42
4- LA ORGANIZACIN DE LAS INTERACCIONES............................................. 45

4.1 TCNICAS DESCRIPTIVAS ___________________________________________ 45
4.1.1 Introduccin ___________________________________________ 45
4.1.2 Orientadas a objeto _____________________________________ 47
4.1.3 Orientadas a objetos de negocio___________________________ 48
4.1.4 BPMN _______________________________________________ 51
4.1.5 Casos de uso__________________________________________ 53
4.1.6 Diagramas de composicin de interacciones _________________ 55
4.2 DIAGRAMAS DE COMPORTAMIENTO ___________________________________ 57
4.2.1 Elementos bsicos de los diagramas _______________________ 57
4.2.2 Estructura de comportamiento. ____________________________ 59
4.3 GUAS DE DIAGRAMACIN. __________________________________________ 64
4.3.1 Trazado de comunicaciones. _____________________________ 65
4.3.2 Especializacin. ________________________________________ 67
5- ANLISIS DE REQUISITOS Y PROCESOS DE NEGOCIO............................. 71
5.1 PERCEPCIONES DE LA REALIDAD _____________________________________ 71
5.1.1 Observacin de eventos o de individuos_____________________ 73
5.1.2 Elementos del sistema objeto _____________________________ 74
5.1.3 Entradas y salidas: lo bsico y lo derivado ___________________ 75
5.1.4 Niveles organizacionales_________________________________ 76
5.2 PROCESOS Y OBJETOS. ____________________________________________ 77
5.2.1 Dinmica de los objetos derivados _________________________ 78
5.3 ESTRATEGIAS DE ANLISIS DE INTERACCIONES___________________________ 78
5.3.1 Estrategias directas _____________________________________ 78
5.3.2 Estrategias inversas ____________________________________ 79
5.3.3 Estrategias internas_____________________________________ 80
5.4 CRITERIOS DE UNIDAD EN LOS PROCESOS DE NEGOCIO_____________________ 81
5.5 LOS REQUISITOS DEL MBITO PROCESO________________________________ 82
5.6 ELEMENTOS DE UNA DESCRIPCIN DE REQUISITOS PROCESO ________________ 82
5.7 ANLISIS DEL COMPORTAMIENTO COMUNICATIVO _________________________ 85
5.7.1 Anlisis generativo _____________________________________ 85
5.7.2 Anlisis de salidas vinculadas. ____________________________ 89
5.7.3 Consultores de auditora _________________________________ 90
5.7.4 Constructores vinculados ________________________________ 91
5.7.5 Anlisis de Objetos de negocio. ___________________________ 92
5.7.6 La busqueda de interacciones comunicativas a partir de objetos de negocio
93
6- ESPECIFICACIN DE SUCESOS..................................................................... 97
6.1 REQUISITOS ASOCIADOS A UN SUCESO_________________________________ 97
6.2 IDENTIFICACIN Y NOMINACIN DE SUCESOS. ____________________________ 97
6.3 ESPECIFICACIN DE SUCESOS DE ENTRADA. _____________________________ 98
6.3.1 DESCRIPCIN GENERAL _______________________________ 98
6.3.2 DESCRIPCIN DEL CONTACTO _________________________ 99
6.3.3 DESCRIPCIN DE LA COMUNICACIN __________________ 100
6.3.4 DESCRIPCIN DE LA REACCIN DEL SISTEMA___________ 106
6.3.5 Requisitos comunicativos del mbito de uso ________________ 110

iii
6.3.6 Requisitos comunicativos del mbito del suceso._____________ 110
6.4 ESTRUCTURAS DE ADQUISICIN _____________________________________ 111
6.4.1 Notacin para la definicin de estructuras de mensajes _______ 111
6.4.2 Operaciones de adquisicin de datos______________________ 112
6.4.3 Derivacin de estructuras _______________________________ 114
6.4.4 Especializacin _______________________________________ 121
7- SUCESOS Y ESTADO..................................................................................... 123
7.1.1 Sucesos y Objetos ____________________________________ 123
7.1.2 Sucesos y Clases de Sucesos ___________________________ 125
7.1.3 Sucesos y estados ____________________________________ 125
7.1.4 Relaciones de Cardinalidad _____________________________ 126
7.1.5 Diagramas de sucesos y diagramas de estados _____________ 127
7.1.6 Especializacin de comportamiento y estado. _______________ 129
8- REQUISITOS DE USO..................................................................................... 131
8.1 LOS SUCESOS EN EL ENTORNO DE USO _______________________________ 131
8.2 SOPORTE A LA LOCALIZACIN. ______________________________________ 133
8.2.1 Localizacin de clases de funciones. ______________________ 133
8.2.2 Localizacin de instancias de objetos______________________ 135
8.3 SOPORTE EDITORIAL______________________________________________ 135
8.3.1 Compatibilidad editorial: Contextos editoriales. ______________ 136
9- EL ANLISIS........................................... ERROR! MARCADOR NO DEFINIDO.
9.1 ACTORES ______________________________________________________ 141
9.2 FUENTES DE INFORMACIN. ________________________________________ 141
9.3 ENTREVISTAS. __________________________________________________ 142
9.3.1 Consideraciones generales sobre las entrevistas ____________ 142
9.3.2 El proceso de la entrevista ______________________________ 143
9.4 ENTREVISTAS Y MBITOS DE LOS REQUISITOS. __________________________ 147
9.4.1 Las entrevistas iniciales ________________________________ 147
9.4.2 Las entrevistas del mbito proceso________________________ 151
9.4.3 Cuestionarios. __________________ Error! Marcador no definido.
Requisitos
1
1 11 1- -- - Requisitos Requisitos Requisitos Requisitos
1.1 LA MOTIVACIN
Cuando se justifica la necesidad de los requisitos encontramos dos argumentos en la literatura. El
primero es externo. Se basa en la comparacin con procesos constructivos de reas ajenas al
software. Concretamente con la arquitectura. Si los arquitectos usan planos y presupuestos Por
qu los informticos no lo hacen? Nadie parece decepcionado con su casa.
El segundo tipo de argumento es interno. Se basa en un famoso y cuestionado informe de 1994.
El Standish Group Chaos Report. La consultora IT Cortex recoge en su web diferentes informes
sobre fracaso de proyectos. http://www.it-cortex.com
1.1.1 The Chaos Report (1995) The Chaos Report (1995) The Chaos Report (1995) The Chaos Report (1995)
The Chaos Report is the first survey made by the Standish Group. This report is landmark
study of IT project failure. It is cited by everybody writing a paper or making a presentation were a
reference is made of IT project failure.
1 11 1 Scope of the Study Scope of the Study Scope of the Study Scope of the Study
The respondents to the Standish Group survey were IT executive managers. The sample includes
large, medium, and small companies across major industry segments : banking, securities,
manufacturing, retail, wholesale, heath care, insurance, services, and local, state, and federal
organizations. The total sample size was 365 respondents representing 8,380 applications. In
addition, The Standish Group conducted focus groups and personal interviews to provide
qualitative context for the survey results.

2 Key Fin Key Fin Key Fin Key Findings dings dings dings
The Standish Group research shows a staggering 31.1% of projects will be canceled before they
ever get completed. Further results indicate 52.7% of projects will cost over 189% of their
original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg.
The lost opportunity costs are not measurable, but could easily be in the trillions of dollars in the
United States alone.
Based on this research, The Standish Group estimates that in 1995 American companies and
government agencies will spend $81 billion for canceled software projects. These same
organizations will pay an additional $59 billion for software projects that will be completed, but
will exceed their original time estimates. The Standish Group estimates that almost 80,000
projects were cancelled in 1995. Risk is always a factor when pushing the technology envelope,
but many of these projects were as mundane as a drivers license database, a new accounting
package, or an order entry system.
On the success side, the average is only 16.2% for software projects that are completed on-time
and on-budget. In the larger companies, the news is even worse: only 9% of their projects come
in on-time and on-budget. And, even when these projects are completed, many are no more than
a mere shadow of their original specification requirements. Projects completed by the largest
American companies have only approximately 42% of the originally-proposed features and
functions. Smaller companies do much better. A total of 78.4% of their software projects will get
deployed with at least 74.2% of their original features and functions.
This data may seem disheartening, and in fact it is, 48% of the IT executives in our research
sample feel that there are more failures currently than just five years ago.
Pero el Standish report no es el nico informe de fracaso.
1.1.2 The Robbins The Robbins The Robbins The Robbins- -- -Gioia Survey (2001) Gioia Survey (2001) Gioia Survey (2001) Gioia Survey (2001)
Robbins-Gioia, LLC, a provider of management consulting services located in Alexandria - Virginia,
made a study over the perception by enterprises of their implementation of an E.R.P. (Enterprise
Resource Planning) package.
1 Survey Scope Survey Scope Survey Scope Survey Scope
232 survey respondents spanning multiple industries including government, Information
Technology, communications, financial, utilities, and healthcare.
A total of 36 % of the companies surveyed had, or were in the process of, implementing an ERP
system.
2 Key Findings Key Findings Key Findings Key Findings
51 % viewed their ERP implementation as unsuccessful
46 % of the participants noted that while their organization had an ERP
system in place, or was implementing a system, they did not feel their
organization understood how to use the system to improve the way they
conduct business.
56 % of survey respondents noted their organization has a program
management office (PMO) in place, and of these respondents, only 36 % felt
their ERP implementation was unsuccessful
3 Comments on the Robins Comments on the Robins Comments on the Robins Comments on the Robins- -- -Gioia Survey Gioia Survey Gioia Survey Gioia Survey
Project failure is not defined by objective criteria but by the perception of the respondents. The
advantage of a perception is that it naturally integrates multiple aspects. Its obvious disadvantage
Requisitos
3
is that it is inevitably partial: if the respondent has taken an active role in the project it will
inevitably embellish the reality, whereas if the project has been "forced down his throat" he might
cast a grimmer look at the project outcome.
1.1.3 The Conference Board Survey The Conference Board Survey The Conference Board Survey The Conference Board Survey (2001) (2001) (2001) (2001)
1 11 1 Survey Scope Survey Scope Survey Scope Survey Scope
That survey interviewed executives at 117 companies that attempted ERP implementations
2 Key Findings Key Findings Key Findings Key Findings
34 % were very "satisfied.
58 % were "somewhat satisfied,
8 % were unhappy with what they got.
40 % of the projects failed to achieve their business case within one year of
going live
The companies that did achieve benefits said that achievement took six
months longer than expected.
Implementation costs were found to average 25 % over budget,
Supports costs were underestimated for the year following implementation by
an average of 20 %.
1.1.4 The KPMG Canada Survey (1997) The KPMG Canada Survey (1997) The KPMG Canada Survey (1997) The KPMG Canada Survey (1997)
In April 1997, KPMG Canada sent a survey questionnaire focusing on IT project management
issues to Canada's leading 1,450 public and private sector organizations. The main purpose was
to outline the reasons behind the failure of Information Technology projects.
1 Survey Scope Survey Scope Survey Scope Survey Scope
Out of 1,450 questionnaires sent, 176 were analyzed. Of these, 61 % reported details on a failed
IT project.
2 Key Findings Key Findings Key Findings Key Findings
Over 61 % of the projects that were analyzed were deemed to have failed by the respondents.
More than three quarters blew their schedules by 30% or more; more than half exceeded their
budgets by a substantial margin. Considering that an estimated $25 billion is spent on IT
application development in Canada annually, the survey data clearly indicate that unbudgeted IT
project expenditures must run into the billions of dollars.
1.1.5 The OASIG Study (1995) The OASIG Study (1995) The OASIG Study (1995) The OASIG Study (1995)
This study has been undertaken under the auspices of OASIG, a Special Interest Group in the UK
concerned with the Organizational Aspects of Information Technology.
1 Scope of the Study Scope of the Study Scope of the Study Scope of the Study
Information was collected in 1995 in the United Kingdom from a sample of 45 experts employed
primarily by Universities or Consultancies. On average they have each over 20 years personal
experience representing a cumulative knowledge base of over 900 years. Their drew their opinion
from a sample of approximately 14,000 user organizations. 31 of these interviewees (69%)

include consultancy work as a major component of their work, and 27 (60%) include research;
many do both. Their professional areas of expertise cover the domains of management, business,
and social science. A small number of those interviewed have a background in engineering.
Data were collected by interviewing researchers and consultants using a semi-structured interview
schedule. Some preparation was required by them. Each interview lasted, on average, around 1.5
to 2 hours, though some lasted considerably longer.
2 Key Findings Key Findings Key Findings Key Findings
The IT project success rate quoted revolves around 20-30% based on its most optimistic
interviews. Bottom line, at best, 7 out of 10 IT projects fail in some respect.
1.1.6 IT Cortex Conclusion IT Cortex Conclusion IT Cortex Conclusion IT Cortex Conclusion
The statistics presented here all converge to establish that:
an IT project is more likely to be unsuccessful than successful
about 1 out of 5 IT projects is likely to bring full satisfaction
the larger the project the more likely the failure



Requisitos
5
1.2 EL ESTADO ACTUAL

La situacin ha mejorado. Si nos atenemos a la opinin de David Rubisntein la mejora ha sido
sustancial. Del cien por cien. Lo que nos sita en el 2006 en una tasa de xito en proyectos del
35%.

Sin embargo, a pesar de no tener datos objetivos, la situacin no es boyante. Los usuarios siguen
pensando que los informticos no les entienden. Los informticos siguen pensando que los
usuarios no saben lo que quieren. Se mantiene un desentendimiento continuo que se traduce en
una actitud defensiva y medrosa por ambas partes.

Una persona que viaja en un globo aerosttico se da cuenta de que se ha perdido. Hace
descender el globo al ver una persona en un campo. Poco a poco se acerca y le pregunta:
-Disculpe, podra decirme donde estoy?
-S. Esta usted en un globo aerosttico a 8 metros de altura de este campo.
El del globo replica.
-Usted debe ser informtico.
-S, lo soy. Cmo lo ha sabido?
-Bueno, todo lo que me ha dicho es tcnicamente correcto pero no me sirve para nada.
-Ah! Pues usted debe ser consultor.
-S, lo soy. Cmo lo ha sabido?
-Porque no sabe donde est ni donde va y espera que yo le ayude. Est en la misma situacin en
que estaba antes de preguntarme pero ahora la culpa es ma.

Algunas aplicaciones simples de complejidad baja o media se desarrollan adecuadamente. Tienen
xito las aplicaciones universales porque en ellas el usuario se adapta a la aplicacin.
Cuando una organizacin ha sufrido diferentes fracasos acepta adaptarse a algo que por lo
menos funcione. Las consultoras han acuado el trmino gestin del cambio en realidad es un
eufemismo que describe como las organizaciones se rinden ante la imposibilidad de definir su
propia gestin.
Las aplicaciones adaptadas al usuario son cada vez ms raras. Prcticamente ningn profesional
propone un desarrollo a medida. Profesionales muy competentes temen este tipo de desarrollo y
se cobijan en los ERP y en la integracin. Los ERP proporcionan argumentos rotundos para
rechazar los caprichosos requisitos de los usuarios: No es posible hacerlo. Este tipo de
argumentacin no es viable con el desarrollo a medida. Pero en la mayora de los casos el usuario
no quiere pagar lo que cuesta.
1.3 REQUISITOS SOFTWARE
La ingeniera de requisitos parte de una concepcin ambigua del concepto de requisito. Cualquier
manual sobre requisitos del software adopta las definiciones del glosario del IEEE IEEE Standard
Glossary of Software Engineering Terminology (1997). Segn el cual un requisito se define como:
Una condicin o capacidad necesaria para un usuario para resolver un problema o
alcanzar un objetivo.
Una condicin o capacidad que tiene que cumplir o poseer un sistema o una
componente de un sistema para satisfacer un contrato, un estndar, una especificacin o
cualquier otro documento formalmente establecido.
Una representacin documentada de cualquier condicin o capacidad como las dos
anteriores
La primera definicin se orienta a la necesidad del usuario. La segunda tiene un trasfondo
defensivo. Responde a una necesidad de los desarrolladores por establecer los lmites y alcance de
su trabajo. En la visin contractual se busca definir las reglas del juego para que los costes de un
proyecto no se disparen arbitrariamente. El frecuente desencuentro entre analistas y usuarios hace
que cada parte intente resguardarse de los riesgos.
Requisitos
7
De modo que se ha acuado el eufemismo gestionar al cliente para reflejar esta actitud de
proteccin frente a la volubilidad del cliente. La gestin del cliente por parte del ingeniero de
requisitos comprende la firma de un documento de requisitos que exima a la empresa de
desarrollo de responsabilidades ms all de lo razonable. Pero tambin incluye saber convencer
al cliente que lo que pide debe mantenerse en lo razonable.
Lo razonable siempre suele estar vinculado a los resultados y capacidades que la empresa que
desarrolla espera y ofrece.
Estas definiciones, por s solas, no permiten establecer un concepto homogneo, y por tanto de
calidad, de requisito. La literatura de requisitos y el aprendizaje del concepto y de su uso
metodolgico se hace a travs de ejemplos y discusiones. En realidad cualquier concepto utilizado
en ingeniera de software o en el desarrollo de sistemas de informacin es siempre interpretado
de forma amplia. En [Hulburt 1993] se estudian ms de treinta formas de entender y aplicar los
casos de uso. Esto significa que los trminos y conceptos que estamos usando son ambiguos y
favorecen la actitud subjetiva en detrimento de la norma y lo estndar.
En la actualidad la mayora de autores coinciden en que los requisitos deben mostrar el carcter
externo del sistema. El que ser percibido por los usuarios. Esta idea ha sido recogida durante
mucho tiempo en la frase los requisitos deben mostrar qu hace el sistema y no el cmo. Ni
siquiera esta separacin del qu y el cmo est clara. La disquisicin que Alan Davis, la mayor
autoridad en requisitos, hace del qu y el cmo le lleva a concluir que lo que para una persona
puede ser el qu para otra es el cmo. De modo que de nuevo estamos ante una definicin
ambigua y subjetiva. Es por ello que Davis define el concepto de requisito como funcin o funcin o funcin o funcin o
caracterstica necesarias de un sistema que puede percibirse externamente caracterstica necesarias de un sistema que puede percibirse externamente caracterstica necesarias de un sistema que puede percibirse externamente caracterstica necesarias de un sistema que puede percibirse externamente
Tom Gilb aporta una definicin de requisito basada en el valor o en la utilidad. Los requisitos son
sentencias que identifican aquellas las necesidades esenciales de un sistema que hacen que tenga
utilidad y valor.
1.3.1 Estructura de los requisitos Estructura de los requisitos Estructura de los requisitos Estructura de los requisitos
Las tcnicas de catalogacin de requisitos proponen una estructura nica y simple para los
requisitos. La figura siguiente muestra una plantilla para la especificacin de requisitos propuesta
por la empresa Volere fundada por Tom de Marco. Esta empresa ofrece informacin en la web
como soporte a la caracterizacin y bsqueda de requisitos.

Figura 1 Plantilla de requisito de volere

Esta estructura sera idntica para cualquier tipo de requisito. Adems los requisitos se organizan
mediante una lista numerada carente de orden o estructura.
Los requisitos se asociaran a sucesos o casos de uso, o a listas de ellos, para luego poder tener
trazabilidad de satisfaccin del usuario.
1.3.2 Ti Ti Ti Tipos de requisitos pos de requisitos pos de requisitos pos de requisitos
La recomendacin del estndar 830 del IEEE ofrece la siguiente tipologa de requisitos.

1 Introduccin
1.1 Propsito de la especificacin
1.2 Alcance del producto
1.3 Definiciones, acrnimos y abreviaturas.
1.4 Referencias.
1.5 Descripcin general del resto del documento.
2 Descripcin general
2.1 Perspectiva de producto
2.2 Funciones del producto
2.3 Caractersticas de usuarios
2.4 Restricciones generales
3 Requisitos especficos
3.1 Requisitos funcionales
3.1.1 Requerimiento funcional 1
3.1.1.1 Introduccin
3.1.1.2 Entradas
3.1.1.3 Proceso
3.1.1.4 Salidas
3.1.2 Requerimiento funcional 2
...
3.1.n Requerimiento funcional n
...
3.2 Requisitos de interfaces externas
3.2.1 Interfaces de usuario
3.2.2 Interfaces hardware
3.2.3 Interfaces software
3.2.4 Interfaces de comunicacin
3.3 Requisitos de rendimiento
3.4 Restricciones de diseo
3.4.1 Estndares
3.4.2 Limitaciones hardware
. . .
3.5 Atributos
3.5.1 Disponibilidad
3.5.2 Seguridad
3.5.3 Mantenimiento
3.5.4 Conversin
. . .
3.6 Otros requisitos
3.6.1 Base de datos
3.6.2 Operaciones
3.6.3 Adaptacin de la instalacin
Apndices
ndice
Figura 2 ANS!f!EEE std-830 patrn 1
Requisitos
9
La mayora de textos proponen dos tipos de requisitos los funcionales y los no funcionales.

Figura 3 Tipos de requisitos en la propuesta de volere
Para Ralph R. Young en The Requirements Engineering Handbook los requisitos pueden
adscribirse a los siguientes niveles:
1 Business Requirements
are the reason for developing systems and software in the first place. Business requirements
are the essential activities of an enterprise. Business requirements are derived from business
goals (the objectives of the enterprise or organization).
2 User Requirements
Users are the individuals or groups that use a system or software in its environment.
User requirements are their verified needs for that system or
software.
3 High-Level or System-Level Requirements
To enable comprehending a needed system, we refer to the high-level or
system-level requirements. This term relates to those requirements that
are foremost in importance, capture the vision of the customer, enable
defining the scope of the system, and allow estimating the cost and schedule
required to build the system. (Some system architects believe that the
requirements specification should contain every performance requirement.)
Its recommended that a workable number of requirements (on the order of
50 to 200) system-level requirements be identified for a large system. In
Chapter 8, we will discuss a set of business drivers that may be considered
high-level customer requirements, which often are not expressed.
4 Business Rules
Business rules2 provide the basis for creating the functional requirements.
They are as follows:
The policies, conditions, and constraints of the business activities supported by the
system;
The decision processes, guidelines, and controls behind the functional requirements (e.g.,
procedures);
Definitions used by the business;

Relationships and workflows in the business;
Knowledge needed to perform actions.
5 Nonfunctional Requirements
Nonfunctional requirements specify system properties, such as reliability and safety.
6 Derived Requirements
A derived requirement is one that is further refined from a higher-level requirement or a
requirement that results from choosing a specific implementation or system element. In a
sense, all requirements are derived from the system need; thus, the derived distinction tends
to have little significance. However, many systems engineers distinguish between externally
identified requirements and requirements that are derived under the control of the engineer.
7 Design Requirements and Design Constraints
For most system development efforts, design requirements/constraints appear right at the
beginning of the system formulation. Here are examples of why its difficult to separate
requirements engineering from design activities:
New systems are often installed in environments that already have other systems. The
other systems usually constrain the design of the new system. For example, a
requirement (design constraint) may be that the system to be developed must obtain its
information from an existing database. The database has already been designed and
parts of its specification will usually be included in the requirements document.
For large systems, some architectural design is often necessary to identify subsystems and
relationships. Identifying subsystems means that the requirements engineering process
for each subsystem can go on in parallel.
For reasons of budget, schedule, or quality, an organization may wish to reuse some or
all existing software systems in the implementation of a new system. This constrains both
the system requirements and the design.
If a system has to be approved by an external regulator (e.g., systems in civil aircraft), it
may be necessary to use standard certified design that has been tested in other systems.
8 Performance Requirements
One of the most difficult challenges in system development is defining and meeting the
performance requirements (sometimes referred to as dependability requirements). The
performance requirements define how well the functional requirements must perform.
Performance requirements analysis components are beyond the scope of this book, but are
described by Jeffrey O. Grady in Systems Requirements Analysis [8, pp. 238, 313, and 324].
Grady also provides a set of guidelines helpful in the identification of performance
requirements [8, pp. 323324]. Dependability requirements correspond to system-level needs
for availability, security, performance, reliability, and safety.
9 Interface Requirements
Another difficult challenge in system development is finding and defining the interface
requirements. Interface requirements analysis identifies physical and functional relationships
among system elements and between system elements and the system environment. One
project team member should be assigned principal responsibility for assuring coordination of
interface requirements. See [8, pp. 270297] for a good discussion of interface analysis and
techniques.
10 Verified Requirements
Verified requirements are real requirements that are met or satisfied in the design solution.
11 Validated Requirements
Validated requirements are requirements that are implemented in the delivered system. See
Jeffrey O. Gradys System Validation and Verification [9] for clear definitions of these terms,
Requisitos
11
detailed information concerning how to use these fundamental problem-solving tools, and
practical methods for each step of the process.
12 Qualification Requirements
Qualification refers to the verification or validation of item performance in a specific
application and results from design review, test data review, and configuration audits.

Para Robin F. Goldsmith en Discovering Real Business Requirements For Software Project
Success existen requisitos del negocio y requisitos del sistema. El problema para Goldsmith es
ms de enfoque. De intencin descriptiva. De nuevo estamos ante un caso del qu y el cmo. Del
problema y de la solucin.




Para Karl E. Wiegers (1999) en Software Requirements existen tres niveles de requisitos.
Requisitos de negocio, Requisitos de usuario y Requisitos funcionales y no funcionales. Estos
niveles de requisitos estaran alineados con la aproximacin de RUP.
Los requisitos de negocio requisitos de negocio requisitos de negocio requisitos de negocio conduciran al documento de visin y alcance que contiene los
objetivos de alto nivel que la organizacin requiere del producto.
Los requisitos de usuario requisitos de usuario requisitos de usuario requisitos de usuario describen las tareas que los usuarios deben acometer con el producto.
Los requisitos de usuario se capturan mediante descripciones de casos de uso o escenarios.

Por ltimo los requisitos funcionales funcionales funcionales funcionales definen la funcionalidad del software que deben construir
los desarrolladores para acometer sus tareas satisfaciendo los requisitos de negocio.
Wiegers define una caracterstica caracterstica caracterstica caracterstica (feature) como un conjunto de requisitos funcionales
lgicamente relacionados que proporcionan una capacidad al usuario que permite satisfacer un
requisito de negocio.
Lo que algunos autores proponen como requisitos de negocio solo son requisitos genricos o con
mayor nivel de abstraccin. Por ejemplo Wiegers [Wiegers 1999 pag 9] propone el siguiente
requisito de negocio los usuarios sern capaces de corregir los errores ortogrficos en un
documento de forma eficiente.
La sentencia contiene dos aspectos. Una funcionalidad genrica que deber descomponerse en
un conjunto de funciones bsicas que la satisfagan. Pero adems contiene una palabra que no
debera ser aceptada como parte de un requisito eficiente. Eficiente es una calificacin cuya
mtrica es subjetiva y por tanto su satisfaccin depende del usuario que en cada momento se
relaciones con la aplicacin.
Los requisitos presentan varias facetas. Una es su genericidad. Los requisitos pueden ser genricos
o especficos. A su vez los requisitos genricos pueden ser refinables o propagables. As el
requisito anterior propuesto por Wiegers es genrico. Deber refinarse en toda la variedad de
funciones necesarias para dar cuerpo a un corrector ortogrfico.
Otra faceta de los requisitos es su validabilidad o testeabilidad. Un requisito puede ser
objetivamente testeable o no. Cuando un requisito es objetivamente testeable existe un mtodo
para evaluar su satisfaccin independiente del usuario. Un requisito no es objetivamente testeable
si su satisfaccin depende de la interpretacin de cada usuario. Obviamente la diferencia es
importante. En un caso la testeabilidad es una propiedad del requisito. En el otro es una
propiedad de la relacin entre el requisito y el usuario.
Requisitos
13
1.3.3 Necesidades y caractersticas Necesidades y caractersticas Necesidades y caractersticas Necesidades y caractersticas
Algunos autores de manuales de casos de uso vinculados a RUP han aadido dos niveles sobre los
requisitos. Se trata de necesidades y caractersticas. El manual de Dean Leffingwell Managing
Software requirements with Use Cases es uno de ellos.


Para Leffingwell una caracterstica es a service that the system provides to fulfill one or more
stakeholder needs. Pero en el captulo 9, dice Features are a convenient way to describe
functionality without getting bogged down in detail.
Por lo tanto las features seran la funcionalidad en un determinado nivel de abstraccin.

1.4 DONDE EST EL PROBLEMA?
No hay una verdadera visin externa No hay una verdadera visin externa No hay una verdadera visin externa No hay una verdadera visin externa
Hay un error en el enfoque. Que al final haya que construir una aplicacin no significa que los
requisitos deben ser determinados desde el punto de vista de cmo se usar la aplicacin. Los
casos de uso son especialmente perjudiciales en esta visin. Sacralizan la definicin de cmo se
hacen las cosas y de cmo reaccionar el sistema por encima de qu hay que hacer.
A pesar de que todas las propuestas consideran la importancia del usuario el lenguaje de los
requisitos es inmanejable para el usuario.


Los Los Los Los requisitos requisitos requisitos requisitos no pueden ser una lista desestructurada no pueden ser una lista desestructurada no pueden ser una lista desestructurada no pueden ser una lista desestructurada
Hay una pobreza a la hora de estructurar los requisitos. Las listas planas de requisitos son
totalmente inapropiadas para sistemas de informacin. Esta pobreza estructural se intenta
mejorar con la nueva idea de trazabilidad. Solo se trata del problema detrs del problema. Como
no se ha sabido estructurar adecuadamente los requisitos se ofrece una herramienta que
relaciones requisitos, necesidades, caractersticas... Es un error para corregir un error.
Imagine que un usuario debiera aceptar la construccin de su casa en base a una lista de
requisitos del tipo:
...
Los diferentes tipo Los diferentes tipo Los diferentes tipo Los diferentes tipos de sistemas tienen tipos de s de sistemas tienen tipos de s de sistemas tienen tipos de s de sistemas tienen tipos de requisitos requisitos requisitos requisitos diferentes y formas de diferentes y formas de diferentes y formas de diferentes y formas de
investigarlos diferentes. investigarlos diferentes. investigarlos diferentes. investigarlos diferentes.
Hay un error al creer que las interacciones de informacin son equiparables a las interacciones de
materia y energa. Los requisitos para artefactos no se analizan igual que los requisitos para
describir el conocimiento humano. No tiene nada que ver el problema fsico de beber una taza de
caf con el problema lgico de representar la informacin de un pedido. Los vendedores de
herramientas de requisitos pretenden que los requisitos para construir un velero son equiparables
a los requisitos para construir una gestin de pedidos.

El concepto es ambiguo El concepto es ambiguo El concepto es ambiguo El concepto es ambiguo y los ejemplos o casos asociados no aportan claridad. Hay una increble
dejadez a la hora de mostrar ejemplos de requisitos. El significado de los conceptos se basa tanto
en el propio concepto como en las instancias que asociamos a l. Los ejemplos de requisitos son
instancias del concepto de requisito. Lo que se ve por ah es de muy poca calidad. Por ejemplo, el
libro de Leffingwell ofrece pocos ejemplos de requisitos. Existe un desarrollo parcial en el anexo y
ciertas referencias indirectas cuando se trata de ver los atributos de los requisitos. Los requisitos
que se muestran a continuacin estn extrados del libro de Leffingwell. Estos requisitos ni son
problemticos ni son representativos del verdadero trabajo de un ingeniero de requisitos. No
supone ningn problema obtenerlos y no hace falta escribir un libro para explicarlos. Pueden
suponer menos del 1 por mil de los requisitos de un sistema.

Requisitos
15




Es tambin curiosa la explicacin que aparece en el caso de estudio propuesto para el curso
Rational Requirements Management with Use Cases Version 5.5. El caso de estudio es un
ejemplo de un ascensor. En la segunda pgina contiene la siguiente nota:
Disclaimer: This is a fictitious system and does not claim to be a model for a good
Software Requirement Specification. It is used for exercise purpose only.
Bueno, si uno vende una herramienta con un curso lo menos que puede hacer, ya que la
herramienta es cara, es proporcionar esplndidos ejemplos.
La especificacin que se propone es un modelo de cmo no deben hacerse especificaciones.
La realidad es que toda la literatura de requisitos, toda, se propone para resolver el desarrollo de
sistemas complejos y, en el mejor de los casos, se escenifica con ejemplos que ni son complejos ni
son problemas. No se conoce software problemtico de cajeros automticos ni de ascensores. El
software problemtico siempre es de otro tipo de sistemas. Los sistemas de informacin en los
que las interacciones estn vinculadas a interpretaciones significativas para las personas humanas.

Como consecuencia de todo lo anterior Como consecuencia de todo lo anterior Como consecuencia de todo lo anterior Como consecuencia de todo lo anterior se produce un error generalizado en la forma de
abordar los requisitos en el desarrollo de sistemas de informacin. Un sistema de informacin
intercambia informacin, en forma de mensajes, con su entorno. Ni ms ni menos. Los requisitos
esenciales de un sistema de informacin son el conjunto de mensajes que el sistema requiere. Esto
no parece preocuparle al mundo de los casos de uso.
1.5 SOLUCIONES?
El problema de la ausencia de visin externa ausencia de visin externa ausencia de visin externa ausencia de visin externa es difcil de solucionar. Puede llegarse a una
solucin aproximada. Si por ejemplo hablamos de sistemas de informacin la visin externa est
definida por las necesidades de informacin de los usuarios. No por como manipulan un
programa. Pero, incluso con una visin comunicativa y externa, no es fcil establecer las
verdaderas necesidades de informacin que una persona requiere para su trabajo. Entramos en el
mundo de los significados, de la semitica y hacen falta consideraciones no tcnicas para resolver
este problema.
Frente al problema de la no estructuracin de los requisitos sera no estructuracin de los requisitos sera no estructuracin de los requisitos sera no estructuracin de los requisitos sera bueno disponer de una
taxonoma de requisitos que permitiera clasificarlos y estructurarlos adecuadamente. Que
permitiera conocer cuales son las omisiones. Por dnde puede encaminarse la bsqueda. Qu
estamos dejando de lado.
Frente al problema de los diferentes tipos de sistemas diferentes tipos de sistemas diferentes tipos de sistemas diferentes tipos de sistemas sera conveniente ofrecer estrategias de
anlisis diversas. No es posible que exista un mtodo universal que sirva para todo.
Frente al problema de la ambigedad de ambigedad de ambigedad de ambigedad del concepto l concepto l concepto l concepto sera bueno disponer de definiciones menos
ambiguas. Ms rigurosas. Que permitieran que los ingenieros adquirieran seguridad en el uso de
los conceptos. Toda definicin subjetiva de un concepto como un requisito define el qu hace el
sistema y no el como impide fundamentar actividades de ingeniera. Si cada persona puede
interpretar de forma diferente el mundo que observa no podemos hablar de una ingeniera de
requisitos. Ms bien se tratara de una artesana. Lo que realmente es. Las especificaciones de
requisitos dependen ms de la capacidad de las personas que de los mtodos existentes.
Requisitos en Sistemas de Informacin
17
2 22 2- -- - Requisitos en Sist Requisitos en Sist Requisitos en Sist Requisitos en Sistemas de Informacin emas de Informacin emas de Informacin emas de Informacin
Los requisitos no tienen la simplicidad estructural ni la homogeneidad que proponen la mayora
de manuales. Se definen en diferentes mbitos y con diferentes niveles de detalle. Consideraremos
las siguientes facetas para tipificar requisitos:
1. Entradas y salidas: Los requisitos de un sistema de informacin estn esencialmente
constituidos y organizados entorno a los mensajes de entrada y de salida que el sistema
requiere para cumplir sus funciones.
2. Eventos y objetos: Los requisitos de un sistema de informacin pueden derivarse de
expresiones que describen de dos maneras la realidad. Expresiones en las que se
describen los fenmenos del mundo como objetos a travs de sus propiedades
caractersticas o expresiones sobre los cambios que se producen en los objetos del
mundo.
3. Los mbitos: definen diferentes niveles desde los que se pueden considerar los requisitos.
Todo requisito debe adscribirse a un tipo de componente o encapsulamiento sistmico.
En principio consideraremos tres mbitos distinguidos: reas de negocio, procesos de
negocio e interacciones comunicativas.
4. Genericidad de un requisito: Los requisitos se expresan en un cierto mbito pero pueden
ser genricos o especficos. Los requisitos de cualquiera de los mbitos presentados
deben concretarse mediante requisitos ms especficos. Existen dos formas de concrecin
de requisitos: la propagacin y el refinamiento.
Un requisito es propagable cuando afecta a una clase de elementos de un mbito. Por
ejemplo:en el proceso de facturacin todos los importes se calcularn con una
precisin de 9 decimales es un requisito expresado en el mbito del proceso de
facturacin propagable a todas las definiciones de dominio para atributos de importe.
Un requisito es refinable cuando se puede concretar mediante una coleccin de
requisitos de mbito menor. Por ejemplo, un requisito de un mensaje de entrada
(Suceso 3 El sistema permitir la asignacin de vehculos y conductores a las hojas de
expedicin) se debe refinar mediante requisitos que definan la comunicacin y la
reaccin del suceso. Un suceso es un requisito. Lo que ocurre es que es un requisito

complejo. Los requisitos complejos se refinan dando lugar a una estructura compleja
de requisitos.
5. Criterios de satisfaccin
Objetivos: Independiente de las personas que la verifican. En ese caso existe alguna
mtrica especfica, algn procedimiento normado para comprobar que el requisito se
ha satisfecho.
Subjetivos: Dependiente de la persona que aplica el criterio. El criterio es interpretable.
Ya no es una propiedad del requisito sino una propiedad de la relacin entre la
persona y el requisito.
2.1 ENTRADAS Y SALIDAS
El problema del anlisis de requisitos es tan trivial como preguntar a los usuarios que informacin
necesitan conocer y como quieren verla.
La necesidad de una organizacin es la informacin, el disponer de ella. El jefe de compras de una
empresa querr saber las previsiones de ventas de las prximas semanas para poder establecer la
poltica de compras. El jefe de fabricacin querr conocer el detalle de los pedidos existentes para
poder planificar las rdenes fabricacin. El director comercial querr conocer la variacin en las
tendencias de pedidos de sus clientes para poder gestionar eficazmente su poltica de ventas.
La informacin es requerida por diferentes miembros de una organizacin para poder tener un
mejor control y eficacia en las funciones que debe acometer.
Si todas estas personas pudieran prescindir de la informtica seran felices. Su necesidad es saber
su problema como poder disponer de este conocimiento. Es decir un sistema de informacin tiene
valor porque ofrece informacin adecuada para el desempeo de las funciones de la
organizacin. El sistema de informacin tiene el inconveniente de que requiere que se le
comuniquen todos aquellos hechos que luego se quieren conocer. Esas suele ser, desde el punto
de vista de los usuarios, el mayor inconveniente. Introducir los datos.
Es decir, la esencia de un sistema de informacin son los mensajes de salida que tiene que
proporcionar a los miembros organizacin para facilitar les su trabajo.
Para poder suministrar estos mensajes de salida habr que definir que mensajes entrada son
necesarios. Es decir cmo queremos disponer de informacin habr que organizar una red de
chivatos que se ocupen de capturar y obtener la informacin que necesitamos
2.1.1 El SI como sistema de comunicaciones El SI como sistema de comunicaciones El SI como sistema de comunicaciones El SI como sistema de comunicaciones
Un SI es un subsistema de un sistema social responsable de proporcionar a los actores que lo
requieran los datos necesarios para poder acometer sus funciones.
Existen dos intenciones de comunicacin en el mbito del sistema de informacin.
Poner en conocimiento del sistema la existencia de nuevos fenmenos que han ocurrido
en el sistema objeto. Se trata de los m mm mensajes de entrada ensajes de entrada ensajes de entrada ensajes de entrada o sucesos constructores.
Obtener informacin sobre los hechos conocidos por el sistema. Los m mm mensajes de salida ensajes de salida ensajes de salida ensajes de salida
o sucesos consultores.

Los procesadores de entrada y salida que propone el modelo ISO son responsables de entablar
estas comunicaciones.
Requisitos en Sistemas de Informacin
19

Figura + Nensajes de entrada y de salida en un sistema de informacin.

Los mensajes de entrada se obtienen mediante la red de adquisicin de informacin que el
sistema despliega. Supone el estudio, a diferentes niveles comunicativos, de los modos, tiempos y
recursos ms adecuados para captura la informacin. El subsistema de adquisicin de informacin
debe estar adaptado al quehacer organizacional.
El sistema de informacin debe tener mecanismos que le permitan conocer los cambios que se
producen en el sistema objeto.

Figura 5 Comunicacin de los sucesos que ocurren en el sistema objeto
Cuando un cambio se ha producido en el sistema objeto, cuando algo sucede sucede sucede sucede, , , , cuando ocurre un
suceso suceso suceso suceso, algn agente del sistema debe informar de lo sucedido. En ocasiones puede transcurrir un
tiempo entre la ocurrencia de las cosas y su comunicacin al sistema. En cualquier caso la
informacin sobre lo sucedido debe llegar de alguna forma a la frontera del sistema de
informacin. Debe llegar a su entorno que pertenecer al sistema social.
Hablaremos de mensajes de salida o sucesos de consulta para referirnos a las comunicaciones que
el sistema ofrece a los diferentes actores sociales cuando lo solicitan. En tal caso el sistema se
convierte en un emisor que transmite a los actores representaciones del conocimiento que
acumula. Aqu la comunicacin no viene determinada por la observacin directa del sistema
objeto. Se trata de una necesidad de informacin para el desempeo de alguna funcin
especfica.



Figura 6 Comunicacin del conocimiento acumulado por el sistema de informacin
Es de gran importancia para el anlisis de sistemas de informacin la conciencia de las actitudes
comunicativas. El analista debe comprender el contexto de los mensajes comunicados entre
usuarios y sistema. Es decir, debe comprender el significado que cada mensaje tiene para los
diferentes tipos de usuario.
2.2 EVENTOS Y OBJETOS
Los fenmenos que observamos del mundo son complejos y de carcter dinmico. Los seres
humanos observan estos fenmenos sabiendo que son procesos pero los perciben y describen
estticamente. Nuestras limitaciones cognitivas nos llevan a considerarlos de forma esttica o
discreta. La evidencia del carcter dinmico de las cosas est presente desde los filsofos
presocrticos.

Figura 1. Taxonoma de procesos de Sowa
Una observacin sobre el mundo es una correspondencia entre procesos y propiedades. Aunque
el mundo pueda estar constituido por procesos slo sabemos describirlo en trminos de objetos y
propiedades.
Para Jon Sowa los procesos pueden ser continuos o discretos. Estos ltimos estn constituidos por
los eventos y por los estados.
El nico aspecto que percibimos de los procesos es su variabilidad. Variabilidad que detectamos
pero que no siempre identificamos. Cuando observamos una catarata somos conscientes de
percibir un proceso. Sin embargo no somos capaces de identificar estados. Nuestra capacidad
descriptiva est limitada por nuestra capacidad de identificacin de cosas. Como no disponemos
Requisitos en Sistemas de Informacin
21
de identificadores para las gotas de agua no podemos dar una descripcin de estado compositiva
de la catarata. Nuestra percepcin se limita a predicar propiedades estadsticas de las
componentes como el caudal.
2.2.1 Percepcin de Eventos e individuos. Percepcin de Eventos e individuos. Percepcin de Eventos e individuos. Percepcin de Eventos e individuos.
La composicin de objetos y propiedades es una forma de ver o intuir los procesos. Un proceso
es un fenmeno dinmico en el que somos capaces de percibir objetos relacionados. Percibimos
que existen patrones de relaciones entre objetos que se repiten en el tiempo con ciertas
analogas. Esa percepcin es nuestra intuicin de los procesos. No sabemos si existe un nico
proceso universal. Creemos que existen diferentes procesos que no se influyen o que estn
dbilmente influidos.
Nuestra observacin se limita a aislar aquellas caractersticas relacionadas que pensamos que
describen un proceso. Nuestras limitaciones cognitivas se traducen en una fragmentacin fragmentacin fragmentacin fragmentacin
continua de los fenmenos.
Dos son las percepciones percepciones percepciones percepciones que tenemos de los procesos: Eventos e individuos.
Un individuo, un objeto, es el resultado de la observacin de un proceso en el que no somos
capaces de percibir fluctuaciones o no tenemos la capacidad o el inters de constatarlas (aunque
a veces podamos suponer que ese individuo podr cambiar en otras observaciones). As
percibimos una montaa como un individuo, un objeto esttico. Aunque sabemos que un monte
como el Everest est cambiando continuamente.
Un evento es el resultado de una observacin de un proceso en la que somos capaces de percibir
fluctuaciones que describimos mediante propiedades.
Cuando una organizacin se dota de un sistema de informacin los fenmenos en el sistema
objeto pueden ser percibidos de forma esttica o dinmica. Incluso un mismo tipo de fenmenos
puede ser percibido estticamente por unas personas o dinmicamente por otras.
Ambos tipos de fenmenos estn relacionados. Todo fenmeno esttico es siempre generado
por, al menos, un fenmeno dinmico. Podemos considerar a las personas como un fenmeno
esttico (una entidad persona) o como el resultado de fenmenos dinmicos (nacer... morir).
Las percepciones dependen de su relacin con los tipos de fenmenos en cuestin.
Individuos y eventos son formas complementarias de nuestra percepcin del mundo.

2.3 MBITOS DE LOS REQUISITOS


Figura 7 Ambitos de requisitos.




Requisitos en Sistemas de Informacin
23
2.3.1 E EE El mbito sistema l mbito sistema l mbito sistema l mbito sistema
Las descomposiciones iniciales de un sistema tienen siempre la intencin de reducir la
complejidad. Este tipo de refinamientos se denomina tambin functional breakdowns.
Cuando refinamos un sistema podemos utilizar criterios diversos. Orgnicos: las interacciones que
se dan en un determinado departamento. Funcionales: las interacciones que pueden ocurrir para
llevar a cabo una determinada gestin. Temporales: las interacciones que tienen lugar antes de
que se celebre un evento, las que pueden ocurrir durante su celebracin y las que pueden ocurrir
una vez finalizado. Objetuales: las interacciones que afectan a un tipo de objeto dado. Es posible,
incluso, cambiar el criterio cada vez que procedemos a un refinamiento.
La intencin de reduccin de complejidad conduce a subsistemas cuyas componentes no son
interacciones bsicas, no son sucesos, ni requieren un orden temporal entre ellas, aunque pueda
existir. Por ejemplo en una organizacin el subsistema o rea de comercial compuesta por la
gestin de pedidos, la gestin de compras y la gestin de incidencias nos permite abordar el
estudio de cada una de ellas de forma prcticamente independiente de las otras, satisfaciendo as
el criterio de reduccin de complejidad.
2.3.2 El mbito de proceso. El mbito de proceso. El mbito de proceso. El mbito de proceso.
Los procesos de negocio estn siempre vinculados a eventos e individuos. Un proceso describe el
conjunto de cambios, sucesos comunicativos, a los que se somete un determinado individuo que
denominamos objeto de negocio. El trmino objeto de negocio no coincide con el concepto de
objeto que se utiliza para el modelado de datos. Los objetos de datos, las clases de objetos, son
formas fragmentarias mediante las cuales podramos representar un objeto de negocio. Un objeto
de negocio es una estructura de informacin compleja que para los usuarios adquiere sentido por
su composicin y propiedades y por los procesos que lo manipulan.
Pueden ser objetos de negocio un pedido, una factura, un expediente de licitacin o un
prstamo. Cada uno de estos objetos de negocio podra ser descrito mediante un modelo de
datos compuesto por varias clases de objetos. En realidad los objetos de negocio corresponderan
ms bien al concepto de esquema externo o de vista utilizado en las bases de datos.
El proceso supone una ordenacin en el tiempo de los diferentes cambios que puede sufrir el
objeto de negocio hasta que se considera finalizado.
En el mbito de los procesos consideraremos por lo tanto dos aspectos complementarios:
El conjunto de cambios, aportaciones de valor o eventos que un objeto puede sufrir
La estructura y caractersticas, es decir el estado, del objeto de negocio que se procesa
Los requisitos asociados a un proceso estn constituidos fundamentalmente por mensajes de
entrada y mensajes de salida.
o Las diferentes entradas que informan de los cambios que se producen en un objeto de
negocio.
o Las diferentes salidas que informan de estos cambios a quien lo necesite.
o Las diferentes salidas que dan una visin del estado de los objetos de negocio que estn
siendo o han sido procesados en algn momento dado.
.1 .1 .1 .1 Sistema, Areas y Procesos. Sistema, Areas y Procesos. Sistema, Areas y Procesos. Sistema, Areas y Procesos.
Sistemas, reas y procesos constituyen una forma de descomponer un sistema mediante
diferentes niveles de abstraccin. Los sistemas pueden componerse de reas. Las reas pueden
componerse a su vez de otras reas menores o de procesos. Sistemas, reas y procesos se utilizan
cuando los sistemas son complejos y necesitamos compartimentar obteniendo partes ms
pequeas y manejables.

La delimitacin de las reas es subjetiva. Diferentes personas podran ver diferentes
organizaciones de reas en una misma organizacin.
La delimitacin de los procesos es tambin subjetiva. Diferentes personas podran incluir ms o
menos interacciones en cada proceso.
Pero los procesos marcan un nivel de fractura importante en el sistema. Contienen como
elementos componentes las interacciones comunicativas bsicas del sistema. Esas interacciones ya
no pueden descomponerse ms sin prdida de sentido.
2.3.3 El mbito de las interacciones comunicativas. El mbito de las interacciones comunicativas. El mbito de las interacciones comunicativas. El mbito de las interacciones comunicativas.
Delimitar adecuadamente el mbito de las interacciones es de gran importancia para el
establecimiento de los requisitos. En sistemas de informacin para la gestin, las interacciones
entre el sistema y el entorno son comunicaciones que se establecen intercambiando mensajes.
Estos mensajes estn asociados a sucesos constructores que comunican la ocurrencia de nuevos
acontecimientos en el sistema objeto que interesa a una organizacin. Los procesos de negocio
tienen que ver sobre todo con los cambios que se producen en un objeto de negocio y, por tanto,
con los sucesos constructores que informan de los cambios que se producen en el mundo.
En las comunicaciones que se establecen entre el entorno y el sistema de informacin aparecen,
de forma esencial, tres de las funciones comunicativas establecidas por el lingista ruso Roman
Jakobson.
La funcin de contacto porque la comunicacin de todo mensaje requiere el
establecimiento previo de una conexin, una toma de contacto.
La funcin descriptiva porque el objetivo de las comunicaciones en los sistemas de
informacin es describir fenmenos que ocurren en el sistema objeto.
La funcin de influencia porque la organizacin disea sus comunicaciones para poder
reaccionar, segn sus propsitos, ante los fenmenos que ocurren.
Cada interaccin comunicativa es un requisito para el sistema que habr que desarrollar. Es un
requisito genrico que debe ser refinado a travs de una estructura dictada por esas tres
funciones: contacto, descripcin e influencia.
Esos tres aspectos estn vinculados a la idea de evento o suceso habitual en el modelado
conceptual.
Un suceso comunicativo es una interaccin de comunicacin entre el entorno y el sistema de
informacin. El suceso comunicativo tiene lugar porque algo ha ocurrido en el sistema objeto de
inters que la organizacin observa. Algn agente del entorno organizacional ha tenido
conocimiento del fenmeno ocurrido y lo comunica a la organizacin que dispondr de un canal
especfico para ello. Cuando la organizacin conoce esta comunicacin reacciona segn reglas y
protocolos establecidos.
Un suceso comunicativo, una interaccin comunicativa requiere:
Que un agente contacte con el sistema para establecer una comunicacin. Es lo que
denominamos estmulo o disparo disparo disparo disparo del suceso.
Que el agente confeccione una descrip descrip descrip descripcin cin cin cin del fenmeno que ha observado o del que ha
tenido noticia y la transmita por el canal establecido.
Que el sistema reaccione reaccione reaccione reaccione como est establecido al conocer que ese fenmeno que le
interesaba ha ocurrido.
Requisitos en Sistemas de Informacin
25
2.3.4 El mbito de uso El mbito de uso El mbito de uso El mbito de uso
Suponga que usted acude al servicio de correos para poner un telegrama. Lo primero que tiene
que hacer es localizar dnde puede realizar esta gestin. Posiblemente deba usted adems
proveerse del formulario correspondiente.
Una vez haya localizado el entorno adecuado es posible que requiera usted ciertas informaciones
previas que podran afectar a la forma o al contenido de su mensaje. Por ejemplo la lista de
precios. Imagnese que los precios van por bloques de palabras. Usted intentar maximizar el uso
del bloque.
Comenzar un proceso editorial en el que usted participar como aportador de informacin
escribiendo el mensaje en el formulario previsto para ello.
El proceso editorial continuar con la colaboracin de alguna persona de correos que proceder a
un cambio de formato introduciendo el texto que usted le proporcion mediante un teclado en
algn artefacto especfico.
Esta persona realizar ciertas validaciones. Comprobar, por ejemplo, que la poblacin a la que
usted quiere enviar su mensaje existe o que el pas al que usted pretende enviarlo dispone de
servicio telegrfico.
Calcular el importe contando las palabras y aplicando la tarifa correspondiente. Registrar en
algn soporte los datos que la organizacin de correos considere necesarios. Probablemente
registre los datos del emisor, del receptor, el importe cobrado, la fecha y da de la operacin.
Por ltimo emitir un recibo y una copia del mensaje enviado que le sern entregados para
acreditar la operacin.
La serie de actividades descritas en este ejemplo son habituales en cualquier interaccin de un
sistema de informacin; independientemente de los tipos soportes.
Como vemos en el ejemplo anterior, la descripcin de sucesos tiene dos mbitos descriptivos: los
requisitos del dominio del problema y los requisitos del entorno de uso.
Cuando nos movemos en el mbito del problema la cuestin se centra en identificar las
interacciones, los mensajes asociados y la reaccin del sistema frente a esos mensajes.
Cuando trabajamos en el mbito de la solucin la cuestin se centra en ofrecer un soporte
eficiente a la comunicacin. Pero podemos observar que aparecen requisitos que en el domino del
problema, en el modelo del negocio, ni se plantean. Cmo encuentra un usuario de mi servicio la
ventanilla adecuada? Cuantos recursos son necesarios para cumplimentar un cuestionario? El
entorno de uso incorpora aspectos pragmticos que en el entorno del negocio resultan
accesorios.
Una de las principales caractersticas del entorno de uso es facilitar la edicin de los mensajes.
Hasta tal punto que una interfaz puede considerarse un mero editor de estructuras. De hecho es
lo que el usuario percibe. El usuario no desencadena sucesos sino ms bien procesos editoriales
que permiten construir mensajes que se comunican al sistema. La mayor parte del tiempo que un
usuario pasa ante una interfaz la dedica a la edicin. Por ello el concepto base de nuestra
aproximacin es el contexto editorial contexto editorial contexto editorial contexto editorial.
Un contexto editorial identifica un editor de estructuras para uno o ms sucesos de usuario.
Cuando un contexto editorial se utiliza para varios sucesos de usuario es porque existe
compatibilidad estructural entre ellos. El caso ms tpico de un contexto editorial es la agrupacin
de los sucesos de alta, consulta, modificacin y borrado para una clase.
De forma general consideraremos que los requisitos del entorno de uso tienen que ver con los
tres aspectos siguientes:
Soporte a la localizacin de objetos y sucesos: el usuario debe localizar la clase de
suceso que necesita invocar dependiendo del tipo de mensaje que quiere comunicar (hay un
nuevo cliente") o localizar instancias de objetos para luego aplicarle alguna funcin (localizar

al cliente Kaplan S.L."). En realidad el usuario localiza el contexto editorial que le permite
editar el mensaje y, una vez construido, comunicarlo al sistema.
Soporte a la edicin del mensaje: supone visualizar e introducir la informacin asociada a
la funcin seleccionada (suceso). En ocasiones este punto conlleva una edicin intensiva de
los datos y, por lo tanto, el usuario requiere de una bateria de funciones editoriales que le
ayuden en la tarea; en este proceso el sistema y el usuario se intercambian numerosos
mensajes.
Disparo de la funcin de negocio: el usuario indica que ha finalizado la edicin de los
datos para disparar la comunicacin efectiva del mensaje provocando la reaccin del sistema.
2.3.5 El mbito de la infraestructura tecnolgica El mbito de la infraestructura tecnolgica El mbito de la infraestructura tecnolgica El mbito de la infraestructura tecnolgica
Las aplicaciones requieren de un soporte sobre el que se despliegan e instalan que deben
garantizar parte de esa continuidad. Por soporte fsico entendemos el hardware, el software de
base (sistema operativo, sistemas de gestin de base de datos, servidores de aplicaciones, etc.) y
las relaciones entre todos ellos. La infraestructura tecnolgica tiene al menos dos aspectos. La
arquitectura lgica de componentes software, que supone la eleccin de un determinado
framework para el desarrollo y la arquitectura fsica en que se ubican estas componentes.
En el momento actual la arquitectura para infraestructura es objeto de amplio debate y existen
diferentes propuestas al respecto.
Quiz uno de los criterios a establecer es el diseo de acceso a los datos, el control de
redundancia y la optimizacin de base de datos.
Aqu la problemtica est guiada por dos aspectos:
Uno que afecta directamente a los usuarios. El rendimiento: la forma en que elegimos las
componentes fsicas y lgicas para que se adecuen a los requisitos de rendimiento.
Otro que afecta a los desarrolladores pero tambin, a la larga, a la economa de los
clientes. El diseo: la eleccin que hacemos de la arquitectura de componentes para
disponer de un sistema cohesivo y poco acoplado. Es decir fcilmente modificable o
mantenible.

Interacciones externas
27
3 33 3- -- - Interacciones externas Interacciones externas Interacciones externas Interacciones externas
3.1 LAS INTERACCIONES COMO BASE DEL ANLISIS
El objetivo esencial de una especificacin de requisitos es definir el conjunto de interacciones
externas que el sistema requiere. Para que el concepto de interaccin externa tenga calidad es
necesario separarlo de todos los aspectos internos. Pero adems es necesario saber cual es la
granularidad mnima o la unidad de las interacciones externas. Por ejemplo entrar nombre
debe considerarse una interaccin externa? Posiblemente no. Es externa pero carece de unidad
comunicativa si siempre va acompaado de la comunicacin del cif, los apellidos y la direccin.
El nombre no constituye una intencin comunicativa sin el recurso de los dems datos.
En los sistemas existe un nivel de fractura externo/interno que debe aclararse conceptualmente.
Las interacciones de un sistema requieren dos caractersticas:
La externalidad: la interaccin se establece entre el sistema y algn elemento del entorno.
No entre diferentes componentes del sistema.
La unidad: la interaccin tienen sentido en s misma y se considera completa. No se trata
de una parte de otra interaccin mayor.
3.2 LA EXTERNALIDAD
Un sistema es en s un encapsulamiento, una forma de poner cosas juntas o de agregar
fenmenos. Tambin lo son los subsistemas en que decidamos descomponerlo. Cada vez que
consideramos algo como un encapsulamiento es porque no queremos considerar su interior y
decidimos fijarnos en sus relaciones externas.

3.2.1 Refinamientos Refinamientos Refinamientos Refinamientos
Para tratar con sistemas complejos recurrimos a la descomposicin. Una de las formas ms
conocidas y utilizadas para descomponer sistemas es el mtodo de los refinamientos sucesivos.
Esto produce una jerarqua de descomposiciones.
N
i
v
e
l

d
e

A
b
s
t
r
a
c
c
i

n
N
i
v
e
l

d
e

D
e
t
a
l
l
e

Figura 8 Jerarquia de refinamientos
Cuando refinamos un sistema podemos utilizar criterios diversos. Orgnicos: las interacciones que
se dan en un determinado departamento. Funcionales: las interacciones que pueden ocurrir para
llevar a cabo una determinada gestin. Temporales: las interacciones que tienen lugar antes de
que se celebre un evento, las que pueden ocurrir durante su celebracin y las que pueden ocurrir
una vez finalizado. Objetuales: las interacciones que afectan a un tipo de objeto dado como un
pedido o una factura. Es posible, incluso, cambiar el criterio cada vez que procedemos a un
refinamiento.
La descomposicin de complejidad, el refinamiento de un sistema, define una jerarqua de
subsistemas donde cada uno de ellos tiene un criterio particular de encapsulamiento. Como
siempre los criterios de encapsulamiento de un subsistema responden a alguna intencin. Por
ejemplo, si agrupamos funciones organizacionales con un criterio orgnico nuestra intencin es
establecer una poltica de responsabilidades y competencias respecto a los recursos
organizacionales.
El nivel de los procesos de negocio determina el ltimo nivel de refinamiento posible para
interacciones externas de un sistema.
3.2.2 Confusin externa/interna Confusin externa/interna Confusin externa/interna Confusin externa/interna
Imagnese que acude a un restaurante y en el men aparecen lneas que se refieren a platos que
usted puede pedir y lneas que corresponden a componentes de algn plato.
Por ejemplo:
Arroz tres delicias
piones
Bistec al oporto
una cucharadita de jerez
Interacciones externas
29
Ensalada de brotes de soja
Zanahoria rallada y rodajas de remolacha
El men est mezclando interacciones -arroz tres delicias, bistec al oporto, ensalada de brotes de
soja- con componentes -jerez, zanahoria, piones. Al cliente le interesa saber cual puede ser su
eleccin. Al cocinero le interesa saber para cada eleccin cual es su composicin.
Esta confusin de intenciones es habitual en la mayora de tcnicas que usamos. La confusin de
interacciones y componentes slo puede conducir a dificultar la comprensin del sistema.
Si pensamos por ejemplo en sistemas informacin, el refinamiento de la diversidad nos lleva a la
definicin de todas las opciones requeridas por el sistema. Lo que podramos llamar el men de la
aplicacin.
En la figura inferior aparece una descripcin basada en la tcnica del anlisis estructurado
[DeMarco 1979]. Esta tcnica propicia la confusin de interacciones y componentes.

Figura 9 Confusin de interacciones y componentes.
La figura muestra un refinamiento de un proceso superior: gestin de actividades. El refinamiento
debera haber conducido a tres interacciones: alta de actividad, baja de actividad y listar
actividades. El diagrama mezcla relaciones externas y relaciones internas.
Imagnese que un libro de cocina tuviera una pgina que se denominar arroces de pescado. Y
que en esta pgina se describieran al mismo tiempo y de forma entremezclada tres recetas
diferentes de arroz. El sentido comn del lector debera saber cuando cada instruccin se refiere a
cada una de las tres recetas. Eso es exactamente lo que muestra el grfico anterior.
El caso del anlisis estructurado es especialmente singular. El diseo estructurado ha convertido
esta confusin conceptual en un cuerpo de recomendaciones heursticas que gozan de crdito en
muchos planes de estudio de informtica.
3.2.3 Refinamientos de interacciones externas e internas. Refinamientos de interacciones externas e internas. Refinamientos de interacciones externas e internas. Refinamientos de interacciones externas e internas.
Cuando un sistema es complejo utilizamos tcnicas para reducir la complejidad y tratar con
subconjuntos de interacciones menores y ms manejables. Esto es una descomposicin. Pero no
una descomposicin del sistema en sus elementos constituyentes sino una particin de "todas las
interacciones del sistema" en conjuntos menos complejos de interacciones.

El contrasentido proviene de la ambigedad del trmino descomposicin. Descomponer tiene, al
menos, dos acepciones.
La composicin constitutiva o agregada en la que un conjunto de componentes se organizan o
estructuran para dar lugar a una componente compleja. La composicin constitutiva requiere
coincidencia espacio-temporal.
La composicin varietal o electiva en la que se consideran todas las posibles variedades de
interacciones que puede admitir un sistema. Las variedades que pueden darse en un sistema no
requieren la coincidencia en el espacio y en el tiempo.
La composicin varietal tiene que ver con la eleccin, con la abstraccin de generalizacin-
especializacin. La composicin constitutiva tiene que ver con la constitucin con la abstraccin
de agregacin/descomposicin.
Por ejemplo, formular un pedido y dar de alta una maquina en un taller son dos componentes
posibles de un sistema. Pero no se requieren mutuamente. No necesitan coexistir en un momento
y lugar. Puede darse una interaccin sin que se de la otra. Dar de alta una mquina en un taller lo
consideramos un fenmeno completo. Puede ocurrir sin el recurso de otros fenmenos.
Un pedido se compone del cliente que lo formula y de los productos que solicita. Esta
composicin es estricta. No podemos prescindir de ninguno de los elementos sin que pierda
sentido el todo. Las componentes cliente que formula el pedido y productos solicitados en el
pedido no son independientes y deben coexistir en el espacio y en el tiempo. El pedido est
constituido por todos esos elementos o componentes. Si alguno no est presente el pedido no
puede considerarse un fenmeno completo.
Cuando describimos la composicin de un coche suponemos que todas las componentes estn
presentes en el mismo instante y lugar para que el sistema coche mantenga su significado pleno.
Un coche sin motor, sin ruedas o sin puertas est incompleto. El cliente de un concesionario de
automviles difcilmente aceptar que le entreguen un coche incompleto.
Cuando vamos a un concesionario de automviles y nos entregan un catlogo no pensamos que
el catlogo sea una composicin. Ms bien lo vemos como una oferta de posibles elecciones. Son
las variantes de interaccin. Nuestra interaccin de compra supondr elegir uno de los modelos
que oferta el catlogo. Es posible que nos entreguen un catlogo viejo, que no contenga el ltimo
modelo o que no est totalmente actualizado. Sin embargo seguiremos considerndolo un
catlogo. El hecho de que no est actualizado slo ser un ligero inconveniente. Sobre todo si no
afecta a la serie de modelos que nos interesa. As como todos los clientes rechazaran un coche
sin puertas la inmensa mayora aceptara un catlogo desactualizado. Puesto que se trata de un
procedimiento de eleccin la ausencia de partes no invalida el proceso. Slo bajo requisitos
estrictos de optimizacin sera problemtica la ausencia de partes.
3.3 LA UNIDAD
3.3.1 Comunicaciones Comunicaciones Comunicaciones Comunicaciones
A finales del siglo XIX un lingista llamado Charles Sanders Peirce sugiere que las palabras que
intercambiamos tienen un significado que no est en ellas mismas sino que depende de la
relacin entre las entidades que se comunican. Las ideas de Peirce constituyen el origen de la
semitica [Peirce 1894]. Peirce establece tres grados de percepcin sobre las palabras, sobre los
signos. Las palabras nos interesan en una forma primaria por s mismas, tiene adems un inters
secundario porque actan como indicadores de otras cosas y tiene un tercer grado de inters en
la medida en que se relacionan con nuestras ideas. Peirce denomina esta tercera forma de percibir
Interacciones externas
31
mediacin. El significado de las palabras depende de la relacin que tienen con nuestras ideas,
con nuestro conocimiento.
En 1948 Claude Shanon propone el modelo de Sistema de Comunicacin [Shanon 1948].

Figura 10 Nodelo de sistema general de comunicacin de Shanon
Un sistema de comunicacin, segn el modelo de Shanon, tiene cinco partes esenciales: la fuente,
el transmisor/codificador, el canal, el decodificador/receptor y el destinatario. La visin de Shanon
que trabaja como ingeniero en una compaa telefnica, se preocupa solo de la transmisin de
mensajes y no de su significado. Pero su modelo est en la base de los modelos que actualmente
utilizamos. Toda comunicacin requiere un emisor (la fuente), un receptor (el destinatario) y un
medio (el canal). Es necesario que el emisor codifique el mensaje que quiere comunicar usando
algn sistema de codificacin, un lenguaje, compartido entre el emisor y el receptor. Los mensajes
adoptan por tanto una forma codificada convencional que se transmite por un canal.
CANAL
Receptor
Emisor
Nensaje
cdigo

Figura 11 La comunicacin se soporta en un medio o canal
En 1960 otro lingista, Roman Jackobson, propone un modelo comunicativo que asume las ideas
anteriores. Seala la importancia del contexto social como base del significado. Proponiendo un
modelo basado en la existencia de un contexto compartido entre los participantes en la
comunicacin. El significado del mensaje no est en el propio mensaje sino que depende de
convenciones sociales.
El concepto de contexto social se conoce hoy da como conocimiento compartido (shared
knowledge). El significado del mensaje depende del conocimiento compartido entre emisor y
receptor. Solo en la medida en que emisor y receptor compartan las percepciones e ideas que
tiene sobre los fenmenos es posible alcanzar un significado compartido.

Figura 12 El contexto como conocimiento compartido


Por eso para Langefors el SI se limita a adquirir, almacenar o diseminar expresiones lingsticas. El
SI solo es el soporte de la comunicacin. El significado de esas expresiones lingsticas variar en
funcin del conocimiento de quien las interprete.

Jackobson propone adems seis intenciones para caracterizar las funciones del mensaje.
!ntencin Funcin Ejemplo
Descriptiva Describir, informar. Contenido del
mensaje.
Esta lloviendo
Emotiva

Expresar sentimientos o actitudes del
emisor.
INaldita sea! Esta lloviendo
otra vez
!nfluencia !nfluir en el comportamiento del receptor.
Significado del mensaje
Espera que pare de llover.
Contacto Establecer o mantener relaciones
sociales. Asegurar que el canal a travs
del que se establece la comunicacin esta
funcionando.
cNo le parece que esta lluvia
es muy beneficiosa?
Netalingistica Referir la naturaleza o aspectos del
propio mensaje. Describir el contenido o
el cdigo del mensaje.
Este es el informe del tiempo.
Esttica Resaltar las caracteristicas textuales del
mensaje. Reutilizacin de cdigo
lingistico para establecer metaforas.
Los cielos derramaron
lagrimas.
3.3.2 Sucesos Sucesos Sucesos Sucesos
El concepto de suceso comienza a utilizarse en el rea de Sistemas de Informacin a partir de la
publicacin del mtodo Merise auspiciado por el Ministerio de Industria francs. Su Modelo
Conceptual de Tratamientos es la primera tcnica orientada a suceso conocida en el rea de
Sistemas de Informacin.
Merise utiliza el trmino vnement para denotar un disparo o una condicin de disparo de un
tratamiento.
Los eventos en Merise son condiciones persistentes o instantneas. Siempre tiene que existir al
menos una condicin instantnea que acte como estmulo disparador del tratamiento.
El informe ISO/TC97/SC5/WG3 [Van Griethuysen 1982] estableci la base terminolgica para
sistemas de informacin que la comunidad cientfica adoptara en la dcada de los 80. El informe
define un evento como:
The fact that something has happened in either the universe of discourse, or the
environment, or the information system.
En la revisin que Edward Yourdon hace del anlisis estructurado, el Anlisis Estructurado
Moderno, introduce el trmino evento (llamado acontecimiento en la traduccin al espaol
[Yourdon 1989]).
Un acontecimiento es un estmulo que ocurre en el mundo exterior al cual el sistema
debe responder
En 1990 se publica la primera versin del informe Frisco [Frisco 1990] que supondra la revisin
terminolgica ms rigurosa conocida en el rea.
Para Frisco un evento es
An abstraction of a change of state in the organizational domain.
Interacciones externas
33
En sistemas de tiempo real o en sistemas empotrados viene utilizndose desde hace tiempo en un
sentido ms general. En los sistemas de control no se trata slo de estmulos externos al sistema
sino tambin de los internos.
En los entornos de programacin el trmino evento designa cualquier estmulo o interrupcin
posible en la actividad de las componentes. Como el clic del ratn o el fin de la lectura de los
registros de una tabla.
En la orientacin a objeto, donde prima la arquitectura de componentes, la visin del evento es
tambin generalizada.
Un estmulo individual proveniente de un objeto y que llega a otro es un suceso
[Rumbaugh 1991].
En el contexto de las mquinas de estados, un evento es la aparicin de un estmulo
que puede disparar una transicin de estado [Booch1999].
3.3.3 Sucesos comunicativos Sucesos comunicativos Sucesos comunicativos Sucesos comunicativos
El trmino evento est siempre vinculado a la comunicacin. Ya sea comunicacin entre
componentes, entre objetos o entre el entorno y el sistema de informacin. Las diferentes
definiciones de evento denotan una o ms de las funciones comunicativas de Jackobson.
En todas las definiciones aparece una funcin fctica, el contacto o establecimiento de la
comunicacin. El evento es el responsable del inicio de la comunicacin. Es un desencadenante,
un estmulo, un disparo, la causa de que se inicie un determinado comportamiento en una
componente.
Tambin aparece una funcin conativa que se asocia a la influencia del mensaje en el
comportamiento del receptor. Refiere por tanto la respuesta del sistema ante el evento: "puede
disparar una transicin de estado, el sistema debe responder.
Sin embargo la funcin denotativa, la esencia comunicativa, aparece soslayada. La definicin del
informe ISO es la que contiene mayor carga denotativa.
El aspecto descriptivo asociado al evento es al que menos importancia se le da. En prcticamente
todas las definiciones tienen mayor preponderancia los aspectos fcticos, el disparo, y conativos,
la reaccin.
La mayora de tcnicas descriptivas actuales describen los mensajes por la forma en que el sistema
reacciona ante ellos pero no por los mensajes en s mismos.
La tcnica de especificacin de requisitos de usuario por excelencia, los casos de uso, caracteriza
la reaccin del sistema describiendo las acciones minimizando el carcter denotativo de las
interacciones.
Utilizaremos la denominacin suceso comunicativo para enfatizar la esencia descriptiva de las
interacciones en los Sistemas de Informacin.
Esta denominacin recoge la idea de que
algn fenmeno de inters para un sistema de informacin ha ocurrido,
existe una descripcin conveniente de ese fenmeno
algn agente externo conocido est dispuesto a comunicarlo a travs de un canal
preestablecido en el sistema de informacin
el sistema tiene prevista una respuesta para el tipo de fenmeno informado.

3.3.4 Criterios de unidad Criterios de unidad Criterios de unidad Criterios de unidad
En las diferentes definiciones de suceso podemos observar que las caracterizaciones ms precisas,
las que permiten prescripciones metodolgicas, son las que recurren a la delimitacin del suceso a
partir de la respuesta que desencadena en el sistema.
No es por tanto de extraar que los criterios de unidad del suceso se basen en los criterios de
unidad de la respuesta asociada.
Cada suceso define una respuesta. En la prctica suceso y respuesta pueden considerarse una
misma cosa. Si existe una relacin biunvoca entre sucesos y respuestas es lo mismo hablar de las
relaciones entre sucesos que de relaciones entre respuestas.
La unidad, la granularidad de los sucesos podemos tambin encontrarla en las respuestas
asociadas.
La definicin que ofrece Merise de la respuesta reactiva se recoge en el concepto de operacin:
Una operacin es un conjunto de tratamientos que pueden ser ejecutados de manera
continua, es decir, que tienen una misma unidad de accin y no necesitan que ocurran
otras operaciones [Collongues 1989].
Esta definicin de operacin contiene tres criterios:
El designado por de manera continua responde al concepto de sincronismo. Las acciones
invocadas se realizan de forma continua por lo tanto deben ser capaces de comunicarse
sncronamente entre ellas. Las acciones que no puedan ocurrir sncronamente no podrn
formar parte de una misma operacin. Es la interrupcin de la actividad la que marca el fin de
la reaccin.
El designado por una misma unidad de accin introduce el criterio de un objetivo funcional
nico. Es equivalente al concepto de unidad de la cohesin funcional del diseo estructurado.
[Stevens 1974]
El designado por no necesita que ocurran otras operaciones establece un criterio de
impenetrabilidad modular. Una operacin no se compone de operaciones. No admite
refinamientos.
El criterio de continuidad o de sincronismo conduce a una visin fsica del suceso. Las limitaciones
fsicas de los entornos de procesamiento pueden forzar la terminacin de la reaccin. El criterio de
sincronismo est condicionado a una determinada eleccin de los agentes de soporte de las
funciones del sistema.
La definicin siguiente destaca el carcter fsico del criterio de sincronismo.
Un suceso es un conjunto de actividades (de adquisicin, almacenamiento,
procesamiento, recuperacin o distribucin) de informacin que se realizan de forma
completa e ininterrumpida, con ocasin de un estmulo externo [Gonzlez 2002]
Cuando definimos la unidad basndonos en el sincronismo estamos definiendo sucesos que
reflejan actividades bsicas del sistema de informacin. Como por ejemplo el envo de
informacin, el almacenamiento, la validacin, o los cambios de formato.
Si utilizamos criterios meramente comunicativos la unidad de la reaccin est asociada a la unidad
del mensaje comunicado.
Un suceso comunicativo est constituido por uno o ms sucesos fsicos que tienen un mismo
objetivo comunicativo. Los sucesos comunicativos se asocian a los mensajes de entrada y de
salida del sistema de informacin.
Un suceso comunicativo comprende tres actividades bsicas: El estmulo, la edicin del mensaje y
la reaccin. Cuando se trata de mensajes de entrada los procedimientos editoriales pueden ser
largos y resolverse mediante diferentes sucesos fsicos.
Interacciones externas
35
Los sucesos comunicativos son importantes respecto a los sucesos fsicos porque se centran en las
intenciones comunicativas del sistema y no en las limitaciones de la solucin existente.
3.3.5 Criterios de unidad en los sucesos comunicativos Criterios de unidad en los sucesos comunicativos Criterios de unidad en los sucesos comunicativos Criterios de unidad en los sucesos comunicativos
Hemos denominado sucesos constructores a las interacciones comunicativas de entrada.
Inicialmente describiremos estas interacciones por los tres aspectos comunicativos bsicos:
contacto, mensaje y significado es decir quin dispara, qu nueva informacin comunica y cmo
reacciona el sistema frente a ello.
Delimitar adecuadamente el mbito de las interacciones es de gran importancia para el
establecimiento de los requisitos. En sistemas de informacin para la gestin las interacciones
entre el sistema y el entorno son comunicaciones que se establecen intercambiando mensajes.
Mensajes de entrada y mensajes de salida.
En las comunicaciones que se establecen entre el entorno y el sistema de informacin aparecen,
de forma esencial, tres de las funciones comunicativas establecidas por el lingista ruso Roman
Jakobson.
La funcin de contacto contacto contacto contacto porque la comunicacin de todo mensaje requiere el
establecimiento previo de una conexin, una toma de contacto.
La funcin descriptiva descriptiva descriptiva descriptiva porque el objetivo de las comunicaciones en los sistemas de
informacin es describir fenmenos que ocurren en el sistema objeto.
La funcin de influencia influencia influencia influencia porque la organizacin disea sus comunicaciones para poder
reaccionar, segn sus propsitos, ante los fenmenos que ocurren.
Cada interaccin comunicativa es un requisito para el sistema que habr que desarrollar. Pero es
un requisito genrico que debe ser refinado a travs de una estructura dictada por esas tres
funciones: contacto, descripcin e influencia.
Esos tres aspectos estn vinculados a la idea de evento o suceso habitual en el modelado
conceptual.
Un suceso comunicativo es una interaccin de comunicacin entre el entorno y el sistema de
informacin. El suceso comunicativo tiene lugar porque algo ha ocurrido en el sistema objeto de
inters que la organizacin observa. Algn agente del entorno organizacional ha tenido
conocimiento del fenmeno ocurrido y lo comunica a la organizacin que dispondr de un canal
especfico para ello. Cuando la organizacin conoce esta comunicacin reacciona segn reglas y
protocolos establecidos.
Un suceso comunicativo, una interaccin comunicativa requiere:
Que un agente contacte con el sistema para establecer una comunicacin. Es lo que
denominamos estmulo o disparo disparo disparo disparo del suceso.
Que el agente confeccione una descripcin descripcin descripcin descripcin del fenmeno que ha observado o del que ha
tenido noticia y la transmita por el canal establecido.
Que el sistema reaccione reaccione reaccione reaccione como est establecido al conocer que ese fenmeno que le
interesaba ha ocurrido.

Estos tres aspectos de la comunicacin ayudan a considerar los criterios de unidad de un suceso.
1. Unidad de estmulo. Cada comunicacin que se establece con el sistema de informacin est
provocada por la ocurrencia de un nico fenmeno. El estmulo o el establecimiento de
contacto ser responsabilidad de un nico agente. Es posible que la comunicacin sea el
resultado de la deliberacin o la cooperacin de un grupo. Pero en este caso el grupo suele
nombrar un responsable o portavoz que se responsabiliza de la comunicacin.

Las formas coordinadas o sincronizadas de disparo son poco frecuentes. Pueden aparecer en
protocolos de alta seguridad como las dobles llaves para el disparo de artefactos nucleares
para el mantenimiento de la paz por naciones bien intencionadas.
2. Unidad de descripcin. Un suceso describe un fenmeno que ha ocurrido en el entorno. El
mensaje comunicado tiene una unidad que no se puede fragmentar porque no describira de
forma completa el fenmeno. La unidad del mensaje no la determina la forma en que lo
tratamos sino el fenmeno que describimos. Cuando vamos a un club a darnos de alta no
tienen lugar varias comunicaciones del tipo leer y validar_dni, anotar y comprobar
telfono, etc. Hay un nico mensaje que describe toda la informacin necesaria para poder
darnos de alta en ese club.
3. Unidad de reaccin. La llegada de un mensaje a la organizacin desencadena un conjunto de
actividades que se realizan de forma completa e ininterrumpida. Las actividades que
desencadena un suceso son sncronas. Tienen lugar en el mismo tiempo y entorno
comunicativo.
Imagin la siguiente descripcin:
La administracin autonmica ha organizado un procedimiento para recoger solicitudes
para ayudas por daos causados por un incendio que ha asolado grandes extensiones
de cultivo de almendros y frutales. Cada propietario cumplimenta una instancia con sus
datos, los datos de las parcelas afectadas y el nmero de rboles daados en cada
parcela. Esta instancia la entrega en el ayuntamiento de su localidad dentro de los
plazos establecidos. Finalizado el plazo cada ayuntamiento remite a la Conselleria las
instancias recibidas. La Conselleria entrega las instancias a una empresa para que
digitalice los datos. La empresa devuelve los datos y las instancias al departamento de
explotacin de la Conselleria que revisa los datos digitalizados y corrige los posibles
errores existentes. Posteriormente se incorporan las solicitudes a la base de datos.

Figura 13 Sucesos fisicos
Interacciones externas
37
Podemos describir directamente los sucesos comunicativos que relata el caso. Seran los sucesos
fsicos que manipulan y transportan la informacin almacenndola, temporalmente, hasta que
llega a su destino final. Se trata de los sucesos comunicativos desde el punto de vista del modelo
de Shanon o del modelo de los agentes soporte. EL modelo fsico.
Pero en la descripcin anterior existe un nico hecho comunicativo. Poner en conocimiento del
sistema los daos reclamados por un propietario. Este suceso comunicativo aparece como un
conjunto de sucesos fsicos tal como se describe en la Figura 13 .
Es posible considerarlo un nico suceso lgico tal como aparece en la Figura 14 EL analista debe
ser consciente de que una organizacin eficiente de los soportes comunicativos debe aproximarse
al modelo lgico.

Presentar Informe de
Daos
Propietario


Figura 1+ Suceso lgico
El mensaje existe desde el momento en que el propietario cumplimenta la instancia. El resto de
sucesos fsicos existen porque los soportes de adquisicin son rudimentarios. Un formulario en
Internet podra eliminarlos todos. A partir del primer suceso conocemos una informacin que
ninguno de los sucesos posteriores debera alterar. Ninguno de esos sucesos aade valor
comunicativo.

La unidad reactiva, la que conduce a los modelos fsicos, est limitada por criterios de unidad
basados en la organizacin de los soportes comunicativos. No deberan formar parte de un mismo
suceso fsico
1. Las actividades que ocurren en intervalos de tiempo diferentes y no conexos. Salvo que
sincronicemos los estmulos.
Si la actividad A ocurre a las 10 de la maana y la actividad B ocurre a las 5 de la tarde A
y B no se pueden sincronizar salvo que se modifiquen y se hagan coincidir sus estmulos.
Todas las maanas se enva un listado de precios de compra medios del da anterior a
los proveedores y al final del da se enva el resumen de ventas de cada proveedor
Si la actividad A debe ocurrir para que otra B pueda ocurrir y no suceden siempre al
mismo tiempo no pueden formar parte de un mismo suceso. El comit asigna el
proyecto a la empresa que presenta el historial ms competente y la empresa entrega
una redaccin preliminar del proyecto.
Siempre que podamos ordenar dos actividades en el tiempo y entre sus ocurrencias exista
un intervalo de tiempo se trata de dos sucesos diferentes. Las semillas se plantan en
marzo en semilleros. A las tres semanas se replantan en macetas.
2. Las cosas que ocurren en entornos comunicativos aislados. Salvo que unifiquemos los
entornos.
Sobre un hecho comunicativo pueden establecerse competencias de validez y autoridad.
Debemos diferenciar tres posibilidades.
En el nivel ms bajo el problema es meramente de soporte al canal de comunicacin y a
la codificacin. Se penaliza el proceso de adquisicin. Existen muchos costes en la
codificacin del mensaje, se utilizan varios procesos de codificacin o el canal de
comunicacin es rudimentario. Es el caso del ejemplo anterior sobre el sistema de ayudas.

En un nivel intermedio el problema es de asignacin de competencias.
Supongamos que en una empresa se toman pedidos en el departamento de atencin al
cliente. Los pedidos pasan luego a almacn que los clasifica segn hayan o no existencias.
Si hay existencias el pedido se considera vlido y puede pasar a fabricacin.
Los sucesos tomar pedido y validar pedido ocurren en entornos diferentes y en tiempos
diferentes. Pero es posible que se puedan unificar. Todo depende si la clasificacin del
pedido requiere o no de alguna interaccin externa. Si el criterio de validez del pedido
depende solo de la informacin que el sistema dispone, las existencias conocidas, los
sucesos son unificables. Si se mantienen separados es por una decisin de poltica
organizacional.
En el nivel ms alto la cuestin es de valor comunicativo aportado.
Existen sucesos que tienen una contribucin comunicativa mnima. Su propio nombre es
el mayor valor comunicativo, aunque siempre identifican un objeto y un instante. Por
ejemplo aprobar un proyecto, resolver una concesin, autorizar un gasto. Se trata
de sucesos donde interviene la autoridad o la competencia de un actor organizacional.
Las organizaciones establecen protocolos de autorizacin en sus procedimientos.
Determinadas decisiones deben ser refrendadas por personas con los niveles de
responsabilidad adecuados. Estos actos aaden valor a la comunicacin. Cuando
hacemos un presupuesto para un cliente el cliente lo acepta o no. La decisin del cliente
no parece aportar nada nuevo al presupuesto. Sin embargo el inicio de obras no debera
ocurrir sin que haya ocurrido un suceso de aceptacin. El presupuesto aceptado tiene un
valor comunicativo diferente al del presupuesto sin ms.
A diferencia del aparatado anterior aqu la decisin es externa y no previsible por el
sistema. No podemos considerar que elaborar un presupuesto y aceptar un presupuesto
sean realizaciones de sucesos fsicos sobre un mismo hecho comunicativo.
Interacciones externas
39
3.3.6 Estructuras de comunicacin Estructuras de comunicacin Estructuras de comunicacin Estructuras de comunicacin
En el anlisis de sistemas de gestin es muy importante caracterizar la estructura de informacin
que aporta o produce cada suceso. Para ello usaremos las Estructuras de Comunicacin. Se trata
de una notacin regular similar a la propuesta por el Anlisis Estructurado para describir los flujos
de informacin. Los constructores de que se disponen son los siguientes:
< + > Secuencia o composicin
[ | ] Alternativa o especializacin
{ } Iteracin
Supngase un suceso de confeccin de un pedido en una tienda de ordenadores; el comercial
rellena el formulario de la Figura 17 a partir de la informacin que le proporciona el cliente; con
el fin de que el cliente se pueda llevar una copia impresa que le sirva como presupuesto, se
simulan los clculos de importes que se haran en una factura. Al lado se presenta la estructura de
datos correspondiente.

PRESUPUESTO=
< num.pedido+
fecha pedido+
forma pago+
CL!ENTE=
< cod.cliente+
nif+
nombre+
direccin+
cod.postal+
provincia+
email
>+
L!NEAS=
{< cod.producto+
descripcin+
cantidad+
precio+
descuento+
importe
>)+
base imponible+
importe iva+
total factura+
total pesetas
>

Figura 15 Ejemplo de formulario de presupuesto
Al esqueleto estructural de la informacin aportada en el suceso de confeccin del presupuesto
podemos aadirle ms contenido; dependiendo de la fase del proyecto en que nos encontremos,
los elementos de la estructura de comunicacin podrn tener asociada diversa informacin.
3.3.7 Un ejemplo trivial Un ejemplo trivial Un ejemplo trivial Un ejemplo trivial
Supongamos una descripcin trivializada de las interacciones que recibe el sistema de informacin
de una biblioteca. Es el tpico ejemplo que jams ocurre de esta forma en el mundo real pero que
constituye una simplificacin adecuada para presentar conceptos de forma bsica.
El diagrama de la figura siguiente describe el comportamiento mediante cuatro interacciones.
Existen interacciones iniciales. Mensajes que ocurren sin necesidad de que previamente haya
ocurrido algo. Los mensajes asociados al deseo de una persona de inscribirse como socio y al
hecho de que ha llegado un nuevo libro. Para que una persona se asocie a esta biblioteca no es
necesario que nadie comunique nada previamente. Ni siquiera es necesario que se hayan
registrado libros. Pero para que alguien pida un libro prestado si que son necesarias dos cosas.
Que previamente se haya asociado y que el libro que pide haya sido previamente registrado.

El siguiente tipo de interaccin comunicativa que puede tener lugar es la devolucin de un libro.
Para ello es necesario que previamente alguien se lo hubiera llevado prestado. Ntese que
tambin es necesario que la persona que devuelve el libro sea socio y que el libro se haya
registrado. Pero nos basta con expresar la condicin de ocurrencia del prstamo porque si ha
ocurrido el prstamo seguro que han ocurrido los sucesos anteriores. Nunca reflejamos las
relaciones transitivas.


Figura 16 Secuencia temporal de mensajes de entrada
Pero adems estas interacciones estn asociadas a mensajes. De hecho tenemos los siguientes
tipos de mensaje:
1- Una persona se hace socio
a. Contacto: La persona que se quiere asociar
b. Comunicacin: Los datos de la persona.
Persona=
< Dni+
Nombre+
Direccin+
Poblacin+
CP+
Telfono+
Equipo+
Experiencia
> Persona

c. Reaccin: se registra la persona en el sistema informtico. Se genera un nmero
de socio. Se le da un carn de socio.
2- Administracin registra un nuevo libro
a. Contacto: Llega un paquete de libros de la distribuidora.
b. Comunicacin: los datos del libro.
Libro=
< Referencia+
Ttulo+
Autor+
Editorial+
Ao de Edicin+
Pginas+
Interacciones externas
41
Encuadernacin+
ISBN
> Libro

c. Reaccin: abrir una ficha de libro, catalogarlo, colocarlo en la estantera
correspondiente
3- Un socio solicita un libro
a. Contacto: El socio que solicita el prstamo
b. Comunicacin: identificacin del socio , identificacin del libro, fecha y hora
Prstamo=
< SOCIO(id)+
fecha de prstamo
{ LIBRO(id) }
> Prstamo


c. Reaccin: verificar los prstamos pendientes del socio, verificar que los libros
estn disponibles, buscarlos entregarlos al socio, registrar los datos del prstamo
en el sistema.
4- Un socio devuelve un libro
a. Contacto: el socio que devuelve el libro
b. Comunicacin: fecha de devolucin e identificacin de los libros que devuelve
Devolucin=
< fecha de devolucin +
{ LIBRO(id) }
> Devolucin

c. Reaccin: recoger los libros, guardarlos en la estantera correspondiente y
registrar los datos de la devolucin.

Fjese que hemos utilizado las maysculas y la forma OBJETO (id) para indicar que, de alguna
manera, identificamos elementos que ya son conocidos por el sistema. Se trata de referencias al
contexto, a instancias que pertenecen al conocimiento compartido que almacena el sistema de
informacin.
Note que no es necesario decir ms. No aportamos el nombre del socio cuando se hace un
prstamo. Solo comunicamos que un socio, en una cierta fecha se lleva determinado libros. Es
todo lo que el sistema necesita saber para poder actuar.
Otra cosa diferente es cmo identificamos al socio. La solucin que adoptemos nos puede
proporcionar varias formas distintas para identificar a un socio que ha olvidado su nmero de
socio. La esencia de la comunicacin es el mensaje aportado. Los mecanismos de ayuda
editorial para la construccin de ese mensaje forman parte del entorno de uso.

3.3.8 Completando la visin comunicativa Completando la visin comunicativa Completando la visin comunicativa Completando la visin comunicativa
Pero nos interesa otra visin en la que el valor comunicativo adquiere todava mucha ms
importancia.
Un Sistema de Informacin interacciona con su entorno mediante mensajes de entrada y
mensajes de salida.
Los mensajes de entrada suponen la comunicacin de nueva informacin que el sistema
desconoca hasta ese momento. Pero cuando analizamos e identificamos un mensaje de entrada
tambin debemos interesarnos en quin est interesado en la nueva informacin aportada.
De esta forma aparecen diferentes mensajes de salida vinculadas a la entrada.
.1 .1 .1 .1 Mensajes de salidas previos a una comunicacin de entrada. Mensajes de salidas previos a una comunicacin de entrada. Mensajes de salidas previos a una comunicacin de entrada. Mensajes de salidas previos a una comunicacin de entrada.
Cuando el mensaje que tiene que comunicar un actor est asociado a una decisin puede ser
necesario disponer de salidas previas que le ayuden a la toma de esa decisin. Por ejemplo, una
asignacin de personal a un proyecto puede requerir un listado de la ocupacin del personal. La
asignacin de pedidos a lneas de fabricacin requiere un listado de la carga existente en las lneas
y un listado de la demanda de pedidos organizada por tipo de producto.
.2 .2 .2 .2 Consultores acreditativos de constructor Consultores acreditativos de constructor Consultores acreditativos de constructor Consultores acreditativos de constructor
El suceso requiere una salida o comunicacin a agentes externos. Se trata de un consultor que
certifica la transaccin realizada, normalmente ser una copia de los datos capturados. Es lo
que antiguamente se denominaba impresin hardcopy. Puede ser la expedicin de un recibo, la
copia de un pedido
.3 .3 .3 .3 Consultores informativos de un constructor Consultores informativos de un constructor Consultores informativos de un constructor Consultores informativos de un constructor
Los consultores informativos suponen la comunicacin a agentes organizacionales del contenido
del mensaje comunicado por un suceso.
Deber establecerse para quin es importante conocer la nueva informacin o quin tendr que
reaccionar frente a esa informacin. En definitiva a quin es necesario y a quin conviene
informar. Las preguntas bsicas se formulan en este sentido.
Qu personas es necesario que conozcan esta informacin de forma inmediata?
Quin est interesado en conocer el contenido de este suceso?

Interacciones externas
43

Figura 17 Consultores vinculados a un constructor.
Los consultores informativos pueden tener dos objetivos diferentes. Provocar que el actor que los
recibe inicie otro suceso o informar del estado de los asuntos sin responsabilidad inmediata para
la ejecucin de sucesos.


La organizacin de las interacciones
45
4 44 4- -- - La organizacin de las interacciones La organizacin de las interacciones La organizacin de las interacciones La organizacin de las interacciones
4.1 TCNICAS DESCRIPTIVAS
4.1.1 Introduccin Introduccin Introduccin Introduccin
Las publicaciones en el rea de sistemas de informacin presentan la nocin de comportamiento
como un aspecto dinmico-temporal.
En UML el concepto de comportamiento se asocia a mtodos, interacciones, colaboraciones e
historias de estado:
Behavioral models (also known as dynamic models) emphasize the behavior of objects
in a system, including their methods, interactions, collaborations, and state histories.
UML permite descripciones de comportamiento mediante cuatro elementos lingsticos
diferentes.
The Collaborations package specifies a behavioral context for using model elements to
accomplish a particular task. The Use Case package specifies behavior using actors and
use cases. The State Machines package defines behavior using finite-state transition
systems. The Activity Graphs package defines a special case of a state machine that is
used to model processes. The Actions package defines behavior using detailed model
of computation.
El concepto de comportamiento est relacionado con diferentes tcnicas expresivas. En la mayora
de los casos se asocia a aspectos temporales. Pero existen aspectos de comportamiento donde lo
temporal no es tan obvio.

El comportamiento externo define relaciones entre interacciones externas. Normalmente se
utilizan rdenes parciales para reflejar secuenciacin temporal.
Los rdenes parciales de actividades organizacionales no son nuevos en el anlisis de sistemas de
informacin. El Modelo Conceptual de Tratamientos de Merise constituye la primera aproximacin
rigurosa al uso de ordenaciones temporales de sucesos.
La OMG ha propuesto una notacin para modelado de procesos de negocio. Se trata del Business
Process Modelling Notation o BPMN.
En general cualquier propuesta de modelado dinmico que se base en el uso de Redes de Petri
puede ser utilizada para expresar rdenes parciales entre sucesos. La tcnica de DFD permite un
uso muy similar al modelo conceptual de tratamientos de Merise a los diagramas de workflow o
a los diagramas de procesos de negocio. Los diagramas de actividad de UML admiten este mismo
uso.

Figura 18 Organizaciones de componentes dinamicas
Es importante diferenciar entre comportamiento interno y externo. En el comportamiento externo
relacionamos interacciones externas. En el comportamiento interno relacionamos componentes
internas. Se trata de la misma diferencia establecida en el captulo anterior entre composicin
constitutiva o agregada y composicin varietal o electiva.
Pero adems las interacciones externas pueden organizarse de dos formas.
Una es lo que se define de forma amplia como comportamiento. La ordenacin en el tiempo de
las interacciones externas.
Otra propone organizaciones de interacciones segn criterios espaciales y no temporales. Esta
forma de organizar se introduce en el apartado II.5 Diagramas de composicin de interacciones.
Los diagramas de Casos de Uso, por ejemplo, constituyen una forma espacial de organizacin. No
buscan organizar en el tiempo las componentes externas.
La especificacin de los casos de uso puede ser realizada mediante organizaciones temporales.
Por ejemplo un diagrama de secuencia o una secuencia de acciones segn la plantilla propuesta
por Dereck Coleman.
Las organizaciones de componentes dinmicas se sitan en un rea del cuadrante de la Figura 18
.
Pero adems estas organizaciones de componentes agrupan las componentes de los diagramas
segn diferentes criterios. Es decir, una cosa es qu tipo de relaciones entre componentes
La organizacin de las interacciones
47
estamos estableciendo y otra diferente con qu criterio decido las que entran a formar parte de
un determinado diagrama.
Los criterios a este nivel, se trata de subsistemas, son esencialmente dos. La orientacin a objeto y
la cohesin por objetivos de negocio.
4.1.2 Orientadas a objeto Orientadas a objeto Orientadas a objeto Orientadas a objeto
Las ordenaciones de sucesos localizadas por identificador u orientadas a objeto se utilizan en
el anlisis de sistemas de informacin desde las tcnicas estructuradas.
Basadas en diagramas de transicin de estado:
La informacin representada debe contener:
La identificacin de la clase de objetos afectada
Los estados posibles
Las transiciones de estado asociadas a cada suceso.

Figura 19 Diagrama de transicin de estados
Basadas en expresiones regulares: Las Entity Life History (ELH) de Jackson [Jakcson 1983].
Tambin recogidas en METRICA II como historia vital de entidad. Constituye otra
estructuracin orientada a objeto de sucesos. La forma de describirlas se basa en los
constructores de expresiones regulares: secuencia, iteracin, alternativa.
Cada ELH representa una entidad del sistema. Jackson propone estructurar los sucesos
que afectan a la entidad. En la parte izquierda aparecer el suceso generativo, en el
centro las incidencias que puede sufrir la entidad y por ltimo el suceso destructivo que
supone la muerte de la entidad.


Figura 20 Historia vital de entidades de JSD
4.1.3 Orientadas a objetos de negocio Orientadas a objetos de negocio Orientadas a objetos de negocio Orientadas a objetos de negocio
Un diagrama temporal de sucesos permite expresar, mediante relaciones de precedencia o
sucesin, un orden parcial entre sucesos independientemente de la homogeneidad de
identificacin.
La capacidad expresiva de todos estos lenguajes es muy similar.
Todos se basan en Redes de Petri, es decir en hipergrafos dirigidos, para definir el orden entre
sucesos.
.1 .1 .1 .1 Merise Merise Merise Merise
El Modelo Conceptual de Tratamientos de Merise se basa en los conceptos de evento
(disparo o estado), sincronismo de eventos (la lgica de condiciones) y tratamiento.


Figura 21 Elementos del Nodelo Conceptual de Tratamientos de Nerise
Cada tratamiento puede tener una jerarqua de especializacin de resultados. En el caso
ms simple se reflejan dos alternativas. El resultado en caso de que todo sea correcto o el
resultado en caso de error. Pero un tratamiento puede conducir a una jerarqua ms
compleja.
eventos
sincronismo
tratamiento
Eventos
resultantes
La organizacin de las interacciones
49

Figura 22 Jerarquia de especializacin de resultados.
Merise organiza los sucesos mediante relaciones de precedencia y estructurndolos
mediante los sincronismos.
Se puede observar que Merise utiliza el trmino evento para representar tanto los
estmulos externos como estados resultantes que son condiciones de disparo pero no el
estmulo en s.

Figura 23 Nodelo Conceptual de Tratamientos de Nerise
Es importante destacar que todo modelo Merise tiene una expresividad equivalente
mediante diagramas DFD.
La propuesta de [Gane 1980] para Anlisis Estructurado contiene una notacin para
estructurar flujos (* para y, + para o exclusivo) lo que resolvera el problema del
sincronismo. Tngase en cuenta que el sincronismo sirve para estructurar las relaciones
entre sucesos.

Los eventos que utiliza Merise sern en DFD o una entidad externa (eventos puramente
externos) o un archivo (eventos de condicin).
La siguiente figura muestra una visin dual del mismo fragmento de una secuencia de
sucesos.

Figura 2+ Equivalencia expresiva de Nerise y Analisis Estructurado.
De hecho algunas herramientas CASE comerciales permiten usar ambas notaciones.
La cuestin para el analista no es por tanto qu tcnica de diagramacin utiliza sino en
qu conceptos se basa para poder expresar lo mismo en diferentes tcnicas.
La organizacin de las interacciones
51
.2 .2 .2 .2 Diagramas de actividad Diagramas de actividad Diagramas de actividad Diagramas de actividad
Los Diagramas de Actividad de UML permiten tambin expresar rdenes temporales de
sucesos. Lo que en Merise se expresa mediante el sincronismo (la estructura de
relaciones) en Diagramas de Actividad se expresa mediante constructores explcitos: el
paralelismo o fork (el y yy y lgico en Merise) y la decisin o branch (el o oo o exclusivo en Merise).

Figura 25 Diagrama de Actividad
Los diagramas de actividad son menos expresivos que el modelo de Merise. Entre otras
cosas, el concepto de sincronizador permite estructurar las relaciones de forma compleja.
Por ejemplo puede permitir la inhibicin (A y no B) o cualquier formula proposicional
aplicada a los eventos.
4.1.4 BPMN BPMN BPMN BPMN
En junio de 2005 el OMG (Object Management Group) y BPMI (Business Process
Management Initiative) se han fusionado en una nica organizacin (BMI Business
Modelling & Integration http://bmi.omg.org) proponiendo la notacin BPMN (Bussiness
Process Modelling Notation). Esta notacin ha sido adoptada, entre otras organizaciones,
por la WfMC (Workflow Management Coalition http://www.wfmc.org), WARIA
(Workflow And Reengineering International Association http://www.waria.com).
La notacin BPMN incorpora una gran riqueza descriptiva que permite, por ejemplo,
distintos grafismos para cualificar los eventos.


Figura 26 Tipos de eventos iniciales en BPNN
Al igual que Merise diferencia entre eventos iniciales y finales (resultantes).

Figura 27 Tipos de eventos finales en BPNN
La notacin permite los conectores de flujos habituales. Distingue las alternativas (xor) inducidas
por los datos o inducidas externamente por eventos.
Incluye tambin los conectores complejos en los que permite asociar una expresin lgica a un
conjunto de flujos. Los conectores complejos son equivalentes al concepto de sincronismo en
Merise.



Figura 28 Conectores de flujos en BPNN
La organizacin de las interacciones
53
Distingue los flujos de secuencia en dos tipos: flujos normales y flujos de mensajes. Los flujos
normales sirven para indicar el orden de precedencia. Los flujos de mensajes suponen
comunicacin.
Los flujos adems pueden adornarse con matices de control para indicar que un flujo es opcional
o que es el flujo por defecto.

Flujo normal

Flujo opcional

Flujo por defecto

Flujo de mensaje

4.1.5 Casos de uso Casos de uso Casos de uso Casos de uso
Hurlburlt R. A Survey of Approaches for describing and formalizing use cases. Expertech Ltd.
1997. Recoge ms de 30 variantes de Casos de Uso.
Una de ellas los casos de uso orientados a meta de Cockburn. Los casos de uso conducidos por
metas constituyen una forma intermedia de organizacin de sucesos. El caso de uso contiene la
secuencia "principal" de interacciones. Es posible describir secuencias alternativas.

System under discussion: System under discussion: System under discussion: System under discussion: the insurance company
Primary Actor: Primary Actor: Primary Actor: Primary Actor: the claimant
Goal Goal Goal Goal: Get paid for car accident
Steps Steps Steps Steps:
1. Claimant submits claim with substantiating data.
2. Insurance company verifies claimant owns a valid policy
3. Insurance company assigns agent to examine case
4. Agent verifies all details are within policy guidelines
5. Insurance company pays claimant
Extensions Extensions Extensions Extensions:
1a. Submitted data is incomplete:
1a1. Insurance company requests missing information
1a2. Claimant supplies missing information
2a. Claimant does not own a valid policy:
2a1. Insurance company declines claim, notifies claimant, records all this, terminates
proceedings.
3a. No agents are available at this time
3a1. (What does the insurance company do here?)
4a. Accident violates basic policy guidelines:
4a1. Insurance company declines claim, notifies claimant, records all this, terminates
proceedings.
4b. Accident violates some minor policy guidelines:
4b1. Insurance company begins negotiation with claimant as to degree of payment to be
made.

Variations Variations Variations Variations:
1. Claimant is
a. a person

b. another insurance company
c. the government
5. Payment is
a. by check
b. by interbank transfer
c. by automatic prepayment of next installment
d. by creation and payment of another policy


La organizacin de las interacciones
55
4.1.6 Diagramas de composicin de interacciones Diagramas de composicin de interacciones Diagramas de composicin de interacciones Diagramas de composicin de interacciones
Alternativamente existen formas de estructurar interacciones externas que no estn basadas en el
tiempo. Son agrupaciones espaciales de interacciones sin contenidos de especificacin o con
bajos contenidos de especificacin. La tcnica de casos de uso es un modo de composicin de
interacciones externas, aunque las relaciones extend e include incorporan aspectos internos.


Figura 29 Composicin de interacciones externas.
Las jerarquas de acciones que propone Martin [Martin 1989] o los rboles de refinamiento de
funciones de Wieringa estructuran interacciones externas espacialmente. La cuestin es qu
considera cada cual una funcin, qu criterio de unidad se est proponiendo.
En la figura siguiente se muestra un ejemplo de un rbol de refinamiento de funciones.

Figura 30 Arbol de refinamiento de funciones.


El Anlisis Estructurado Moderno [Yourdon1989] no propone ninguna forma especial de organizar
los sucesos. De hecho propone la lista de sucesos es decir una simple relacin de todos los
sucesos de un sistema. Cuando tratamos con sistemas complejos una lista de sucesos es poco
conveniente. La validacin por parte del usuario es ms difcil. Siempre ser ms fcil para un
usuario encontrar omisiones en una estructura ordenada de sucesos que en una lista secuencial
sin ningn criterio estructural.
La organizacin de las interacciones
57
4.2 DIAGRAMAS DE COMPORTAMIENTO
4.2.1 Elementos bsicos de los d Elementos bsicos de los d Elementos bsicos de los d Elementos bsicos de los diagramas iagramas iagramas iagramas
Para el modelado de procesos de negocio es necesario como mnimo poder describir:
Encapsulamientos dinmicos (funciones, tareas, actividades...). Habitualmente representadas
por formas rectangulares. Con frecuencia presentan los cantos redondeados.

Figura 31 Forma de tarea en la notacin BPNN
Relaciones de temporalidad entre encapsulamientos dinmicos. Habitualmente representadas
mediante arcos dirigidos que indican el orden temporal entre elementos. En BPMN se
denominan flujos de secuencia.

Figura 32 Flujo de secuencia

Estructuradores o constructores de relaciones temporales complejas. Normalmente se ofrecen
tres constructores: el paralelismo o y-lgico, la alternativa u o-exclusivo y la opcionalidad u o-
inclusivo.

Figura 33 Constructores AND, XOR y OR en la notacin BPNN
La Figura 21 muestra estos constructores en la notacin BPMN pero los diagramas de
actividad de UML proponen una barra negra para el AND y un rombo para el XOR. La
opcionalidad se consigue combinando el paralelismo con flujos opcionales representados con
trazo discontinuo.


Disparos o eventos. En el caso de sucesos comunicativos el disparo se representa siempre
mediante una entidad externa o actor primario que comunica al sistema algo que ha ocurrido.
Los diagramas de actividad no contemplan este hecho. La notacin BPMN asocia el disparo al
evento. Lo representa mediante un crculo pequeo y denota que algo ha ocurrido en el
exterior del sistema.

Figura 3+ Disparadores en BPNN
Un disparo es una relacin entre una entidad externa que comunica un mensaje al sistema y
la reaccin que desencadena.

Figura 35 El disparo como relacin comunicativa
Mensajes. Los mensajes intercambiados entre los actores y el sistema los representaremos
mediante flechas de trazo grueso. A ser posible distinguiremos claramente el color de los
mensajes de entrada y de los mensajes de salida.

Figura 36 Nensajes de entrada y de salida
Entornos de proceso. Las actividades que se realizan en el sistema de informacin con motivo
de la comunicacin de un suceso tienen lugar en un entorno de proceso. La forma ms
extendida para representarlo es mediante el uso de calles o swimlanes.
La organizacin de las interacciones
59

Figura 37 Uso de swimlanes
4.2.2 Estructura de comportamiento. Estructura de comportamiento. Estructura de comportamiento. Estructura de comportamiento.
Para reflejar la estructura de comportamiento todas las tcnicas recurren a constructores que
permiten expresar el paralelismo, la opcionalidad o la alternativa.
Se trata del uso de las conectivas lgicas tradicionales. El y y y y lgico asociado al paralelismo, el o o o o
inclusivo asociado a la opcionalidad y el o o o o exclusivo asociado a la alternativa.
.1 .1 .1 .1 Opcionalidad Opcionalidad Opcionalidad Opcionalidad
La opcionalidad siempre se suele basar en el etiquetado de aristas. En el caso de los diagramas de
actividad se recurre al uso de guardas. Otras tcnicas proponen marcar las aristas opcionales
mediante trazo discontinuo.

Figura 38 Representacin de la opcionalidad

Poco frecuente es el uso de la negacin o de la inhibicin. Slo Merise, que permita expresar
mediante conectivas lgicas las condiciones de disparo de cada suceso, contemplaba la negacin.
.2 .2 .2 .2 La especializacin en los diagramas de La especializacin en los diagramas de La especializacin en los diagramas de La especializacin en los diagramas de comportamiento. comportamiento. comportamiento. comportamiento.
Usamos la especializacin en los diagramas de comportamiento para indicar alternativas en las
trayectorias de sucesos. La aparicin de trayectorias alternativas nace de diferentes formas.
Puede surgir asociada la diversidad estructural de los mensajes asociados a un suceso. La
denominaremos especializacin caracterstica. Se induce externamente y, en la prctica, el actor
que comunica los hechos ya conoce la variedad comunicativa.
Puede surgir asociada a las diferentes alternativas de disparo que pueden ocurrir tras un suceso.
Supone una toma de decisin por parte de algn actor que el que opta por la alternativa elegida.
La denominaremos especializacin electiva. El caso ms simple es la decisin entre los sucesos de
aprobacin o de rechazo que pueden seguir a un suceso de propuesta.
En principio puede parecer que la distincin entre las dos formas no es ntida. Podramos pensar
que en el caso de la aprobacin o del rechazo se trata de un mismo suceso que adopta mensajes
alternativos.
Existe sin embargo una pequea diferencia. La especializacin caracterstica unos supone eleccin
por parte de un actor. Por eso es caracterstica.
Si cuando una persona entre urgencias de un hospital el formulario de entrada es diferente segn
se trate de un nio con un adulto no se trata de un problema de eleccin. La persona que entra
no elige ser una cosa u otra. Es algo caracterstico en ella y no lo puede cambiar al menos en ese
instante.
Si el mdico que atiende el ingreso opta por la hospitalizacin del paciente que ingresa est
decidindose por una de las alternativas posibles de tratamiento.

Existe una forma de la especializacin caracterstica que no presenta alternativas estructurales sino
que est basada en los valores comunicados. Mediante reglas organizacionales podemos tipificar
diferentes alternativas de un suceso. Supongamos por ejemplo que una empresa define tres
posibles alternativas en su gestin de pedidos. Se importe del pedido es inferior a 1000 pasa
directamente a planificacin de produccin. Si el importe es superior a 1000 pero inferior a
12.000 debe ser aprobado por el responsable comercial. Si el monto superior es necesaria la
autorizacin del director comercial.
Se trata de especializacin caracterstica en el sentido de que no cabe eleccin. La trayectoria a
elegir est definida por caractersticas del mensaje.

La especializacin caracterstica define estados resultantes en un suceso a partir de los cuales
pueden surgir trayectorias diferentes. Las alternativas estn asociadas al suceso en el que se
produce la caracterizacin. Esta caracterizacin condiciona las trayectorias subsecuentes.
La especializacin electiva no est previamente determinada por ningn suceso. Simplemente
muestra las alternativas eleccin que aparecen a partir de un instante dado.
.3 .3 .3 .3 Formas grficas de los comportamientos especializados Formas grficas de los comportamientos especializados Formas grficas de los comportamientos especializados Formas grficas de los comportamientos especializados
Los modelos de especificacin de comportamiento utilizan diferentes variaciones sintcticas para
dar cuenta de trayectorias de sucesos alternativas. El conector ms utilizado es el rombo.
La organizacin de las interacciones
61

Figura 39 Especializacin en Diagramas de Actividad
Merise utiliza una expresividad asociada a la operacin o tratamiento para dar cuenta de la
especializacin. Un tratamiento tiene asociado diferentes posibles resultados que pueden reflejar
una jerarqua de especializacin.

Figura +0 Especializacin en Nerise
La notacin que permiten tanto las herramientas de workflow como los diagramas de actividad
no contempla la unidad. En la notacin Merise o la notacin de diagramas de Venn el suceso
genrico y los especializados estn en un mismo encapsulamiento.

Figura +1 Especializacin mediante diagramas de venn
La opcin de diagramas de actividad obliga a mezclar dos conceptos de interaccin la relacin
temporal y la relacin espacial.

Figura +2 Especializacin no encapsulada
En el diagrama de la figura no est definido si las actividades pertenecen a un mismo suceso o
deben considerarse sucesos diferentes. Por no hablar de casos realmente complejos en los que la
jerarqua de especializacin puede tener varios niveles.



Figura +3 Especializacin caracteristica no encapsulada y encapsulada
Pero esto slo es un problema cuando hablamos de especializacin caracterstica. Porque en
realidad las dos formas son necesarias.
En el caso de especializacin caracterstica la forma encapsulada es ms conveniente. Permite
mantener la unidad del suceso y es grficamente ms simple.
En el caso de especializacin electiva la forma externa es ms conveniente pues permite reflejar
con claridad las alternativas de eleccin que se presentan a partir de un suceso determinado.
.4 .4 .4 .4 Bucles, iteraciones Bucles, iteraciones Bucles, iteraciones Bucles, iteraciones
Los bucles en los diagramas de sucesos aparecen siempre vinculados a la especializacin. Un bucle
en un diagrama de comportamiento indica la decisin de repetir una trayectoria ya realizada;
normalmente para subsanar un error o defecto.
3
El comercial
confecciona un
presupuesto
4.2
El cliente rechaza el
presupuesto
4.1
El cliente acepta el
presupuesto
5.1
El Jefe de rea
cancela el proyecto
5.2
El Jefe de rea
propone confeccionar
un nuevo presupuesto

Figura ++ Bucle en un esquema de comportamiento

No debe presentarse como bucles las iteraciones o trazas repetitivas. En un esquema de
comportamiento pueden aparecer los sucesos alta de socio y alta de huertos de un socio.
A cada suceso alta de socio le pueden suceder mltiples sucesos alta de huertos. De la misma
forma que a un suceso alta de cliente le pueden suceder mltiples sucesos un cliente solicita un
pedido. En ningn caso se define un bucle sobre estos sucesos. En realidad no existe tal bucle.
Tras el suceso de solicitud de pedido no es necesario que ocurra otra instancia del mismo.
Sin duda podramos optar por una especializacin electiva y un bucle para reflejar el hecho de que
tras la solicitud de un pedido puede ocurrir otra solicitud de pedido o alternativamente que se
La organizacin de las interacciones
63
tramite el pedido. Esta precisin no es conveniente por la complejidad que incorporara en los
diagramas. Adems no deja de ser una representacin de un hecho que puede expresarse de
forma ms simple. Se trata en definitiva de un problema de paralelismo. Tras el suceso alta de
cliente o alta de socio pueden iniciarse n ocurrencias de los sucesos subsiguientes. Si quisiramos
expresarlo es ms prctico y sobre todo ms simple recurrir al concepto de cardinalidad entre
ocurrencias.

Figura +5 Relaciones de ocurrencia multiple.

4.3 GUAS DE DIAGRAMACIN.
Scott Ambler [Ambler 2005] ha publicado un libro sobre guas de estilo en UML. Propone las
siguientes guas para el trazado de diagramas de actividad:
1- Coloque el punto inicial en la parte superior izquierda de la hoja
2- Coloque algn punto final.
3- Simplifique lo mximo posible.
A continuacin propone el siguiente ejemplo

Figura +6 Diagrama con temporalidad bidimensional.
a- El eje temporal debe desarrollarse en una sola dimensin
Utilizando la norma de mantener un eje temporal nico, el diagrama se trazara en la forma que
muestra la figura siguiente.


Figura +7 Diagrama temporalidad en una sola dimensin
En el grfico de la Figura 33 el tiempo se dobla comienza transcurriendo verticalmente para
luego desarrollarse horizontalmente. Esto dificulta la comprensin del diagrama e incrementa el
tiempo dedicado a comprenderlo. Existen dos razones bsicas para seguir esta recomendacin. La
primera es que en la cultura occidental tendemos a leer de arriba abajo y de izquierda a derecha.
Cuando aparece informacin escrita nuestra percepcin tiende a seguir esta pauta. En el primer
diagrama es necesario invertir ms tiempo porque para entender las diferentes unidades de texto
es necesario realizar en paralelo una lectura vertical y otra horizontal.
La segunda porque segn muestran los trabajos de [Barsalou 1998] sobre formacin de conceptos
la mente humana asigna a los conceptos espaciales representaciones grficas especficas. Puesto
La organizacin de las interacciones
65
que el tiempo es una dimensin su representacin debe ser unidimensional y no bidimensional
como en la primera figura.
En este diagrama cuesta menos tiempo comprender que la actividad Obtain help to fill out the
forms es una actividad opcional que transcurre entre Fill out.... y Enroll in University
4.3.1 Trazado de comunicaciones. Trazado de comunicaciones. Trazado de comunicaciones. Trazado de comunicaciones.
b- Las relaciones de comunicacin deben desarrollarse en dimensin
perpendicular al eje temporal

Figura +8 Temporalidad vertical y comunicacin horizontal.
Las comunicaciones con el entorno del sistema informacin pueden reflejarse de dos maneras.
Una Consiste en vincular cada comunicacin con una actividad comunicativa. Habitualmente la
actividad suele tener un nombre formado por un verbo como enviar, recibir, remitir, comunicar, y
un complemento directo designando el documento que se comunica un complemento indirecto
que indica la persona o departamento a quien se enva. Es la que suele utilizarse en la mayora de
flujogramas o en las propuestas de workflow.
Otra posibilidad es asociar las comunicaciones a flujos de datos. Las acciones especficas que
generaran esta informacin se consideran vinculadas a un mensaje de entrada. Esta opcin
simplifica los diagramas.

c- Diferencie los grafismos de comunicacin y las relaciones de precedencia.


La organizacin de las interacciones
67
4.3.2 Especializacin Especializacin Especializacin Especializacin. .. .
Use la especializacin/generalizacin cuando sea necesario.
d- Solo se debe especializar si los caminos temporales son diferentes para
cada variante de la especializacin.

Figura +9 Especializacin con caminos independientes.
e- Puede aparecer especializacin asociada a salidas diferentes. Pero debe
evitarse si se trata de un mismo documento con contenidos variantes.
Por ejemplo, todos los meses se enva una carta felicitando a los empleados que han superado la
media de ventas y otra invitando a mejorar a los que estn por debajo de la media. El documento
es el mismo. Vara el contenido. No debera usarse especializacin de comportamiento.
f- Evite especializar las comunicaciones por diferencias en los soportes.
Si algo llega por telfono o por e-mail pero el contenido del mensaje y la reaccin asociadas son
iguales no afecta al comportamiento comunicativo. Solo es un matiz. Se puede poner mediante
adornos del mensaje (un telfono, un e-mail...).
g- Use especializacin encapsulada cuando tras un suceso puedan darse
variantes alternativas de un mismo hecho comunicativo.
3 Evaluar Solucin
2
Comunicar
Solucin
Tcnico
3.2
Solucin
correcta
3.1
Solucin
ncorrecta
Cliente
Cliente

Figura 50 Especializacin encapsulada.


h- Use especializacin no encapsulada cuando tras un suceso puedan darse
variantes que dependen de lo que ocurra en el futuro. Pero esas variantes no
sean alternativas de un mismo hecho comunicativo.

Figura 51 Especializacin no encapsulada.
En la figura anterior tras haber emitido la factura pueden ocurrir dos cosas. Que se reemita la
factura porque contena errores o que se proceda al pago y emisin de facturas a proveedores. El
que ocurra una u otra no depende del suceso Gesco FAC5 sino de cual es el primer mensaje que
llega a la organizacin.
Adems entre refacturar y emitir pago a proveedor no existe ninguna relacin comunicativa. No
son dos alternativas comunicativas relacionadas sino independientes.
i- Cuando aparecen bucles debe aparecer especializacin.
Cuando aparece un bucle debe existir algn camino alternativo para salir de l. La forma de
hacerlo est siempre vinculada a la especializacin. Aparece un suceso especializado que
constituye la ruptura del bucle.

Figura 52 Especializacin y bucles.

La especializacin se induce no solo en el suceso que constituye la ruptura del bucle
La organizacin de las interacciones
69

Figura 53 Especializacin y bucles.
Cuando en un suceso entran diferentes caminos temporales o flujos de precedencia. Ser
necesario considerar que los tratamientos internos del suceso comunicativo requerirn
especializacin.
Internamente las comunicaciones de incidencias debern diferenciar dos modalidades
comunicativas, las incidencias nuevas y las incidencias provenientes de una solucin incorrecta.


Anlisis de Requisitos y Procesos de Negocio
71
5 55 5- -- - Anlisis Anlisis Anlisis Anlisis de Requisitos y Procesos de Negocio de Requisitos y Procesos de Negocio de Requisitos y Procesos de Negocio de Requisitos y Procesos de Negocio
5.1 PERCEPCIONES DE LA REALIDAD
Los usuarios de los sistemas de informacin describen sus percepciones de manera diversa. Los
analistas tienen que enfrentarse al modelado de fenmenos en funcin de estas formas de
describir. Filsofos y cientficos discuten hace milenios sobre la realidad y la percepcin. En cierta
forma da igual de qu est constituido el mundo, cual sea su esencia, su ontologa. Lo importante
es qu perciben los humanos y cmo lo describen.
Wolgfang Hesse presenta la siguiente reflexin en el informe Frisco [FRIS98]:
We live in the age of nominalisation. Data processing - and particularly data modelling -
techniques even enforce this tendency by objectiIying (i.e. giving static descriptions) of
actions and processes. But nevertheless, there are continuous, dynamic processes in our
conceived world which are not completely grasped by these techniques but only in a
reduced, snapshot-like manner.
Dynamic "things" must not be confused with static descriptions of their results or of
intermediate and resulting states.
Cuando una organizacin se dota de un sistema de informacin los fenmenos en el sistema
objeto pueden ser percibidos de forma esttica o dinmica. Incluso un mismo tipo de fenmenos
puede ser percibido estticamente por unos usuarios o dinmicamente por otros.
Ambos tipos de fenmenos estn relacionados. Todo fenmeno esttico es siempre generado
por, al menos, un fenmeno dinmico. Podemos considerar a las personas como un fenmeno
esttico (una entidad persona) o como el resultado de fenmenos dinmicos (nacer... morir).
La visin de los usuarios depende de su relacin con los tipos de fenmenos en cuestin.

72
De acuerdo con [OPDA9+| plantear que la orientacin a objeto es una forma natural de ver
el mundo implica que en la percepcin humana del mundo real la estatica es mas basica o
fundamental que la dinamica. Sin embargo existen indicaciones de lo contrario". Entre esas
indicaciones estarian las filosofias orientales, algunas corrientes filosficas occidentales o la
preponderancia del verbo sobre los nombres en la mayoria de los lenguajes naturales.
Esta preponderancia de lo estatico esta presente en las propuestas ontolgicas y en los
mtodos inherentes a la aproximacin objetual. Lo estatico y lo dinamico no suele verse
como algo complementario o dual. Business processes in an organization are regarded to
be an orthogonal concept to the objects that model the system structure" [HART95|.
Wilfred Sellars habla de dos lineas fundamentales de conceptualizacin del mundo. Las
basadas en la categoria de la sustancia y las basadas en el concepto de evento. Para Sellars
el cambio es una caracteristica esencial de la existencia. El ser persiste a travs del cambio
que luego percibimos en trminos de estructura y propiedades.
The external thing selected and referred to as an object is never existentially given in
experience, but is cognitively given in the sense that it is interpreted and revealed.
[SELL34]
La justificacin existencial de nuestras cogniciones no es evidente.
Los colores no son clases naturales precisamente porque son el producto de la
evolucin biolgica, que tiene tolerancia por fronteras desdibujadas entre categoras
que horrorizara a un filsofo aficionado a ideas claras y distintas. Si la vida de una
criatura dependiera de empaquetar juntos la luna, el queso azul y las bicicletas, tengan
la seguridad de que la Madre Naturaleza encontrara una manera para hacerle ver
estas cosas como intuitivamente la misma y cabal clase de cosa . [DENN98]
Frente a la tendencia actual, introducida por la orientacin a objeto, que manifiesta que El
mundo est formado por objetos debe oponerse una expresin ms dinmica: El mundo est
formado por procesos
Los seres humanos observan estos procesos. Las limitaciones cognitivas nos llevan a considerarlos
de forma esttica o discreta. Pero la evidencia del carcter dinmico de las cosas est presente
desde los filsofos presocrticos.
Una observacin sobre el mundo es una correspondencia entre procesos y propiedades. Slo
sabemos describir el mundo en trminos de objetos y propiedades. El nico aspecto que
percibimos de los procesos es su variabilidad. Variabilidad que detectamos pero que no siempre
identificamos. Cuando observamos una catarata somos conscientes de percibir un proceso. Sin
embargo no somos capaces de identificar estados. Nuestra capacidad descriptiva est limitada por
nuestra capacidad de identificacin de cosas. Como no disponemos de identificadores para las
gotas de agua no podemos dar una descripcin de estado compositiva de la catarata. Nuestra
percepcin se limita a predicar propiedades estadsticas de las componentes como el caudal.
Como decamos en el captulo anterior: Dos son las percepciones que tenemos de los procesos:
Eventos e individuos. Es decir objetos y los cambios que se producen en ellos.
Un evento es el resultado de una observacin de un fenmeno en la que somos capaces de
percibir fluctuaciones que describimos mediante propiedades.
Un individuo es el resultado de la observacin de un proceso en el que no somos capaces de
percibir fluctuaciones o no tenemos la capacidad o el inters de constatarlas (aunque a veces
podamos suponer que ese individuo podr cambiar en otras observaciones).
Los actores de un sistemas de informacin describen sus percepciones de manera diversa. Los
analistas tienen que enfrentarse al modelado de fenmenos en funcin de estas formas de
Anlisis de Requisitos y Procesos de Negocio
73
describir. Da igual de hecho de qu est constituido el mundo. Lo importante es qu perciben los
humanos y cmo lo describen.
Cuando una organizacin se dota de un sistema de informacin los fenmenos en el sistema
objeto pueden ser percibidos de forma esttica o dinmica. Incluso un mismo tipo de fenmenos
puede ser percibido estticamente por unas personas o dinmicamente por otras.
Ambos tipos de fenmenos estn relacionados. Todo fenmeno esttico es siempre generado
por, al menos, un fenmeno dinmico. Podemos considerar a las personas como un fenmeno
esttico (una entidad persona) o como el resultado de fenmenos dinmicos (nacer... morir).
Las percepciones dependen de su relacin con los tipos de fenmenos en cuestin.
5.1.1 Observacin de eventos o de individuos Observacin de eventos o de individuos Observacin de eventos o de individuos Observacin de eventos o de individuos
Cuando los fenmenos generativos son lejanos en el tiempo, y por lo tanto no son directamente
observables, las personas describen el fenmeno en su perspectiva esttica, por ejemplo una
cuenca hidrogrfica. Cuando los fenmenos generativos son observables (coetneos del SI) las
personas pueden tener percepciones dinmicas de ellos.
El hecho de que percibamos un fenmeno como objeto o como evento se debe en muchas
ocasiones a la relacin que tenemos con los cambios que experimenta. Cuando la frecuencia con
que percibimos los cambios es alta tenderemos a considerar los eventos. En caso contrario
consideraremos los individuos. Es decir, si a nuestros ojos un fenmeno es estable, porque apenas
observamos cambios, tenderemos a la percepcin esttica o de individuos. Si lo observamos como
algo cambiante tenderemos a la percepcin dinmica o de eventos.
Hay fenmenos que estn en cambio continuo. Pero a veces estos cambios son tan sutiles a
nuestra percepcin que nos pasan inadvertidos. Podemos estar un rato observando una planta. En
ella se estn produciendo cambios continuos. Sin embargo nos cuesta percibirlos.

74
5.1.2 Elementos del sistema objeto Elementos del sistema objeto Elementos del sistema objeto Elementos del sistema objeto
En el Sistema Objeto encontramos tres tipos de elementos caractersticos de las organizaciones de
negocio. Cada uno de ellos se percibe de forma diferente por los actores organizacionales.
Elementos bsicos
Constituidos por las materias primas y los productos o servicios comercializados. Son los
operandos de los procesos organizacionales. Pueden ser ms o menos complejos. Su
descripcin puede requerir una simple clase con varios atributos descriptivos o responder a
una composicin compleja que requiera el uso de mltiples clases, agregaciones y
asociaciones. Se caracterizan porque:
Los eventos que los generan presentan distribuciones concentradas. Bien al principio de la
vida del sistema bien por ciclos definidos por la actividad del negocio.
Constituyen la imagen principal de la organizacin.
Su percepcin es mas estatica que dinamica. Por lo tanto se ajustan mas al analisis estatico.
Son temporalmente primarios.
Constituyen el elemento de competencia basico. Estan sujetos a conceptos como cuota de
mercado. Existen estudios de consumo.
Pueden ser objeto de mtricas de calidad de producto.
Suelen ser los actores organizacionales quienes los definen. Al menos en su forma esencial.
Pueden presentar complejidad compositiva en diferentes aspectos. Composiciones,
elaboraciones, empaquetamientos.


Figura 5+ Elementos basicos
Elementos Elementos Elementos Elementos mediadores mediadores mediadores mediadores: son los agentes que participan o median en los procesos
organizacionales.
Pueden ser de nivel operacional. Son los que aportan, reciben, transforman, transportan los
objetos bsicos.
Pueden ser tambin los que soportan los procesos de gestin y planificacin de las
actividades de otros mediadores.
Participan en la gestin
Son destinatarios o contribuyen al valor anadido.
Son iniciales respecto al comportamiento del sistema.
No son elementos de mercado. Son agentes de mercado.
Se perciben estatica y dinamicamente.
Anlisis de Requisitos y Procesos de Negocio
75

Figura 55 Elementos mediadores
Elementos de gestin y produccin.
Son los procesos organizacionales. Tratan los elementos basicos (produccin,
desplazamiento, consumo, aprovisionamiento, diseno...) con la participacin de los
mediadores.
Constituyen la imagen de valor anadido.
Son mas proceso que objeto. Por lo tanto se ajustan mas a patrones temporales. Nunca son
iniciales. Primero se conciben los elementos basicos.
Definen el comportamiento del sistema. El comportamiento de elementos mediadores y
basicos esta condicionado por los elementos de gestin.
No son elementos de mercado. Confieren valor anadido.
Pueden ser objeto de mtricas de calidad de proceso.

Figura 56 Elementos de gestin
5.1.3 Entradas y salidas: lo bsico y lo derivado Entradas y salidas: lo bsico y lo derivado Entradas y salidas: lo bsico y lo derivado Entradas y salidas: lo bsico y lo derivado
Las interacciones entre un sistema de informacin y su entorno contienen descripciones de
fenmenos de la realidad. Toda interaccin puede tener una parte descriptiva bsica y una parte
descriptiva derivada. La parte bsica es la que corresponde a la nueva informacin aportada al
sistema. La parte derivada est constituida por toda aquella informacin que se obtiene de la que
ya conoce el sistema. En palabras de Lngefors un Sistema de Informacin es a technologically
implemented medium for recording, storing, and disseminating linguistic expressions, as well as
for drawing conclusions from such expressions. La informacin derivada est constituida por
todas las expresiones que diseminamos y por todas las conclusiones que podemos sacar de ellas.
Complejidad y tipicidad introsducida en cada
nivel.
Complejidad intrinseca bsica
Complejidad basico-mediador
Complejidad intrnseca de gestin
Complejidad gestin-mediacin
Compeljidad gestin-bsico

76
Es bsico el hecho de que informemos al sistema que un cliente c ha comprado x unidades del
producto z el da d. Es derivado, una conclusin de la que el sistema no ha sido informado
explcitamente, saber qu cliente ha comprado ms unidades del producto z el da d.
Los objetos de negocio tienen una composicin compleja. En algunos casos su estructura
completa puede ser el resultado de una derivacin. Por ejemplo, el listado del 20% de clientes
que consumen el 80% de los productos de una empresa. En otros pueden reflejar informacin
bsica. Por ejemplo una descripcin del catlogo de productos. En otros pueden ser mixtos. Unas
partes provienen de informacin bsica, otras provienen de informacin derivada y son el
resultado de ciertas conclusiones. Por ejemplo una factura tiene una informacin bsica: el
nmero de la factura, la fecha de la factura, el perodo de facturacin, el cliente al que
corresponde la factura y las lneas de albarn que recoge. El resto de informacin de la factura
puede derivarse de informacin que consta en el sistema. En algunos casos podra ser incluso
posible que las lneas de albarn fueran una derivacin del sistema a partir del dato del perodo de
facturacin.
En la estructura bsica de un suceso comunicativo -contacto, descripcin, reaccin- la descripcin
contiene informacin bsica y la reaccin describe las necesidades de derivacin: las conclusiones
o clculos.

En el modelo simplificado que denota diferentes estadios de proceso en una organizacin. El
contenido de informacin bsica y derivada se va invirtiendo a medida que avanzamos en el
tiempo.

Figura 57 variacin en la informacin basica y derivada de las interacciones
As en las interacciones de los procesos iniciales o de la fase de demanda el contenido de
informacin bsica es mayor, por ejemplo un pedido, que en las interacciones de las fases
finales por ejemplo una factura.
5.1.4 Niveles organizacionales Niveles organizacionales Niveles organizacionales Niveles organizacionales
Si atendemos a los niveles de gestin organizacional -estratgico, tctico, operacional-
observamos que en los niveles altos los requisitos que detectemos harn referencia a informacin
derivada. La carga de interacciones con aporte de informacin se deja al nivel operacional que es
el que observa de forma ms directa lo que ocurre da a da. A los niveles de decisin les interesan
ms las conclusiones, no la informacin detallada.
Anlisis de Requisitos y Procesos de Negocio
77

Figura 58 Niveles organizacionales, entradas y salidas.
5.2 PROCESOS Y OBJETOS.
La literatura ha acuado el concepto de negocio para referirse a un mbito significativo o de
valor de las percepciones. Utilizaremos esa denominacin para indicar percepciones prximas a
los actores organizacionales y no a los agentes informticos. As mientras un objeto de un
diagrama de clases es algo que se define sin ambigedad y que encapsula propiedades y mtodos
entorno a un mismo identificador un objeto de negocio es una percepcin de una estructura de
informacin por parte de un usuario. Un objeto de negocio puede ser un formulario o un
expediente que comprende diferentes formularios y escritos. Todo objeto de negocio puede
asociarse a un proceso de negocio que define los distintos pasos en los que el objeto de negocio
va tomando forma.
Un objeto de negocio se puede describir mediante un esquema de objetos de un diagrama de
clases.
Los procesos de negocio y los objetos de negocio constituyen una forma dual de nuestra
percepcin.
Las propiedades de un objeto de negocio pueden ser elementales o estructuradas. Las
propiedades estructuradas pueden ser, a su vez, objetos de negocio, es decir, composiciones de
propiedades que sean de inters para algn actor social. Obsrvese que donde dice inters podra
decir valor. Carece de importancia porque lo que se indica en realidad es que la estructura de un
objeto de negocio es discrecional y no universal. Alguien decide ver una parte de la realidad
representada mediante un determinado objeto de negocio.
Un proceso de negocio es una composicin temporal de interacciones comunicativas que
conforman un objeto de negocio.
Los objetos de negocio necesitan disponer de identificacin. De otra forma no seramos capaces
de distinguir dos fenmenos diferentes. La identificacin de un objeto puede ser propia o
dependiente.
Las componentes de un objeto de negocio pueden ser bsicas o derivadas. Son bsicas si existe
una interaccin comunicativa que aporta su valor descriptivo. Son derivadas si se obtienen
mediante un clculo o derivacin a partir de otras propiedades bsicas o derivadas.

78
Las interacciones comunicativas de entrada aportan informacin descriptiva de los objetos de
negocio. Las interacciones comunicativas de salida muestran objetos de negocio derivados.
Cualquier interaccin, en su forma ms general, puede contener descripciones bsicas y derivadas.
Los objetos de negocio pueden tener tambin un mayor o menor carcter bsico o derivado.
Por ejemplo, el listado de productos comprados por clientes de Murcia puede considerarse una
interaccin de salida y un objeto totalmente derivado. El alta de un proveedor puede
considerarse una interaccin de entrada y al proveedor como un objeto bsico.
Mientras que una factura es una composicin de propiedades bsicas y derivadas como veamos
en el apartado 5.1.3. ...una factura tiene una informacin bsica: la fecha de la factura, el perodo de
facturacin, el cliente al que corresponde la factura y las lneas de albarn que recoge. El resto de
informacin de la factura puede derivarse de informacin que consta en el sistema. En algunos casos podra
ser incluso posible que las lneas de albarn fueran una derivacin del sistema a partir del dato del perodo
de facturacin....
5.2.1 Dinmica de Dinmica de Dinmica de Dinmica de los objetos derivados los objetos derivados los objetos derivados los objetos derivados
Uno de los problemas que aparece en el desarrollo de aplicaciones es el de la dinmica de los
objetos derivados. Un objeto derivado puede ser esttico o dinmico. Es esttico el valor obtenido
debe preservarse aunque cambien los valores de los objetos de los que se deriva. Es dinmico si el
valor que interesa es el que se obtiene cada momento que se deriva. Es dinmica la lista de los
clientes de Murcia es esttico el precio del producto 33 de la factura 44.
Un tipo de objeto derivado esttico es un ndice secuencial. Por ejemplo la numeracin de las
facturas. Tambin los es la descripcin de un producto que aparece en una factura o su precio.
5.3 ESTRATEGIAS DE ANLISIS DE INTERACCIONES
Cmo buscamos requisitos? Cmo detectamos las interacciones que existen?
Obviamente no hay una sola forma. Los diferentes modos de percibir, las diferentes formas de
relacionarse con el sistema hacen imposible una nica estrategia de investigacin cognitiva.
Segn las percepciones de los usuarios y las caractersticas del sistema objeto podemos encontrar
diferentes formas de organizar la investigacin de un sistema. Cada una de ellas sugiere una
estrategia de anlisis diferente. Las estrategias no son excluyentes. Son contingentes. En funcin
de las caractersticas de cada usuario y del problema tratado puede ser conveniente el uso de una
u otra.
5.3.1 Estrategias directas Estrategias directas Estrategias directas Estrategias directas
Es aplicable cuando analizamos un sistema existente (que est funcionando aunque sea de forma
manual) en el que los usuarios tienen una cultura establecida de procedimientos y formularios
organizacionales. Al conocer los procedimientos de tramitacin ser posible obtener informacin
precisa de constructores y sus estructuras de adquisicin. Constituye la aproximacin ms fiable.
Anlisis de Requisitos y Procesos de Negocio
79

Figura 2. Estrategia directa
La estrategia directa es aplicable con usuarios de nivel operacional, es decir los que conocen los
procedimientos concretos. Los usuarios de nivel tctico y estratgico, que no conocen los
procedimientos bsicos con detalle, expresarn sus necesidades en trminos de consultas.
Describirn la informacin que necesitan obtener para su gestin organizacional.
Mediante estrategia directa partimos de la estructura de adquisicin de cada suceso constructor
para ir obteniendo el modelo de datos de forma incremental. Al analizar cada acontecimiento
podemos encontrar objetos bsicos cuyo anlisis puede responder a otra percepcin ms esttica.
Los sucesos consultores se definen de forma precisa a partir del modelo de datos.
La estrategia de JSD es directa. Primero se identifican y organizan los sucesos constructores. Las
organizaciones de constructores definen las entidades del sistema. Sobre estas estructuras se
definen las funciones de observacin (consultores).
5.3.2 Estrategias inversas Estrategias inversas Estrategias inversas Estrategias inversas
Es aplicable cuando analizamos un sistema que no existe ms que en la mente de los usuarios. No
existe una experiencia del mismo y es ms difcil establecer los procedimientos organizacionales.
Ser ms fcil saber qu esperan obtener los usuarios del sistema (consultores).
Tambin es adecuada cuando partimos de objetos de negocio que son fuertemente derivados y
en que no son en s mismos objeto directo de los sucesos generativos. Una nmina, por ejemplo,
recoge informacin bsica de objetos que resultan de sucesos que jams identifican el objeto
nmina.

Figura 3. Estrategia inversa
A partir de los consultores podemos definir el modelo de datos que satisface las necesidades de
consulta. Por ltimo ser necesario definir los constructores que permiten generar dicho modelo
de datos. La estrategia inversa es menos fiable a la hora de definir el modelo de datos. En

80
[ATRE80] se propone una tcnica de derivacin de modelo de datos a partir de estructuras de
consultores basada en la normalizacin.
5.3.3 Estrategias internas Estrategias internas Estrategias internas Estrategias internas
Consiste en definir la arquitectura interna de componentes del sistema y como gua para la
definicin de las comunicaciones.
Existen entidades en los sistemas que suelen ser de carcter bsico (normalmente referidas por las
dems entidades) cuya descripcin puede ser independiente de los tratamientos. Por ejemplo los
productos que una empresa comercializa, por complejos que sean, tienen caractersticas estticas
bien conocidas por los usuarios. Es la forma de gestionar estos productos (cmo se piden,
fabrican, transportan, facturan...). Las caractersticas observables de un buque o de las mercancas
sern descritas con detalle por los usuarios. Los sucesos en que se ve involucrado (llegada, salida,
amarre...) o la forma en que las mercancas se cargan o descargan son procesos que para
caracterizarse deben quedar reflejados en estructuras que no reflejan aspectos estticos directos
sino descripciones de actividades. La hora de llegada, la mercanca cargada, etc. no son
propiedades de la entidad buque sino resultado de actividades en las que el buque est
involucrado.

Figura +. Estrategia interna
En las actuales propuestas de modelado de SI la estrategia de anlisis es esencialmente interna. El
modelo ER propugna el descubrimiento de la estructura de entidades. Los constructores y
consultores se definen a posteriori. Los modelos orientados a objeto comienzan por definir la
arquitectura de entidades, el diagrama de clases. El resto de componentes se obtienen a partir de
esta arquitectura.
Todas las propuestas basadas en ontologas de objetos preconizan la descomposicin de
componentes internas bajo el criterio de unidad de identificacin.
La descomposicin interna esttica no es la nica posible. La versin inicial del Anlisis
Estructurado de Sistemas puede considerarse una estrategia interna.
Las tcnicas de integracin de vistas [BOUZ90], [BATI92].pueden considerarse una forma de
estrategia interna. Aunque la integracin de vistas parte de las visiones externas de usuarios cada
visin de usuario no responde a un concepto de constructor o consultor sino a un concepto de
esquema externo considerado como proyeccin del esquema interno. Por ello cada vista es un
fragmento del estado interno del sistema. La integracin de vistas no propone la separacin de
aspectos constructivos y consultivos y, en ese sentido, debe ser considerada una estrategia de
descomposicin interna.
Anlisis de Requisitos y Procesos de Negocio
81
5.4 CRITERIOS DE UNIDAD EN LOS PROCESOS DE NEGOCIO
A medida que vamos refinando el sistema surgen niveles de descomposicin cuyos elementos
responden a una intencin que va ms all de la mera reduccin de complejidad. Se trata de lo
que hoy en da se denominan procesos de negocio.
Un proceso de negocio es el conjunto de los sucesos que se requieren para gestionar de forma
completa una transaccin entre organizaciones.
El trmino de forma completa requiere, de nuevo, criterios de unidad. Preguntarnos qu
consideramos completo es lo mismo que preguntarnos qu consideramos la unidad de procesos
de negocio.
Los criterios que se vienen proponiendo en la literatura son las metas u objetivos.
El trmino proceso de negocio es habitual en las reas de BPM y en las propuestas de workflow.
A business process is a set of logically related business activities that combine to deliver
something of value (e.g. products, goods, services or information) to a customer.
Un proceso de negocio es una composicin de interacciones a medio o largo plazo en la que
podemos hacer las siguientes suposiciones:
El proceso de negocio se compone de interacciones elementales o sucesos.
El proceso de negocio tiene un inicio y un fin definidos.
En algunos casos pueden existir ms de una forma de iniciar y ms de una forma de terminar.
Si el proceso de negocio se inicia, forzosamente acabar alcanzndose un estado final en un
plazo razonable.
Los sucesos que componen un proceso de negocio se ordenan en el tiempo.
El criterio de unidad que se utiliza en los procesos de negocio coincide con el criterio de unidad
que se propone en las aproximaciones basadas en metas.
La delimitacin de las actividades que comprende un proceso de negocio o un caso de uso
orientado a metas siguen en realidad un mismo criterio: ofrecer valor aadido.
Para Cockburn la meta se asocia a la apreciacin de valor por parte de un actor. Este criterio
aparece en la propia definicin de caso de uso de Jacobson a sequence of transactions in a
system whose task is to yield a measurable value [Jacobson 1995].
Existen muchas tcnicas de modelado orientadas a objetivos [Bubenko 1994], [Potts 1989], [Yu
1994], [Anton 1996], [Rolland 1998]. El nico problema que plantean los objetivos es que no
siempre son nicos porque no todos los actores que participan en una interaccin necesariamente
comparten las mismas intenciones.
El punto de partida siempre ser una descripcin inicial del proceso de negocio. Esta descripcin
se obtendr de los responsables del proceso. Bien porque existen especificaciones de
procedimiento, bien porque se establezcan en una entrevista especfica.
La descripcin inicial servir para identificar las fuentes de informacin esenciales para la captura
de requisitos de ese proceso.
Ser necesario definir una ficha de proceso que contendr la descripcin general del proceso, los
objetivos de gestin, los indicadores de gestin y una posible relacin de carencias o necesidades
actuales.
A partir de este esquema inicial el analista proceder a determinar y completar un esquema de
sucesos comunicativos.

82

Figura 59 Ficha de proceso. (Rafael Cal. SOGET!)
5.5 LOS REQUISITOS DEL MBITO PROCESO
El mbito de los procesos es de carcter abstracto. Hay tres tipos de requisitos esenciales en un
proceso.
Las interacciones comunicativas que caracterizan el proceso.
Los objetos de negocio que caracterizan el proceso.
Los indicadores de negocio que dan al estamento directivo una visin global del proceso y
permiten su control efectivo.
5.6 ELEMENTOS DE UNA DESCRIPCIN DE REQUISITOS PROCESO
Nombre
Motivos para el cambio: problemas detectados en la gestin actual o necesidades que el
procedimiento actual no puede satisfacer.
Objetivos: mejoras esperadas en beneficio, reduccin de costes, recursos, tiempos, imagen...
Objetos de negocio: identifique los requisitos de observacin esenciales sobre los diferentes
elementos del sistema. Defina un glosario de los objetos, y sus principales caractersticas.
Elementos bsicos: Materias primas, bienes, servicios. Sobre qu elementos acta el proceso
que se va a definir.
Elementos mediadores: Recursos humanos, medios de produccin que intervienen en el
proceso y que sern objeto de inters en la aplicacin.
Gestin: Determine las fases esenciales de gestin involucradas.
Solicitud (valoracin-presupuesto-, aprobacin)
Anlisis de Requisitos y Procesos de Negocio
83
Planificacin (asignacin de recursos
Aprovisionamiento, Produccin, Ejecucin, Transformacin, Desplazamiento, Distribucin
Cobro
Fuentes de informacin: defina quienes participarn en el proceso de anlisis. Qu
formularios se utilizan en la gestin actual.
Usuario responsable
Usuarios implicados
Formularios en papel o electrnicos.
Interfaces: defina relaciones con otros subsistemas que recibirn o aportarn informacin al
proceso. Este apartado solo debe documentarse si el proceso que se analiza no forma parte
de un subsistema superior que lo contiene en el que se han documentado las necesidades de
integracin.
Indicadores de Gestin
Indicador: Parmetro que define el volumen, esfuerzo o recursos que son necesarios en la
gestin actual.
Estimacin: volumen de la gestin actual, posibles tasas de error, tiempos de respuesta
actuales, sucesos crticos.
Objetivos: mejora propuesta de cada indicador.
Listado asociado: listados que permitirn conocer si los objetivos se estn satisfaciendo.
Diagrama de Sucesos a travs de l se define el comportamiento comunicativo que requiere el
proceso de negocio. Permite investigar las necesidades de informacin de forma metdica.
Lista de sucesos de negocio: est constituida por todos los sucesos de entrada (sucesos
constructores) y todos los sucesos de salida (sucesos consultores) utilizados en el diagrama
de sucesos o detectados como indicadores de gestin.

Tanto el diagrama de sucesos como la lista de sucesos o los consultores que resuelven los
indicadores de gestin son el resultado de diversas entrevistas.
En una primera entrevista se deben determinar los aspectos ms bsicos. En funcin de la cultura
tecnolgica y de gestin de los usuarios la riqueza de los consultores puede ser mayor o menor.
Cuando los usuarios sufren una informtica poco adaptada a sus necesidades tienen problemas
operacionales y es difcil que planteen problemas tcticos o estratgicos. Lo primero es resolver
las operaciones diarias.
Cuando una organizacin ha madurado en el uso de la tecnologa desarrolla una mayor riqueza
de consultores.
La cumplimentacin del documento de proceso de negocio comprende varias iteraciones.



84


Anlisis de Requisitos y Procesos de Negocio
85
5.7 ANLISIS DEL COMPORTAMIENTO COMUNICATIVO
El anlisis de comportamiento comunicativo es una estrategia directa basada en obtener las
interacciones a partir de la organizacin temporal de los procesos de entrada.
Definir el conjunto de sucesos comunicativos que la organizacin requiere para cada proceso
de negocio.
Reflejar en qu forma se organizan en el tiempo estas comunicaciones.
Definir el contenido esencial de cada una de las comunicaciones requeridas.
Para la determinacin de los sucesos comunicativos es recomendable utilizar las siguientes
tcnicas.
5.7.1 Anlisis generativo Anlisis generativo Anlisis generativo Anlisis generativo
El anlisis generativo se basa en construir las secuencias temporales o el comportamiento
comunicativo de los mensajes de entrada.
Para llevar a cabo el anlisis generativo podemos apoyarnos en los formularios existentes o en las
descripciones de procesos.
.1 .1 .1 .1 Anlisis Anlisis Anlisis Anlisis de formularios. de formularios. de formularios. de formularios.
Frente a cualquier formulario el analista indagar la forma en que se cumplimenta. Se trata de
detectar si el formulario corresponde a uno o ms sucesos comunicativos.
Se debe investigar con el usuario la forma en que se generan cada uno de los campos del
formulario. En qu instante se generan y quin los genera. Los formularios de entrada pueden ser
generados de forma incremental siendo el resultado de una secuencia de sucesos de entrada.
Cada comunicacin de entrada va aadiendo nueva informacin al formulario.
La documentacin inicial puede basarse en el propio formulario, marcando cada conjunto de
campos que se adquieran en el mismo suceso. Anotando quin es el responsable de cada suceso
e indicando el orden generativo para establecer la secuencia de sucesos.
El analista buscar cules son los actores primarios que originan la informacin del formulario,
mediante qu sucesos diferentes se construye, el mensaje que se comunica en cada suceso y cual
es el orden temporal de esta generacin.
.2 .2 .2 .2 Formularios Formularios Formularios Formularios y y y y funciones funciones funciones funciones comunicativas comunicativas comunicativas comunicativas
Lo primero que deber de hacer el analista es revisar las secuencias bsicas de los procedimientos
organizacionales y convertirlos en sucesos utilizando criterios de unidad comunicativa.
El esqueleto de los diagramas de comportamiento comunicativo son los sucesos constructores.
Cuando definimos procesos de negocio de forma detallada el hilo conductor se establece sobre
los sucesos que aportan nueva informacin al sistema. A partir de ellos se van definiendo las
necesidades de informacin.
Con la documentacin aportada por los usuarios el analista fijar las estructuras de adquisicin de
cada uno de los sucesos detectados. Mediante esta actividad pueden aparecer nuevos sucesos o
desaparecer algunos de los inicialmente considerados.
Los formularios deben ser exhaustivamente analizados para obtener toda la informacin necesaria
para la especificacin de los sucesos.
El analista deber comprender el uso de cada uno de los formularios utilizados por la
organizacin; prestando especial atencin a los formularios de entrada de datos.
Perry Edwards [Edwards 1985] define diferentes usos de formularios organizacionales que se
presentan a continuacin.

86
a ) Formularios de entrada de datos
Los formularios de entrada de datos estn asociados a la adquisicin de informacin. Son el punto
de partida del anlisis de comunicaciones. Si no existen ser necesario disearlos con los usuarios
construyendo prototipos simples. Los formularios son la mejor herramienta de especificacin y
validacin de contenidos que el analista puede utilizar. Por su carcter externo constituyen una
visin totalmente adaptada al usuario.
b ) Formularios de ida y vuelta
Los documentos de ida y vuelta son aqullos que el sistema genera, mediante un suceso
consultor, pero con la previsin de que vuelvan a ser ingresados en el sistema para alguna
tramitacin posterior.
Por ejemplo una persona se matricula de un curso y se le expide un documento de pago. Esta
persona va al banco, ingresa el importe de la matrcula y devuelve una copia sellada del
documento para reincorporarlo al sistema.
Tratamientos similares pueden asociarse a gestiones de pagos, envo y devolucin de albaranes,
una tarjeta de cargos en un hotel
El aspecto ms importante de los documentos de ida y vuelta es el control de identificacin. Al ser
la organizacin la que expide el documento siempre puede generar identificadores propios en
formatos que permitan una adquisicin gil (cdigos de barras, OCR).
Los documentos de ida y vuelta estarn asociados a diferentes sucesos constructivos. Sus
caractersticas dinmicas dependern de las secuencias de sucesos aplicables.
Frecuentemente los documentos de ida y vuelta requieren dispositivos complejos para su
tratamiento ya sea en emisin o en el uso (control de accesos, identificacin de tramitaciones).
c ) Formularios de resultados intermedios
Cuando una organizacin maneja funciones de su sistema de informacin de modo manual,
pueden aparecer formularios que en la prctica se asocian a consultores pero que por su forma de
uso parecen constructores.
Estos formularios suelen contener informacin resumida, campos acumulados, campos
calculados, en general informacin redundante que se actualiza en el momento en que la
informacin base se conoce y que simplifica la gestin.
Por ejemplo supongamos un almacn en el que se producen entradas y salidas de productos.
Habitualmente, cuando se gestiona de forma manual, los responsables de almacn tienen
formularios donde reflejan cada entrada y cada salida (o uno para entradas y otro para salidas).
Pero adems pueden tener otro formulario de existencias por producto. Cada vez que entra un
producto se refleja en el diario de entradas y se actualiza el estadillo de existencias de ese
producto.
Los formularios de resultados intermedios deben tratarse como informacin redundante.
Obsrvese que en el ejemplo anterior los datos adquiridos se utilizan para actualizar dos
formularios.
Se trata de separar los aspectos constructivos y consultivos.
La construccin implica adquirir la nueva informacin conocida: se aportan x unidades del
producto y en la fecha z.
La consulta implica definir el formulario de existencias como la suma de todas las unidades
aportadas para un cierto producto menos la suma de las salidas de ese mismo producto.
Que por razones de diseo decidamos mantener redundancia es otra cuestin aparte.
Ms que diferentes tipos de formularios, el analista debe estudiar la comunicacin que cada
suceso define sobre un formulario.
Anlisis de Requisitos y Procesos de Negocio
87
El objetivo es conocer los circuitos de las comunicaciones de entrada o sucesos constructores de
un rea de gestin. Es necesario preguntar por los sucesos iniciales: de qu forma o formas
comienza o a peticin de quin se inicia la gestin.
A partir de los sucesos iniciales se ir completando la secuencia temporal de sucesos necesarios
para el rea de gestin que se analiza.
d ) Formularios de consulta
Los formularios de consulta son los diferentes mensajes de salida del sistema. En muchos casos se
descubren de forma vinculada a los diferentes sucesos constructores.
2 Consultores de nivel estratgico y tctico.
Pueden ser los ms complejos. Suponen un conocimiento profundo de la gestin del negocio.
En muchos casos, dependiendo de la cultura organizacional, surgen de forma tarda cuando
la organizacin comienza a tener experiencia con el sistema desarrollado.
Surgen como requisitos del nivel gerencial que deber establecer sus indicadores de gestin.
No suelen vincularse a constructores concretos. Normalmente su forma y estructura debe ser
simple. Sin embargo su generacin puede ser sofisticada. En muchos casos requieren gran
esfuerzo de diseo. Puede ser necesario al anlisis de almacenes de datos o la minera de
datos.
Los requisitos de rendimiento y aspecto son importantes.
Suponen el aspecto ms evolucionado de una aplicacin.
3 Consultores de apoyo a la operacin.
Se trata normalmente de consultores vinculados a constructores. Consultores que son
necesarios para planificar las operaciones diarias de la organizacin. Son de complejidad
media. Los requisitos de aspecto y presentacin no son crticos. Lo importante es el contenido
de informacin. Los requisitos de rendimiento suelen ser crticos.
4 Consultores externos.
Son todos aquellos consultores que salen del mbito organizacional hacia los usuarios
externos. Los requisitos de aspecto son importantes porque afectan a la imagen
organizacional. Los requisitos de rendimiento no son crticos pero si el volumen de usuarios
externos es considerable pueden exigir un diseo y arquitectura complejos.
5 Consultores de auditora y control.
Son consultores que facilitan el seguimiento del uso del propio sistema de informacin.
Pueden ser orientados al control de responsabilidad del sistema: quin est haciendo uso de
las funciones del sistema, en qu momento y de qu forma.
Pueden orientarse a control de riesgos en la adquisicin y distribucin de la informacin.
Deteccin de responsabilidades de sucesos no iniciados. Se ha emitido la facturacin de los
pedidos del mes pasado?
Deteccin de sucesos normativos no realizados. Normalmente sern sucesos que deben
ocurrir segn un plan preestablecido y con ciertas restricciones temporales. Por ejemplo la
devolucin de un material prestado antes de un cierto plazo. La comunicacin de llegada de
una mercanca en un plazo razonable.

El anlisis detallado de consultores se simplifica cuando conocemos el modelo de datos del
sistema. Esto no significa que no deben documentarse los consultores hasta que no se conozcan
todos los constructores y se haya modelado el diagrama de datos. El analista puede ir detectando
las necesidades de consulta a medida que van surgiendo en las entrevistas con los usuarios. Puede
documentar los requisitos de rendimiento, aspecto, estructura y formato. Pero la generacin de
consultores no podr definirse de forma precisa hasta que el modelo de datos no est resuelto.

88
El diseo de consultores aporta adems los criterios de desnormalizacin, es decir, incorporacin
de redundancia, desnormalizacin de especializaciones, etc.
Desde el punto de vista generativo tendr que evaluarse la complejidad del consultor. Inicialmente
bastar con estudiar si es SQL-generable o si es algortmico. En el caso algortmico el estudio de
complejidad es imprescindible. Los tiempos de desarrollo en consultores algortmicos pueden ser
difciles de establecer.
Por ejemplo, una empresa de corte de tableros recibe pedidos para proveer de pequeos tableros
a empresas del sector del mueble de cocina y bao. La empresa compra grandes tableros y en
funcin de los pedidos procede al corte en mquinas especializadas. La empresa tiene una
persona que planifica los cortes. Actualmente el desperdicio es del orden del 10%. La empresa
quiere reducir este desperdicio a la mitad.
Este problema no se soluciona con una simple consulta en SQL. Se trata de un consultor que
requerir un estudio algortmico detallado. Es un problema de optimizacin cuya solucin general
se asocia al problema de la mochila.

.3 .3 .3 .3 Anlisis de procesos organizacionales. Anlisis de procesos organizacionales. Anlisis de procesos organizacionales. Anlisis de procesos organizacionales.
Las comunicaciones de entrada se pueden ir derivando de la forma en que la organizacin va
resolviendo los procesos de negocio. Cuando exista se puede utilizar la documentacin existente
de flujos de trabajo o procedimientos de calidad.
Normalmente esta documentacin describe de forma procedimental y orientada a las
responsabilidades de los actores que dan soporte a los procedimientos. Se trata de que cada
actor sepa como debe actuar y qu responsabilidades tiene.
La documentacin disponible ser objeto de mejora separando las interacciones externas de las
composiciones internas.
Las preguntas tendern siempre a identificar la unidad comunicativa identificando el disparo o
contacto inicial, el mensaje comunicado y el sincronismo de la reaccin organizacional.
Si los procesos organizacionales no estuvieran documentados ser preciso analizarlos para buscar
los instantes en que se producen los sucesos comunicativos.
En la mayora de los casos la trama de sucesos comunicativa est establecida. El analista
simplemente deber reconsiderar si los instantes comunicativos son los idneos y los contenidos
de los mensajes se adaptan a las necesidades organizacionales.
En algunos casos el analista deber disear la trama de observacin. Deber decidir cuales son los
instantes ms adecuados para la captura. Cmo se insertan en el proceso organizacional y cuales
son las alternativas de soportes que minimizan el uso de recursos y garantizan la mayor
adaptacin posible.
.4 .4 .4 .4 Anlisis de observaciones de estado. Anlisis de observaciones de estado. Anlisis de observaciones de estado. Anlisis de observaciones de estado.
Existen sucesos cuya composicin comunicativa es trivial. La informacin que aportan es el hecho
de haber ocurrido. El analista debe preocuparse de establecer si su deteccin es relevante para la
organizacin. Estos sucesos son de varios tipos. Pueden afectar a los elementos bsicos o
mediadores aportndoles valor.
Cada vez que algo ocurre en la organizacin hemos de considerar si el estado de algn elemento
bsico sufre un cambio relevante. Por ejemplo, una empresa fabrica muebles de cocina. Fabrica
pedido a pedido. El pedido se recibe, se planifica la produccin. Entra en produccin. Una vez
finalizada la fabricacin se lleva al muelle de carga de all lo carga el transportista para llevarlo al
cliente.
El pedido est en diferentes estados. Puede ocurrir que el pedido se haya finalizado y est todava
en el rea de fabricacin. Que la fabricacin se finalice no garantiza que el pedido est en el
Anlisis de Requisitos y Procesos de Negocio
89
muelle de carga. Los elementos fabricados de un pedido tiene diferente valor, o estado, segn
estn o no en el muelle de carga. Por lo tanto el suceso que comunica que un pedido se ha
desplazado al muelle de carga cambia el estado de un pedido. La estructura del mensaje puede
ser mnima: el identificador del pedido. Lo importante es que el pedido est en el muelle de carga
y el transportista lo podr cargar. No disponer de esta informacin puede suponer prdidas de
tiempo y dinero para la organizacin
.5 .5 .5 .5 El a El a El a El anlis nlis nlis nlisis is is is generativo en ausencia de documentacin. generativo en ausencia de documentacin. generativo en ausencia de documentacin. generativo en ausencia de documentacin.
Disee formularios y procesos con los usuarios. Si los usuarios no se ven obligados a pensar en la
estructura de informacin que necesitan y en los procesos por los que van a regirse su anlisis
corre graves riesgos.
5.7.2 Anlisis de salida Anlisis de salida Anlisis de salida Anlisis de salidas vinculada s vinculada s vinculada s vinculadas. s. s. s.
Todo mensaje de entrada puede servir de fuente de informacin para inferir la necesidad de
comunicaciones de salida vinculadas.
Se denominan sucesos vinculados porque en tiempo de anlisis surgen de forma vinculada al
mensaje de entrada. Normalmente en diseo tambin debern vincularse de modo que el
formulario que contenga un determinado suceso de entrada deber permitir disparar los
sucesos de salida vinculados.
Las necesidades de sucesos vinculados pueden ir apareciendo a medida que se va analizando con
detalle los sucesos de los formularios.
Todo mensaje de entrada puede contener aspectos consultores vinculados
.1 .1 .1 .1 Consultores previos a un constructor Consultores previos a un constructor Consultores previos a un constructor Consultores previos a un constructor
Para determinar el mensaje de entrada el usuario necesita informaciones previas que le permiten
decidir los datos que comunicar. Por ejemplo, una asignacin de personal a un proyecto puede
requerir un listado de la ocupacin del personal.
Los consultores previos deben detectarse preguntando al usuario por ellos en cada comunicacin
de entrada que informen. Un consultor previo permite decidir una eleccin ms adecuada de los
datos de entrada al suceso constructor. Por lo tanto en el proceso organizacional relacionado con
esa comunicacin existe una decisin, eleccin, estimacin, diagnstico, juicio, etc. El consultor
previo ayuda o facilita ese proceso.
Es posible que el agente que comunica la informacin de un suceso requiera ms de un consultor
previo.
La pregunta bsica es: Qu informacin necesita para poder realizar este proceso? o Qu
informacin le podra suministrar el sistema para facilitar su trabajo?
.2 .2 .2 .2 Consultores acreditativos de constructor Consultores acreditativos de constructor Consultores acreditativos de constructor Consultores acreditativos de constructor
El suceso requiere una salida o comunicacin a agentes externos. Se trata de un consultor que
certifica la transaccin realizada, normalmente ser una copia de los datos capturados. Es lo
que antiguamente se denominaba impresin hardcopy. Puede ser la expedicin de un recibo, la
copia de un pedido
.3 .3 .3 .3 Consultores informativos de un constructor Consultores informativos de un constructor Consultores informativos de un constructor Consultores informativos de un constructor
Los consultores informativos suponen la comunicacin a agentes organizacionales del contenido
del mensaje comunicado por un suceso.

90
Deber establecerse para quin es importante conocer la nueva informacin o quin tendr que
reaccionar frente a esa informacin. En definitiva a quin es necesario y a quin conviene
informar.

Figura 60 Consultores vinculados a un constructor.
Los consultores informativos pueden tener dos objetivos diferentes. Provocar que el actor que los
recibe inicie otro suceso o informar del estado de los asuntos sin responsabilidad inmediata para
la ejecucin de sucesos.
5.7.3 Consultores de auditora Consultores de auditora Consultores de auditora Consultores de auditora
.1 .1 .1 .1 Auditora de disparo o de ocurrencia: Auditora de disparo o de ocurrencia: Auditora de disparo o de ocurrencia: Auditora de disparo o de ocurrencia:
a ) Fiabilidad
Qu personas deben conocer que esto ha ocurrido?
No se trata de conocer el contenido sino la mera ocurrencia del suceso. Auditamos la ocurrencia,
por ejemplo, cuando pensamos que el responsable del disparo puede fallar o cuando alguien
necesita conocer ndices de actividad sobre uno o ms sucesos.
b ) Indicadores
La frecuencia de ocurrencia de una gestin est descendiendo? Tenemos los mismos pedidos
que en la misma semana del ao pasado? El tiempo medio entre el pedido y la carga del camin
se ha dilatado?
.2 .2 .2 .2 Auditora de contenidos Auditora de contenidos Auditora de contenidos Auditora de contenidos
a ) Fiabilidad
Alguien debe supervisar los datos que se aportan?
La auditora de contenidos permite establecer reglas de negocio respecto al comportamiento.
Por ejemplo: el importe de pedido no puede superar el riesgo establecido para el cliente salvo
que la operacin sea autorizada por el Jefe Comercial.
Anlisis de Requisitos y Procesos de Negocio
91
La auditora de contenidos conduce a dos bsquedas de requisitos:
Una para estudiar las necesidades y la forma ms adecuada de informar al auditor que la regla
de negocio ha sido transgredida. Si el auditor usa con frecuencia el sistema se puede proponer
un consultor que muestre todas las transgresiones cada vez que el usuario se conecte, a primera
hora de la maana, o a peticin del usuario. Si no usa el sistema con frecuencia ser necesario
hacerle llegar la informacin con la urgencia requerida. Por ejemplo usando correo electrnico.
La otra bsqueda de requisitos sera para determinar el constructor que permite autorizar o
denegar una determinada operacin.
Los sucesos vinculados por auditora de contenidos deben de permitir el sincronismo de reaccin.
El mismo entorno que comunica la trasgresin debe ser capaz de permitir la respuesta de quien
controla. Es decir el mismo medio a travs del cual se le comunica el consultor al usuario tiene
que permitir la respuesta.
b ) Indicadores
El importe medido de facturacin est decreciendo? Cual es la evolucin de ventas por
comercial?
.3 .3 .3 .3 Auditora de secuencias normativas Auditora de secuencias normativas Auditora de secuencias normativas Auditora de secuencias normativas
En los diagramas de comportamiento aparecen secuencias normativas de sucesos. Con ello
queremos decir que los usuarios, u otros mediadores, esperan que una vez ha ocurrido un
determinado suceso se alcance un suceso relacionado en un plazo razonable de tiempo. Es
normativo que si un avin despega debera aterrizar en un plazo razonable. Es normativo que si
un cliente hace un pedido se le acabe facturando en un plazo razonable de tiempo.
La gravedad que se atribuya a los diferentes sucesos de un proceso sugiere diferentes tipos de
auditora.
Los consultores admiten diferentes estilos de realizacin. La comunicacin de la trasgresin de las
reglas de auditora puede ser de tipo lo antes posible, es decir sncrona, o a peticin del usuario,
es decir asncrona. Segn las consideraciones de urgencia sobre el proceso o las consideraciones
de gravedad sobre las reglas de auditora la organizacin optar por un estilo de comunicacin.
Cuando usamos mecanismos de comunicacin para informar lo antes posible los mensajes
pueden ser especficos informando del hecho concreto a las personas indicadas.
Alternativamente podemos utilizar un estilo de comunicacin en demanda. En este caso es el
usuario el que accede a consultores que le permiten supervisar el cumplimiento de las reglas de
auditora.
5.7.4 Constructores vinculados Constructores vinculados Constructores vinculados Constructores vinculados
.1 .1 .1 .1 Auditora de comunicaciones Auditora de comunicaciones Auditora de comunicaciones Auditora de comunicaciones
Todo suceso consultor puede contener aspectos constructivos si queremos controlar su
ocurrencia (auditora de emisin).
Pero la auditora no garantiza que el consumidor haya recibido la informacin. Si adems
buscamos garanta es necesario incorporar constructores de confirmacin (auditora de
recepcin).

92

Figura 61 Constructores vinculados a un consultor.
Pueden aparecer tambin constructores vinculados a constructores. Por ejemplo constructores de
insercin condicionada. Cuando se formula un pedido si el cliente no existe se le da de alta. Es
posible que un suceso de gestin requiera vinculacin con uno o ms sucesos de mantenimiento
bsico.
.2 .2 .2 .2 Anlisis de excepciones y alternativas. Anlisis de excepciones y alternativas. Anlisis de excepciones y alternativas. Anlisis de excepciones y alternativas.
Normalmente las personas cuentan los sucesos normales, los que ocurren con ms frecuencia.
A los sucesos excepcionales se les da poca importancia. El analista deber investigar los
tratamientos excepcionales. Estos tratamientos son porcentualmente irrelevantes pero deben ser
detectados.
Pueden aparecer excepciones en los tratamientos internos, es decir, los que dependen de la
propia organizacin. Son sucesos asociados a la aprobacin, conformidad o toma de decisin. El
analista siempre verificar la posibilidad de rechazos o decisiones alternativas. El tipo de preguntas
a formular nunca se harn en forma positiva (siempre se aprueba?, todos se aprueban?) sino en
forma negativa (es imposible que ocurra de otra forma?).
Otras excepciones a considerar son las desviaciones de presunciones optimistas o la saturacin de
recursos. En procedimientos en los que se usan recursos de cualquier tipo (asignaciones,
planificaciones) debemos indagar si es posible que esos recursos no estn disponibles por el
propio uso organizacional por saturacin. La saturacin puede afectar a los mediadores que
deben responsabilizarse de una gestin o a la imputacin de elementos bsicos a un medido de
produccin o a un contenedor.
Pueden aparecer excepciones en aspectos externos, es decir, aquellos sucesos que pertenecen al
Sistema Objeto pero que estn fuera del mbito de la organizacin. Si estamos analizando una
gestin de envo de pedidos siempre ser necesario buscar posibles incidencias. Qu pasa si el
camin tiene una avera? Qu pasa si el cliente rechaza la mercanca?

5.7.5 Anlisis de Anlisis de Anlisis de Anlisis de Objetos Objetos Objetos Objetos de negocio. de negocio. de negocio. de negocio.
Los usuarios pueden comenzar por una descripcin de objetos que se utilizan en el proceso.
Tngase en cuenta que, en la mayora de los casos, los procesos de negocio son orientados a
objeto. No en el sentido ms tcnico de la palabra objeto, una clase, sino en el sentido ms
amplio de los usuarios una estructura de informacin compleja y variable. Los objetos de usuario
Anlisis de Requisitos y Procesos de Negocio
93
suelen ser agregados y complejos. Las clases de negocio preliminares designan una amalgama no
claramente delimitada de clases informticas es decir plenamente identificadas. Cuando un
usuario habla de una factura, lo hace en sentido laxo. Incluye todas las posibles configuraciones
de facturas que se dan en su negocio. Para un informtico la factura no existe. Existe un diagrama
de clases que describen la factura. Habr como mnimo una clase, que el informtico puede
llamar factura, identificada con un nmero de factura y que solo contendr los datos de la
cabecera de la factura. Existir otra clase lneas de factura con otro identificador asociado. Si las
lneas son de varios tipos el informtico especializar en varias clases ms, etc.
Los usuarios no piensan nunca as. Mantienen un pensamiento complejo y agregado respecto a
los objetos agregados.
Cuando el usuario comience a describir objetos, el analista tomar nota de sus descripciones.
Segn la forma de describir del usuario el analista tratar de identificar si se trata de clases o
propiedades, si son descripciones de elementos bsicos o derivados. SI las descripciones son
estticas o dinmicas y si el objeto descrito es complejo o simple.
El problema surge cuando el anlisis directo no es aplicable. EL anlisis generativo es aplicable
cuando las interacciones comunicativas identifican un mismo objeto de negocio o componentes
asociadas al mismo objeto de negocio. Es decir cuando la parte bsica del objeto de negocio
puede identificarse y, por lo tanto, asociarse a los sucesos comunicativos que la generan.
Pero existen objetos con una composicin mixta, bsica y derivada, en los que lo bsico es est
asociado a objetos diferentes del objeto de negocio que analizamos. No es obvio el
comportamiento de las comunicaciones que afectan a un objeto de negocio nmina. O su
estructura temporal es laxa y no tan fcil de seguir como una gestin de pedidos. El anlisis de
composicin de objetos derivados permite abordar el problema en estos casos.
5.7.6 La busqueda de in La busqueda de in La busqueda de in La busqueda de interacciones comunicativas a partir de objetos de negocio teracciones comunicativas a partir de objetos de negocio teracciones comunicativas a partir de objetos de negocio teracciones comunicativas a partir de objetos de negocio
Observe siempre qu expresiones usa el usuario. Identifique si el usuario describe de forma
esttica, descripcin de caractersticas de objeto, o est describiendo un cambio que se requiere o
que se produce, descripcin de caractersticas de un suceso.
Identifique si el usuario describe una propiedad elemental o algo complejo. Si se trata de un
complejo averige que tipo de identificacin tiene asociada dependiente o independiente.
Cuando el usuario describa objetos que no pueda asociar con facilidad a informacin proveniente
de sucesos de entrada obtenga la composicin y comience a analizar las componentes.
Busque el origen de cada componente. Si se trata de una caracterstica bsica debe llegar a
conocer cual es el suceso de entrada que informa de ella.
Si es una caracterstica derivada deber analizar la expresin de derivacin y el mapa de
dependencias con otras propiedades hasta llegar a las caractersticas bsicas. Deber anotar si la
derivacin es esttica o dinmica (5.2.1des hasta llegar a las caractersticas bsicas. Deber anotar
si la derivacin es esttica o dinmica (5.2.1).
Desarrolle el rbol de derivacin es decir la forma en que se componen las derivaciones.
Tenga en cuenta que cada derivacin no es ms que una funcin de consulta. Si se trata de
derivaciones estructurales deber indicar la relacin estructural mediante lenguaje natural (con
expresiones similares a las utilizadas en una sentencia SQL), usando estructuras de adquisicin o
con otro lenguaje.
Si se trata de derivaciones algortmicas deber definir el clculo mediante alguna tcnica de
especificacin.

94
Imagine la siguiente hoja de nmina. Es un objeto con gran contenido derivado. El sucesos emitir
nmina solo aportara el mes que se remunera y la fecha de emisin.

Podramos describir este objeto mediante la siguiente estructura.

COMPOSICIN ORIGEN
NOMINA=
Fecha emisin + e
Mes + e
Empleado(id)=
< nombre+ empleado.nombre
nif+ empleado.nif
salario base>+ empleado.salario
descuento ausencias+ calcular descuento ausencias( )
salario base neto+ salario base- descuento ausencias
ayuda familiar+ calcular ayuda familiar( )
cotizacin SS+ calcular cotizacin SS( )
retencin IRPF+ calcular retencin IRPF( )
salario neto+ salario base neto+ ayuda familiar- retencin IRPF
retencin plan jubilacin+ calcular retencin plan jubilacin( )
lquido+> salario neto - retencin plan jubilacin

Ahora deberamos conocer la estructura de cada derivacin. Eso nos llevar a nuevos objetos
derivados o a los sucesos generadores de algn objeto.
1-Octubre-1997
Nmina de SEPTIEMBRE de 1997

EMPLEADO Gutierrez Gomez, Francisco Antonio 22.336.443-R



SALARIO BASE 3.500
AUSENCIAS 3 das -785
SALARIO BASE NETO 2.715
AYUDA FAMILIAR 130
COTIZACIN S.S. -800
RETENCIN IRPF 9% -424
SALARIO NETO 1.621
PLAN DE JUBILACIN 2% -110
LQUIDO A PERCIBIR 1.511

Anlisis de Requisitos y Procesos de Negocio
95
Calcular
Liquido
Calcular
Neto
Calcular
Plan Jubilacin
Calcular
bruto
Calcular
descuento RPF
Obtener
descuento
ausencias
Obtener
Salario
base
Obtener
% RPF
Obtener
Retencin SS
Calcular
Ayudas
Obtener
cuota
Est casado?
Calcular
descuento plan
jubilacin
Calcular %plan
Obtener
Salario
base
Numero hijos?
empleado ausencias Tabla RPF
empleado
cuotas
empleado empleado
Revisin salarial
Parte de
ausencia
Alta Tramos Alta cuotas
Modificacin
situacin
familiar
Modificacin
situacin
familiar
Contrato
SUCESOS Objetos bsicos DERVACONES


Figura 62 Arbol de derivacin
Cada una de las funciones que calculan aspectos intermedios o componentes derivadas tiene una
especificacin de clculo asociada.
Esta especificacin puede ser descrita de diferentes formas. Por ejemplo el porcentaje a aplicar
para calcular el plan familiar se obtiene a partir de la siguiente tabla.

n de hijos
sueldo base 0 1 2 3 4 >4
3.000 10 9 9 8 7 7
< 5.000 12 11 10 10 9 8
5.000 15 14 13 13 12 11


96
Los objetos derivados pueden suponer descripciones de tipo algortmico o expresiones de
estructuras de objetos.
Por ejemplo, cada una de las lneas de la factura de un cliente resulta de obtener todas las lineas
de albarn de ese cliente para el perodo de facturacin especificado. Agruparlas por producto y
precio para as acumular todas las unidades del mismo producto y precio.
Especificacin de sucesos
97
6 66 6- -- - Especificacin de sucesos Especificacin de sucesos Especificacin de sucesos Especificacin de sucesos
6.1 REQUISITOS ASOCIADOS A UN SUCESO
Un suceso comunicativo es un requisito genrico refinable. La estructura de composicin de un
suceso se caracteriza por los tres aspectos bsicos de toda comunicacin de mensajes:
Contacto que recoge todos los requisitos relativos al escenario en el que se establece la
comunicacin. Las condiciones de disparo o de contacto. Desde los imprescindibles requisitos
de disponibilidad hasta los posibles requisitos de soportes especficos o de protocolos de
verificacin.
Descripcin comunicativa que recoge todos los requisitos relativos al mensaje que se
comunica al sistema y que constituye la descripcin del suceso acaecido y la aportacin de
nueva informacin. La descripcin del mensaje es la parte ms esencial de un suceso.
Influencia o reaccin que recoge todas las conclusiones y derivaciones que el sistema necesita
realizar. Todos los requisitos de comunicaciones de salida vinculadas que deben informar a
otros actores del sistema de hechos relacionados o derivados del que en ese momento se
informa.
6.2 IDENTIFICACIN Y NOMINACIN DE SUCESOS.
Los sucesos comunicativos constituyen la esencia de una especificacin de requisitos de negocio.
En este captulo se propone una estructura para los sucesos que contiene diferentes facetas
descriptivas relacionadas con la especificacin e investigacin de requisitos.

98
Todos los sucesos tendrn asociado un identificador
Identificador numrico/alfanumrico.
Coincidir siempre con la numeracin del esquema de sucesos. Como es frecuente que se
utilicen herramientas diferentes para diagramas y para el texto de la especificacin es
conveniente poner cuidado en la concordancia de identificador y de nombre. De lo contrario
se crea confusin y se dificulta la localizacin e identificacin correcta de elementos en la
especificacin.
Los identificadores pueden ser alfanumricos si contienen acrnimos o abreviaturas de reas
de negocio o de procesos de negocio (FAC 1, FAC 2, GESMED 2.2...).
Nombre del Suceso
El nombre del suceso debe ser consensuado con los usuarios.
El nombre de un suceso puede construirse siguiendo las recomendaciones de Yourdon.
Propone una estructura de nominacin basada en la secuencia:
<emisor+accin+objeto+[cualificacin]>
Un fotgrafo entrega un reportaje
La editorial devuelve el albarn firmado
En algunos casos podemos reemplazar al emisor por el receptor aunque ste sea un actor
secundario y se limite a dar soporte al proceso de adquisicin.
<receptor + accin+objeto+[cualificacin]>
Comercial recibe el albarn firmado
6.3 ESPECIFICACIN DE SUCESOS DE ENTRADA.
6.3.1 DESCRIPCIN GENERAL DESCRIPCIN GENERAL DESCRIPCIN GENERAL DESCRIPCIN GENERAL
La descripcin general del suceso contiene los grficos y el texto que permiten comprender el
suceso. Normalmente ser una enumeracin de las actividades que se realizan.
En la descripcin general podemos encontrar las siguientes secciones:
Objetivos
En el caso ms habitual, el noventa por cien de las veces, los objetivos de un suceso se
resumen en una frase simple.
Los objetivos de un suceso son dependientes del mbito en el que se considere.
En el mbito del Sistema de Informacin los objetivos responden a los propsitos de
observacin, influencia o control del sistema objeto. Se trata de los aspectos denotativos del
mensaje, del contenido descriptivo. Qu fenmeno o fenmenos comunicamos.
En el mbito del Sistema Organizacional los objetivos se relacionan con la funcin conativa
del mensaje, la intencin de inducir un determinado comportamiento. En este mbito los
objetivos se complican porque pueden aparecer diferentes intenciones y por lo tanto
diferentes objetivos. Es necesario conocer cul es la reaccin organizacional frente al mensaje
recibido. Si el analista no comprende la reaccin de los diferentes actores organizacionales es
difcil que pueda ajustar el contenido adecuado del mensaje a las necesidades
organizacionales.
Especificacin de sucesos
99
Cuando aparezcan diferentes intenciones organizacionales el analista debe considerar si son o
no compatibles. En caso de incompatibilidades debern utilizarse tcnicas de resolucin de
conflictos.
Descripcin
La descripcin muestra una visin ms detallada de las actividades del sistema de informacin
indicando las peculiaridades de los soportes. Pueden aparecer descripciones de los diferentes
canales de adquisicin utilizados o de los procedimientos diferidos de captura, cambios de
formato, etc.
La descripcin debe mostrar todos los sucesos fsicos y los procedimientos manuales
requeridos en cada suceso comunicativo.
Puede enumerar las distintas acciones y responsabilidades del suceso. No constituye una
especificacin rigurosa sino una explicacin que tiene como objetivo facilitar la comprensin
del suceso.
Necesidades y problemas
Este apartado es opcional. El analista debe siempre detectar la expresin de necesidades no
cubiertas o la indicacin de problemas por parte de los usuarios.
Necesidades y problemas pueden estar vinculados a los contenidos de la informacin o a los
agentes soporte que la manipulen.
Si se trata de los contenidos ser necesario remodelar con los usuarios los mensajes.
Las necesidades y problemas dan lugar a requisitos concretos (estructurales, de suceso, de
soporte, de rendimiento...). Si el problema est en la comunicacin ser preciso revisar la
descripcin de la comunicacin.
Si se trata de los soportes ser necesario su reemplazo o su optimizacin. En este caso los
requisitos estarn asociados a la disponibilidad o al rendimiento de alguno de los soportes.
6.3.2 DESCRIPCIN DEL CONTACTO DESCRIPCIN DEL CONTACTO DESCRIPCIN DEL CONTACTO DESCRIPCIN DEL CONTACTO
La descripcin de contacto se refiere a todo aquello que es necesario para que pueda tener lugar
el establecimiento de la comunicacin. Esto implica diferentes requisitos que no son solo del
software, sino del sistema de informacin y de los agentes y tecnologas que lo soportan. No
exclusivamente la digital.
Es posible que se requieran documentos acreditativos, la cdula de habitabilidad, el certificado de
empadronamiento, el pago del ltimo recibo, etc. Ser conveniente documentar o definir una lista
de verificacin (checklist) de cualquier aspecto documental que se considere necesario o
conveniente.
Las condiciones generan diferentes tipos de requisitos. Las condiciones de disponibilidad dan
lugar a requisitos operacionales de disponibilidad y de soporte.
Disponibilidad
Restricciones temporales de disponibilidad, horario ...
Agentes requeridos: los diferentes agentes para las funciones del sistema, adquisicin,
almacenamiento, proceso, distribucin deberan especificarse asi como su funcin,
disponibilidad y requisitos de operacin.
Canales: los posibles canales de comunicacin deberan ser documentados y descritos.
Contingencias: de cualquiera de los agentes o canales disponibles se especificaran las normas
habituales operacin y las normas contingentes de operacin. En funcin de la disponibilidad
requerida se estableceran los protocolos de reserva y reemplazo de los soportes requeridos.
Responsabilidad de actores
Autoridad: quienes estan autorizados a establecerfparticipar en la comunicacin

100
Acreditacin: que requisitos (protocolos) de acreditacin se consideran necesarios para los
diferentes actores. Como sabemos que un actor es quien dice ser. Sera necesario documentar
una lista con los requisitos de acreditacin.
Protocolos de acreditacin documental: verificaciones sobre los datos aportados, ya sea
mediante certificaciones documentales ya mediante inspeccin visual, diagnstico, juicio,
estimacin....
Protocolos de verificacin de elementos fsicos asociados a la comunicacin. Entrada de
material en un almacn. Book de fotgrafo...
6.3.3 DESCRIPCIN DE LA COMUNICACIN DESCRIPCIN DE LA COMUNICACIN DESCRIPCIN DE LA COMUNICACIN DESCRIPCIN DE LA COMUNICACIN
.1 .1 .1 .1 Estructura del mensaje Estructura del mensaje Estructura del mensaje Estructura del mensaje
Los sucesos pueden aportar informacin de objetos desconocidos por el sistema.
Individuos aislados no complejos. Por ejemplo informar de un nuevo producto en el catlogo
Conjuntos de individuos. Por ejemplo informar de que un conjunto de personas solicitan que
se asfalte una calle.
Agregados o complejos. Por ejemplo un pedido con el conjunto de productos solicitados
A su vez cada uno de ellos puede admitir variantes es decir especializacin. Podramos tener
conjuntos de individuos con variantes o agregados de variantes. Por ejemplo un pedido con lneas
de materias primas, de productos confeccionados o de servicios prestados como reparaciones o
transportes.

Los sucesos pueden aportar informacin sobre objetos conocidos por el sistema, es decir
informacin contextual. Que de nuevo puede ser:
De individuos aislados por ejemplo informar del nuevo precio de un producto en el catlogo
De conjuntos de individuos por ejemplo informar del importe de ayuda familiar que le ha
correspondido a un conjunto de personas que lo solicitaron
De aspectos parciales de un complejo. Por ejemplo informar de que 20 unidades del producto
XFRS del pedido 345/08 han sido ya producidas en este instante por el operario R2P2.

Todos estos aspectos pueden ser descritos en lenguaje natural. Siempre hay que tener en cuenta
que la forma de describirlos sea completa. Podemos usar una notacin estructurada para hacerlo.
Pero si lo hacemos correctamente es indiferente. La estructura del mensaje asociado a un suceso
debe definir los tipos de elementos descritos.
Si se trata de nueva informacin bsica describimos la estructura en cuestin. Por ejemplo un
suceso para dar de alta un cliente podra describirse mediante la siguiente estructura:
Cliente=
< cdigo+
fecha_alta+
CIF+
nombre+
calle+
nmero+
escalera+
puerta+
C.P.+
poblacin +
provincia >
Especificacin de sucesos
101
Eso mismo podemos decirlo en lenguaje natural. Pero sin ambigedad. De forma completa. No
sirve una descripcin del tipo se toman los datos del cliente el cif, el nombre, direccin, etc. O
se toman los datos relevantes del cliente. Habr que indicar del cliente es necesario conocer
Cdigo, fecha en que se dio de alta, su NIF el nombre y apellidos su direccin completa para
envos calle, nmero, escalera, puerta y cdigo postal as como la poblacin y la provincia
Tambin podemos adjuntar una ficha o formulario de cliente, si existe, que describa claramente la
composicin.

Si se trata de nueva informacin contextualizada tendremos que identificar el contexto.
Si quiero referirme a la propiedad (o propiedades) de un individuo podr escribir:
Objeto de negocio(id)<propiedad> Donde id lo utilizamos para indicar que usaremos alguna
expresin o forma de identificacin de un objeto (de una instancia) concreto.
Es decir basta con indicar que clase de objeto debo identificar y que propiedades sern
informadas. Por ejemplo para indicar que un cliente puede cambiar de direccin podemos
expresar.
CLIENTE (id)
< calle+
nmero+
escalera+
puerta+
C.P.+
provincia >

Donde indicamos que solo informaremos de que ha cambiado la direccin del cliente. El resto de
sus propiedades permanecen inalteradas.

Si quiero referirme a las propiedades de un conjunto de individuos que identificar uno a uno
escribir
{Objeto de negocio(id)<propiedad>}
Por ejemplo supongamos que es necesario cambiar el precio de varios productos.
{ PRODUCTOS (id)
< precio >
}

Este tipo de iteracin es poco frecuente. Normalmente los conjuntos de iteracin para objetos
existentes vienen determinados por alguna caracterstica. Si quiero referirme a las propiedades de
un conjunto de individuos necesito indicar el conjunto de los individuos.
{Objeto de negocio(id)<propiedad>} { Objeto de negocio(criterio de seleccin)<id>}
Necesito expresar dos aspectos. Uno es la estructura de la informacin que comunicar el otro el
conjunto de individuos conocidos por el sistema de los que necesitar informar.
Por ejemplo, una empresa ha recibido solicitudes de empleo. Direccin revisa las solicitudes y
decide aceptarlas indicando el nivel profesional al que se adscribe o rechazarlas.
REVISIN SOLICITUDES=
{< Solicitud (id)= id C { solicitudes(no existe(decision) )<id> )
Decisin +
nivel>
}
Obsrvese que se ha indicado una funcin genrica de consulta no existe(decisin) cuyo
significado puede ser ambiguo. La funcin no existe() es una funcin genrica que nos dice que
una propiedad nunca ha sido informada al sistema. Desde el punto de vista de la representacin,

102
del diseo, esto puede solucionarse mediante el uso de valores nulos o de otras soluciones ms
redundantes.
Puedo decirlo en lenguaje natural pero es importante determinar ambos aspectos sealados:
estructura que se comunica y descripcin del contexto de iteracin es decir descripcin del
conjunto de objetos afectados todas las solicitudes que todava no se han evaluado.
Si quiero referirme a la propiedad de un elemento de un agregado escribir
Objeto de negocio(id).objeto componente(id)<propiedad>
Por ejemplo para indicar que ha habido una alteracin en las unidades pedidas de un
determinado producto de un determinado pedido escribir:
PEDIDO(id).producto(id)=
< cantidad>

La estructura del mensaje se refina en los siguientes requisitos.
1 11 1 Componentes Componentes Componentes Componentes
La estructura de composicin de los objetos sobre los que se informa.
2 22 2 Dominios Dominios Dominios Dominios
Debe indicarse para cada componente cual es el dominio asociado. Esto permite mantener
adecuadamente un diccionario de datos.
3 33 3 Valores iniciales Valores iniciales Valores iniciales Valores iniciales
Los valores iniciales pertenecen en realidad al mbito del uso.
4 44 4 Derivacin Derivacin Derivacin Derivacin
La derivacin puede ser de componentes. el precio total es el precio unitario multiplicado
por las unidades ms el importe de IVA
Pero como hemos visto la derivacin puede generar estructuras ms complejas.
{< Solicitud (id)= id C { solicitudes(no existe(decisin) )<id> )
Por ejemplo podramos indicar que el conjunto de lneas de un albarn se deriva de las lineas
de un pedido.
LINEAS ALBARN= d PEDIDO(id).LINEAS =
{ <referencia+ {<referencia
cantidad_servida cantidad_pedida
precio_a_facturar + precio_pedido>}
> } LINEAS +

Especificacin de sucesos
103

Figura 63 Requisitos de la estructura comunicativa
.2 .2 .2 .2 Restricciones comunicativas. Restricciones comunicativas. Restricciones comunicativas. Restricciones comunicativas.
Definen el estado necesario en el sistema para que la comunicacin sea aceptable. Necesitan
referir elementos de la estructura de comunicacin. Son restricciones estructurales pero con
mayor nfasis en la relacin entre lo comunicado y lo conocido. Por ejemplo, el importe del
pedido no puede superar el riesgo asegurado para el cliente.
Las condiciones comunicativas pueden conducir a
1 11 1 Restricciones Estructurales Restricciones Estructurales Restricciones Estructurales Restricciones Estructurales
Son restricciones de la propia estructura del mensaje. No es necesario conocer el contexto
para poder describirlas.
2 22 2 Restricciones Contextuales Restricciones Contextuales Restricciones Contextuales Restricciones Contextuales
Son las que se basan en contrastar el mensaje que se comunica con lo ya conocido por el
sistema.
3 33 3 Restricciones de privacidad Restricciones de privacidad Restricciones de privacidad Restricciones de privacidad
Son restricciones de especializacin asociadas a diferentes criterios de privacidad para cada
usuario. Pueden afectar a los dominios, a la derivacin o a la composicin.
Establece niveles de privacidad sobre la estructura del mensaje. Puede afectar a las
componentes que cada tipo de usuario puede ver (que no vea los campos ay b) o a los
dominios a los que puede acceder (que solo le muestre los pedidos de su
Los requisitos de privacidad suponen la existencia de diferentes grados de autoridad sobre el
contenido del mensaje de un suceso. Es posible que un tipo de usuarios slo visualice
determinados campos o que otro tipo usuarios slo pueda trabajar con determinados
clientes. Los distintos grados de autoridad inducen especializaciones en la estructura de
adquisicin. Estas especializaciones pueden afectar a las componentes o a los dominios.
Especializacin de estructuras
Especializacin de dominios
.3 .3 .3 .3 Requisitos de fiabilidad Requisitos de fiabilidad Requisitos de fiabilidad Requisitos de fiabilidad
Los riesgos de fiabilidad establecen la confianza que debe tener el sistema sobre el actor primario
que aporta los datos. Si el analista detecta riesgos de fiabilidad ser necesario prever sucesos de
inspeccin que validen la bondad de los datos.

104
La escasa fiabilidad tiene que ver con un inadecuado diseo de las comunicaciones. Es posible que
el actor aporte datos incorrectos por error, por incomodidad o de forma malintencionada. Si el
sistema de adquisicin de datos resulta incmodo o requiere esfuerzos suplementarios a su
trabajo habitual, el usuario intentar evitarlo. Si el usuario puede tener perjuicio por aportar los
datos que el sistema le pide, tendr reticencia para hacerlo.
Los requisitos de fiabilidad aparecen cuando se consideran las condiciones en el mbito del
sistema organizacional. La documentacin previa que se requiere a un actor cuando comunica
con el sistema constituye requisitos de fiabilidad. El problema de los requisitos de fiabilidad es que
son difciles de obtener porque requieren un buen conocimiento del contexto cultural de los
actores primarios. Puede ocurrir que, al analizar un sistema, el analista nunca llegue a
entrevistarse con un actor primario. Es inusual, aunque no adecuado, que en el anlisis del
sistema de informacin para la gestin de un ayuntamiento el analista llegue a hablar con los
ciudadanos.
Los requisitos de fiabilidad pueden generar:
Requisitos de procedimientos manuales: como se vio en el apartado de condiciones del
entorno de contacto.
Protocolos de identificacin de emisores
Protocolos de acreditacin de los contenidos de mensajes.
Se trata de listas de verificacin con los documentos acreditativos que deber aportar
el emisor para garantizar o acreditar los datos y su fiabilidad.
Requisitos de sucesos de autorizacin, validacin y verificacin.
Es posible que al detectar problemas de fiabilidad se incorporen al proceso nuevos
sucesos en los que una persona experta revise y valide la informacin aportada. Se
trata de reglas de negocio de comportamiento.

.4 .4 .4 .4 Requisitos de uso Requisitos de uso Requisitos de uso Requisitos de uso
La descripcin de comunicacin recoge todas las necesidades de comunicacin de un suceso. Cul
es el mensaje que se comunica y qu otras necesidades vinculadas de comunicacin requiere.
Siempre pediremos a los usuarios que aporten cualquier formulario que utilicen en los
procedimientos de gestin. De no existir ningn formulario se propondr a los usuarios que
diseen uno utilizando las herramientas ofimticas a las que estn acostumbrados. En su defecto
el analista diseara con los usuarios los formularios necesarios. Mediante esta interaccin
obtendremos los requisitos estructurales del suceso caracterizados en la estructura de adquisicin.
La informacin descrita en un mensaje de entrada define la nueva informacin que llega al
sistema. Es la que permite decidir el modelado esencial de la memoria del sistema. Tambin es
esencial para el diseo de las pantallas de usuario.
Los requisitos de las comunicaciones de entrada son de varios tipos. Normalmente se pueden
expresar mediante una estructura tabular.
1 11 1 Localizadores/Filtros Localizadores/Filtros Localizadores/Filtros Localizadores/Filtros
Un localizador es una estructura de interfaz que permite trabajar con un determinado tipo de
objetos de negocio. EL localizador muestra todos los objetos que interesan a un usuario.
Usualmente debe mostrar el estado en que se encuentra cada uno permitiendo el acceso a las
caractersticas de cada objeto para su manipulacin.
Los localizadores manejan conjuntos de instancias y deben disponer de filtros para que cada
usuario pueda localizar los que sean de su inters.
Especificacin de sucesos
105
2 22 2 Formularios y documentos de usuario Formularios y documentos de usuario Formularios y documentos de usuario Formularios y documentos de usuario
Todo sucesos y los consultores vinculados pueden estar asociaos a documentos de usuario que
ser conveniente reproducir o, en su caso, mejorar.
3 33 3 Requisitos de Requisitos de Requisitos de Requisitos de aspecto aspecto aspecto aspecto
Los requisitos de aspecto deberan estar estandarizados en su mayora para cualquier
organizacin. Se refieren a todos los criterios de forma: tipos de letras, colores, distribuciones de
elementos en pantallas y listados...
4 44 4 Requisitos de soporte Requisitos de soporte Requisitos de soporte Requisitos de soporte editorial editorial editorial editorial

106
6.3.4 DESCRIPCIN DE LA DESCRIPCIN DE LA DESCRIPCIN DE LA DESCRIPCIN DE LA REACCIN REACCIN REACCIN REACCIN DEL SISTEMA DEL SISTEMA DEL SISTEMA DEL SISTEMA
Cuando un sistema de informacin conoce que algo ha ocurrido en el entorno que observa
reacciona de la siguiente manera:
Registra o almacena el nuevo conocimiento.
Extrae todas las conclusiones necesarias que pueden inferirse al incorporar el nuevo
conocimiento.
Pone a disposicin de los actores adecuados el nuevo conocimiento o las conclusiones que de
el se han derivado.
Esta caracterizacin gua la estructura de los requisitos de reaccin. Podemos hablar de los
requisitos de objetos de negocio bsicos o de clases de objeto bsicas, de los objetos de negocio
derivados que es necesario obtener como conclusin del nuevo conocimiento y de las
comunicaciones vinculadas que definen quin debe conocer todo este conocimiento.

Funciones y reglas de negocio
En este mbito es frecuente encontrar los trminos Funcin de negocio o Regla de negocio.
Una funcin de negocio, cuando se aplica en el mbito de los tratamientos de la reaccin, refiere
las actividades que el sistema realiza con la informacin.
Si el concepto funcin de negocio lo aplicamos a los objetos de negocio bsicos estaremos
hablando de aspectos de actualizacin de la memoria: insertar, modificar, borrar.
Si el concepto funcin de negocio lo aplicamos a los objetos de negocio derivados estaremos
hablando de aspectos de recuperacin y clculo.
El concepto de regla de negocio, cuando se aplica a este mbito, se refiere a una funcin de
negocio o a una parte de una funcin de negocio en la que aparece una lgica compleja basada
en combinaciones de condiciones.
.1 .1 .1 .1 Objetos Objetos Objetos Objetos de negocio de negocio de negocio de negocio bsicos bsicos bsicos bsicos
La descripcin de la reaccin del sistema se elabora a partir de las restricciones precedentes. La
estructura de adquisicin y la descripcin narrativa permiten inferir el modelo de datos y las
actividades de actualizacin o derivacin expresadas con mayor precisin.
En el caso de sucesos asociados a comunicaciones de entrada procederemos al modelado de
datos. Generaremos un modelo de datos asociado a la estructura de adquisicin que caracteriza el
mensaje. Solo los nuevos datos comunicados generan nuevas clases de objetos o entidades en el
sistema. El uso de referencias nos permite conectar los atributos a nuevas clases con las clases ya
existentes, definidas en sucesos previos.
Cada comunicacin de entrada es responsable de generar una parte del modelo de datos del
sistema.
.2 .2 .2 .2 Objetos Objetos Objetos Objetos de negocio de negocio de negocio de negocio derivados derivados derivados derivados
Funciones de negocio
Las funciones de negocio estn definidas por cada una de las consultas u objetos derivados
que los usuarios requieren. En unos casos las funciones de negocio podrn ser expresiones de
derivacin estructural, en otras funciones de clculo sobre objetos del sistema. En general los
objetos de negocio derivados deben analizarse siguiendo las pautas indicadas en el apartado
de anlisis de objetos derivados.

Especificacin de sucesos
107
Reglas de negocio
El concepto de regla de negocio es ambiguo. Para la wikipedia las reglas de negocio tienen la
siguiente definicin:
Reglas de negocio Reglas de negocio Reglas de negocio Reglas de negocio es la coleccin de polticas y restricciones de negocio de una
organizacin.
Un ejemplo de reglas de negocio sera:
"Un cliente al que facturamos ms de 10.000 al ao es un cliente de tipo A"
"A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a
3.000"
Las organizaciones funcionan siguiendo mltiples reglas de negocio, explcitas o tcitas,
que estn embebidas en procesos, aplicaciones informticas, documentos, etc. Pueden
residir en la cabeza de algunas personas o en el cdigo fuente de programas
informticos.
En los ltimos aos se viene observando una tendencia a gestionar de forma sistemtica y
centralizada las reglas de negocio, de forma que sea fcil y sencillo consultarlas,
entenderlas, utilizarlas, cambiarlas, etc.
La definicin es imprecisa. Pero las hay peores. Vase sino el manifiesto del
BusinessRulesGroup de 2003.
Las reglas de negocio estn asociadas a la actuacin contingente o condicional. A cmo debe
reaccionar o comportarse el sistema cuando se dan situaciones variables.
Para algunos autores las reglas de negocio pueden ser cualquiera de los requisitos
considerados hasta ahora.
En los ejemplos que proporciona la wikipedia se presenta de forma incompleta una
especializacin de tratamientos.
Cuando decimos que a los clientes de tipo A les aplicamos un descuento X en los pedidos de
importe Y establecemos una condicin de tratamiento, de la reaccin del sistema.
Pero lo importante, desde el punto de vista del anlisis, no es cada regla sino el conjunto
estructurado de reglas que definen de forma completa el tratamiento. La tcnica a utilizar en
este caso se conoce desde hace tiempo como tablas de decisin. Una tabla de decisin
permite evaluar cual es el repertorio de condiciones que entran en juego para la aplicacin de
un determinado tratamiento.
En el ejemplo que propone la wikipedia se trata de una visin incompleta de lo que debe ser
una regla de negocio. El analista debe detectar que como mnimo se establecen dos
condiciones una el tipo de cliente (cliente de tipo A), otra el importe del pedido (si el importe
es superior a 3000).
Por lo tanto se definir una regla de negocio de especializacin de tratamientos que podra
denominarse aplicacin de descuentos.
Esta regla se especificar mediante una tabla de decisin. En ella desarrollaremos cuatro
cuadrantes: condiciones, valores de condiciones, acciones y valores de acciones.

108

Seccin Identificacin de condiciones: se detalla una condicin por rengln. Se llaman condiciones
a situaciones variables que pueden ocurrir (p.ej: tipo de cliente, monto de ventas, antigedad,
etc.).
Seccin Identificacin de acciones: depende de la complejidad de los tratamientos. Puede ser una
nica accin valorada (tipo de descuento a valor del descuento) o una lista de acciones
potencialmente aplicables segn cada combinacin de valores de condicin. Se llaman acciones a
los distintos comportamientos que se asumirn en funcin de los valores que tomen las
condiciones
Seccin Valores de condiciones: se indican valores de las condiciones identificadas.
Seccin Valores de acciones: se indican valores de las acciones identificadas.

Las tablas de decisin permiten un marco de trabajo para determinar especializaciones de
tratamientos de forma exhaustiva y rigurosa. El analista comenzar por determinar las condiciones
que pueden afectar a la diversidad de tratamientos. Para cada condicin deber establecer la
enumeracin de valores admisibles. Estos valores sern valores discretos (A,B,C) o condiciones que
discretizan un rango continuo (de 0 a 1000, de 1001 a 10000, ms de 10000).

Tipos de reglas de negocio reactivas.
Las reglas de negocio de especializacin de tratamientos son las que permiten definir el
tipo de reaccin que adoptara el sistema en funcin del contenido de la comunicacin y de
la situacin en que est el sistema. Los consultores internos son los que definen el
tratamiento a adoptar a partir de los datos adquiridos. Este tipo de reglas no requieren
una intervencin de usuario. La unica accin del usuario es aportar los datos al sistema. A
partir de ellos el sistema decide automaticamente aplicando las reglas.
La especificacin y sobre todo el anlisis de reglas de negocio de especializacin de
tratamientos conviene realizarla mediante un rbol o una tabla de decisin.
Especificacin de sucesos
109

Figura 6+ Arbol de decisin para una regla de negocio de especializacin de tratamientos
Las reglas de negocio de especializacin de comportamiento se definen de manera similar.
Pero estas reglas se asocian a la auditoria y control de los mensajes comunicados y
requieren posteriores acciones de los usuarios. Supongamos una regla que establezca que
un pedido por un importe superior a 6.000 C tiene que ser aprobado por el director
comercial. Esta regla induce dos posibles comportamientos tras el suceso de un nuevo
pedido. El comportamiento habitual, que podria ser el suceso ordenar fabricacin, y un
comportamiento excepcional que podria ser el suceso autorizar pedido. Las reglas de
negocio de especializacin de comportamiento requieren nuevas comunicaciones, sucesos
vinculados de auditoria, y nuevo comportamiento en el sistema para recoger las acciones
permisivas o correctivas del comportamiento que se auditan.
Las reglas de negocio de especializacin de comportamiento tambin pueden analizarse y
describirse mediante tablas o rboles de decisin. Pero a diferencia de los tratamientos lo
nico que hacen es provocar cambios en variables de estado que sern utilizadas como
condiciones de disparo en los sucesos relacionados.
Las reglas de negocio de comportamiento exigen la revisin del esquema de sucesos del
proceso de negocio.
La seccin de acciones en este caso no se trata de tratamientos sino de sucesos
requeridos que reflejan el comportamiento esperado para cada combinacin de
condiciones.
.3 .3 .3 .3 Sucesos vinculados Sucesos vinculados Sucesos vinculados Sucesos vinculados
Al obtener los requisitos de cada suceso procederemos al anlisis de sucesos vinculados. Si alguna
de las comunicaciones vinculadas al suceso requiere auditora y control ser necesario revisar el
esquema de sucesos. El anlisis de sucesos vinculados se describe en el captulo anterior. Surge
en el modelado del proceso de negocio cuando se establece el comportamiento. Al describir cada
suceso el mayor conocimiento de los usuarios puede conducir a nuevos requisitos de sucesos
informativos, acreditativos o de otro tipo.
Los sucesos vinculados se enumeran en forma de lista. Cada suceso ser objeto de una
especificacin detallada.

110
6.3.5 Requis Requis Requis Requisitos comunicativos del mbito de uso itos comunicativos del mbito de uso itos comunicativos del mbito de uso itos comunicativos del mbito de uso
Existe informacin del mbito de uso que no afecta a la esencia comunicativa de la necesidad de
negocio. El analista debe saber separar los dos aspectos.
Como hemos visto un suceso informa al sistema de nuevos individuos que el sistema desconoca
hasta ese instante o de individuos conocidos por el sistema. Cuando se informa de algn aspecto
de objetos conocidos una cuestin esencial es que el usuario debe:
Identificar cada objeto del que va a informar. Describir los cambios producidos en determinadas
caractersticas de cada objeto identificado.
La necesidad de negocio es indicar que se habr de identificar un objeto de la clase A y que se
introducir una descripcin para sus propiedades a1,a2,a3.
Pero en el mbito de uso la forma de localizar un determinado objeto cobra gran importancia. Es
posible, incluso que ofrezcamos al usuario varias maneras alternativas de identificar una instancia
de una clase de objeto para que pueda informar de los cambios que ha sufrido.
6.3.6 R RR Requisitos comunicativos del mbito del suceso. equisitos comunicativos del mbito del suceso. equisitos comunicativos del mbito del suceso. equisitos comunicativos del mbito del suceso.
De la ocurrencia de un suceso surgen diferentes necesidades comunicativas:
Para la adquisicin consideraremos tres grupos de requisitos. Los requisitos de composicin o de
estructura, los requisitos de derivacin que no siempre aparecern y los requisitos de condiciones
y restricciones estructurales.
Para la reaccin consideraremos los requisitos de clases que se derivan directamente de la
estructura de adquisicin y las funciones y reglas de negocio que definen la relacin entre la
estructura de adquisicin y el modelo de datos.
Los requisitos asociados a un suceso no son solamente de informacin. Existen tambin requisitos
operacionales, habitualmente incluidos en los conocidos como no funcionales, y requisitos de uso.
Los requisitos de uso pueden surgir en los sucesos. Pero su mbito adecuado son los contextos
editoriales que se presentarn en el siguiente captulo. Un contexto editorial es una agrupacin de
sucesos que comparten una misma interfaz de usuario. Por ejemplo, en el caso de estudio de la
agencia fotogrfica todos los sucesos que afectan a la gestin de exclusivas (solicitud, asignacin,
finalizacin, cobro) se agruparan en un mismo contexto editorial de modo que reutilizaran las
componentes de interfaz.
No obstante es posible que en un suceso aparezcan requisitos de aspecto o de soporte editorial
(ayudas contextuales para la edicin de ciertos campos. Reutilizacin editorial de datos histricos
como el pedido ms frecuente de un usuario, etc.).
La estructura de requisitos propuesta permite abordar la investigacin definiendo un marco de
procedimiento para la realizacin de entrevistas.
Una vez establecido el proceso de negocio y definida la secuencia temporal de sucesos
comunicativos se proceder a especificar cada uno de los sucesos comunicativos.
Las entrevistas para capturar requisitos de sucesos partirn del esquema de sucesos y se guiarn
por la definicin de cada uno de los sucesos. Suceso a suceso se verificarn las diferentes facetas
descriptivas de cada uno de ellos
Especificacin de sucesos
111
6.4 ESTRUCTURAS DE ADQUISICIN
Una estructura de adquisicin es una especificacin de una estructura de datos para la descripcin
de un mensaje en la que cada elemento se asocia con la operacin editorial que permitir
instanciar su valor.
6.4.1 Notacin para la definicin de estructuras de mensajes Notacin para la definicin de estructuras de mensajes Notacin para la definicin de estructuras de mensajes Notacin para la definicin de estructuras de mensajes
La notacin BNF fue propuesta por Backus y Naur en el desarrollo del compilador de Algol 60
[Backus 1963].
En la propuesta inicial los constructores gramaticales fueron dos: la secuencia representada
mediante contigidad y la alternativa representada por la barra vertical de separacin.

Los parntesis angulares se utilizaban para delimitar smbolos no terminales.
Extensiones posteriores incorporaran las llaves {,} para repeticiones y los parntesis rectos [,] para
la opcionalidad. La cantidad de notaciones propuestas provocara el artculo de Wirth What can
we do about the unnecessary diversity of notation for syntactic definitions [Wirth 1977].
Una adaptacin significativa de la notacin BNF sera la utilizada para la descripcin de estructuras
de datos en el Anlisis Estructurado de Sistemas [DeMarco 1979].

La notacin que aqu se propone se basa en los tres constructores clsicos de secuencia,
alternativa y repeticin.
< + > Secuencia o composicin
[ | ] Alternativa o especializacin
{ } Iteracin
La diferencia fundamental con la mayora de notaciones propuestas estriba en el uso de
parntesis para la secuencia. Ni el anlisis estructurado de sistemas ni las notaciones iniciales de
BNF permiten la parentizacin de secuencias. Esta ausencia de parentizacin impide la descripcin
de estructuras dentro de estructuras. Por ejemplo:
Vehculo=Matrcula+Marca+Modelo+Motor=Cilindrada+Vlvulas+Combustble+Color+Extras
Vehculo=Matrcula+Marca+Modelo+Motor=<Cilindrada+Vlvulas+Combustible>+Color+Extras
La primera forma, la que permite el anlisis estructurado de sistemas, es ambigua. La ausencia de
parentizacin obliga a dividir las estructuras cada vez que queremos nominar una subestructura o
grupos datos.
Vehculo=Matrcula+Marca+Modelo+Motor+Color+Extras
Motor=Cilindrada+Vlvulas+Combustible
Esta peculiaridad impide una edicin simple de estructuras complejas. De hecho las herramientas
CASE de las tcnicas estructuradas presentaban una interfaz para la definicin de diccionarios de
datos costosa y pesada. Para ver una estructura completa era necesario navegar por el rbol de
subestructuras abriendo un formulario para cada una de ellas.

112
6.4.2 Operaciones de adquisicin de datos Operaciones de adquisicin de datos Operaciones de adquisicin de datos Operaciones de adquisicin de datos
Con la notacin presentada la estructura del mensaje que nos informa de la existencia de una
nueva persona puede definirse como:

Persona=

< cdigo+

fecha_alta+
CIF+

nombre+

calle+

nmero+

escalera+

puerta+

C.P.+

poblacin +

provincia >


Pero una estructura de adquisicin de datos indica adems el origen de los datos que constituyen
el mensaje.
Podemos vincular una operacin de adquisicin de datos a cada elemento de una estructura. Esta
idea fue propuesta en [Brodie 1984] para la tcnica ACM/PCM. Utilizaremos las siguientes
abstracciones bsicas de operaciones de adquisicin de datos:
i para los datos que el usuario introducir o aportar al sistema de forma libre. Estos
datos no son predecibles por el sistema. El sistema desconoce el instante exacto y el valor
de los datos que un agente puede comunicar al sistema. El gerente de un videoclub no
sabe en qu momento se pasar un socio del videoclub ni las pelculas que le pedir.
e para los datos que el usuario aportar pero en un dominio que el sistema puede prever.
Por lo tanto el usuario elegir entre las opciones que el sistema le proponga. El socio del
videoclub slo podr pedir pelculas en video o en dvd. Toda operacin de eleccin
supone la indicacin de un conjunto asociado de valores. En el caso de tipos enumerados
se puede utilizar el constructor de alternativas e [dvd|video]
d para los datos que puedan ser calculados o derivados de otros. El precio final a pagar
por el cliente no es necesario introducirlo si es calculable a partir de los precios unitarios.
g para los datos que pueden ser generados por el propio sistema. Como es el caso de los
cdigos o de la fecha del da o de las constantes. No dependen de la voluntad de un
agente externo y pueden ser generados en cualquier instante por agentes del sistema.
Toda generacin se asociar a una funcin g funcion() o a una constante g iniciado.
Aadiendo las operaciones de captura de datos podemos describir la estructura de adquisicin de
los mensajes que nos informan de la existencia de nuevas personas como:
Persona=
< cdigo+ G F1()
fecha_alta+ G hoy()
CIF+ I
nombre+ I
calle+ I
nmero+ I
escalera+ I
puerta+ I
poblacin + I
C.P.+ I
provincia > D F2 (C.P.)

Especificacin de sucesos
113
Donde indicamos que en el suceso el cdigo de persona se generar segn una funcin
especfica, que la fecha se generar a partir de la funcin hoy(), que el resto de datos se
introducirn por el usuario y que la provincia se derivar a partir del Cdigo Postal (C.P.).
.1 .1 .1 .1 C CC Composicin de operaciones omposicin de operaciones omposicin de operaciones omposicin de operaciones
Las operaciones de adquisicin pueden componerse en diferentes formas.
Las operaciones de generacin o derivacin pueden ser una forma de establecer valores iniciales.
Es posible que una operacin de generacin de lugar a datos editables por el usuario.
Por ejemplo la fecha de alta puede generarse a partir de la fecha actual y adems puede ser
editada por el usuario

Persona=
< cdigo+ g F1()
fecha_alta+ g i hoy()

>

La estructura de operaciones de adquisicin puede expresarse con ms rigor como < g hoy() + i >
.2 .2 .2 .2 Expresiones de derivacin Expresiones de derivacin Expresiones de derivacin Expresiones de derivacin
En su forma ms simple una expresin derivada refleja que un campo de un formulario es el
resultado de una operacin a partir de otros campos.
Sea, por ejemplo, el siguiente fragmento de estructura de adquisicin que describe la introduccin
de un pedido:
< { LINEA DE PEDIDO=
< Referencia= I
Descripcin+
Precio >+
Cantidad + I
Total lnea d Cantidad*Precio
>
}+
Total
>
d (Total lnea)
En la expresin de derivacin asociada a la componente Total Lnea aparecen dos propiedades
que por comodidad no hemos prefijado con el nombre de su estructura.
Total lnea d Cantidad*Precio
De forma ms rigurosa debiramos haber escrito para referirnos a estas propiedades:
LINEA DE PEDIDO.Precio y LINEA DE PEDIDO.Cantidad
Sin embargo no necesitamos prefijar las propiedades puesto que no existe ambigedad.
Igual ocurre con la segunda expresin.
Total d (Total lnea)
El sumatorio se refiere sin ambigedad a una propiedad que pertenece a una iteracin.

114
6.4.3 Derivacin de estructuras Derivacin de estructuras Derivacin de estructuras Derivacin de estructuras
.1 .1 .1 .1 Selectores Selectores Selectores Selectores
La estructura de datos asociada a la comunicacin de un suceso, no slo contiene referencias a
los nuevos datos. Tambin puede contener referencias a datos previamente conocidos por el
sistema.
Supongamos que queremos representar la estructura de adquisicin asociada a mensajes del tipo
Una persona cambia de domicilio. Lo primero que tendremos que hacer es recordar los datos
de la persona en cuestin. Para ello usaremos los parntesis de seleccin. El uso de parntesis de
seleccin con una estructura indica una referencia al entorno de la memoria del sistema en vez de
una referencia al entorno editorial.
Persona= D Persona(cdigo I)
< cdigo+ < cdigo+
fecha_alta+ fecha_alta+
CIF+ CIF+
nombre+ nombre+
calle+ calle+ I
nmero+ nmero+ I
escalera+ escalera+ I
puerta+ puerta+ I
poblacin + poblacin + I
C.P.+ C.P.+ I
provincia > provincia > D F2 (C.P.)
Esta forma supone una derivacin estructural. Lo que se est expresando es que la informacin
origen del mensaje que se va a construir se obtiene del propio sistema de informacin.
No derivamos un campo sino una instancia de la estructura completa de persona. Por simplicidad
y dada la total similitud de propiedades podemos reducirlo a la forma siguiente.

Persona (cdigo) (cdigo) (cdigo) (cdigo) = I
< fecha_alta +
CIF+
nombre+
calle+ I
nmero+ I
escalera+ I
puerta+ I
poblacin + I
C.P.+ I
provincia > D F2 (C.P.)

Mediante expresiones de derivacin podemos obtener valores elementales, conjuntos de valores o
conjuntos estructurados de valores.
Por ejemplo Cliente(provincia){<apellidos, nombre>} denota el conjunto de apellidos y nombre de
los clientes de una determinada provincia.
.2 .2 .2 .2 Relaciones Relaciones Relaciones Relaciones
Las estructuras mantienen entre ellas relaciones de contigidad que se expresan de diferentes
formas segn el modelo de datos usado.
En el modelo relacional se utilizan los mecanismos de clave ajena. En el modelo ER se utilizan las
relaciones. En los modelos de objetos se usan la asociacin y la agregacin.
En la notacin propuesta dos estructuras tienen relacin de contigidad si una de ellas es
componente de la otra.
Especificacin de sucesos
115
Sea el ejemplo de la figura siguiente que muestra un fragmento de una cabecera de pedido.
PEDIDO=

< num_pedido +

fecha_pedido+

CLIENTE=

< CIF+

nombre+

razn social+

provincia+

.....


En esta estructura pedido y cliente son estructuras relacionadas, de la misma forma que lo sern
en los modelos de datos correspondientes. Toda relacin de contigidad requiere una definicin
de cardinalidad o multiplicidad. Sabemos que entre pedido y cliente existe una cardinalidad M-1.
Las siguientes expresiones derivadas son equivalentes. Denotan las fechas en que un determinado
cliente ha realizado algn pedido.
Cliente(cif).Pedido{<fecha>}, Cliente(cif).{Pedido<fecha>}, Cliente(cif).{Pedido.fecha},
{Cliente(cif).Pedido<fecha>}, {Cliente(cif).Pedido.fecha}
Si bien hay varias maneras de expresar lo mismo, se recomienda usar siempre una forma estndar.
Preferiblemente se optar por una de la dos ltimas porque expresan mejor que el resultado es
una iteracin y, adems, permiten el uso de operaciones poblacionales (equivalentes a las
operaciones agregadas de SQL). Por ejemplo la fecha del primer pedido que se hizo en una
determinada provincia:
Min{Cliente(provincia).Pedido.fecha_pedido}
En la estructura de pedido que se muestra, cliente y lineas no mantienen relacin de contigidad.
Pero las dos son contiguas al pedido.
PEDIDO=

< num_pedido+

fecha_pedido+

CLIENTE=

< CIF+

nombre+

razn social+

calle+

nmero+

escalera+

puerta+

C.P.+

provincia >

LINEAS=

{ <referencia+

descripcin+

cantidad

precio +

importe

> } LINEAS +

total

> PEDIDO


Por ello para obtener la cantidad de artculos de la referencia 33 que solicitaron los clientes de
Huelva en el mes de mayo es necesario utilizar el hecho de que ambas mantienen relacin de
contigidad con PEDIDO.
Sum{CLIENTE(provincia=huelva).PEDIDO(mes(fecha_pedido)=mayo-05).LINEAS(referencia=33)<cantidad>}

116
.3 .3 .3 .3 Iteraciones der Iteraciones der Iteraciones der Iteraciones derivadas ivadas ivadas ivadas
En algunos casos es necesario usar conjuntos de iteracin en la definicin de estructuras de
adquisicin. Una iteracin es un conjunto de instancias de una clase que se derivan del sistema.
Por ejemplo, supongamos que queremos indicar que una factura se realiza a partir de los datos
que se almacenaron en el pedido correspondiente.

FACTURA=
< num_factura+ g
fecha factura+ g
num_pedido+ e PEDIDO(estado=por facturar)<num_pedido>
CLIENTE= d PEDIDO(num_pedido=:num_pedido).CLIENTE
< CIF+
nombre+
razn social+
calle+
nmero+
escalera+
puerta+
C.P.+
provincia > +
LINEAS= d PEDIDO(num_pedido=:num_pedido).LINEAS =
{ <referencia+ {<referencia
descripcin+ descripcin
cantidad cantidad_pedida
precio + precio_pedido>}
importe d cantidad*precio
> } LINEAS +
total d _ (cantidad*precio)
> FACTURA

La estructura anterior expresa que el usuario elige un pedido que est por facturar y los datos de
la factura se derivan de ste. Las elecciones de este tipo se describen con la expresin:
e CLASE (seleccin){<visualizacin>}<proyeccin>
El criterio de seleccin determina el dominio de instancias de la clase que se ofrecen para la
eleccin, la parte de visualizacin indica los atributos de esas instancias que se presentarn al
usuario y la proyeccin indica los campos que se derivan para la interfaz. En el momento de
disear la interfaz, estas selecciones dan lugar a ayudas de campo.
Obsrvese que, en los selectores, se ha prefijado con dos puntos los parmetros que hacen
referencia a campos de la interfaz; esto es especialmente til en casos en que se puede dar
ambigedad.
Cuando se utilizan la expresiones de derivacin para instanciar campos o estructuras es posible
que exista una posterior edicin de los valores instanciados. Aadimos una columna de edicin
para separar con nitidez la derivacin de la posible edicin del valor derivado.

FACTURA=
< num_factura+ g
fecha factura+ g
num_pedido+ e e PEDIDO(estado=por facturar)<num_pedido>
CLIENTE= d PEDIDO(num_pedido=:num_pedido).CLIENTE
< CIF+
nombre+
razn social+
calle+
nmero+
escalera+
erta+
Especificacin de sucesos
117
C.P.+
provincia > +
LINEAS= d PEDIDO(num_pedido=:num_pedido).LINEAS =
{ <referencia+ d {<referencia
descripcin+ d i descripcin
cantidad d cantidad_pedida
precio + d precio_pedido>}
importe d d cantidad*precio
> } LINEAS +
total d d _ (cantidad*precio)
> FACTURA
.4 .4 .4 .4 Derivacin de Iteraciones y agrupacin. Derivacin de Iteraciones y agrupacin. Derivacin de Iteraciones y agrupacin. Derivacin de Iteraciones y agrupacin.
La agrupacin es equivalente al uso de la clusula GROUP BY en SQL.
Una agrupacin es una operacin que a partir de un conjunto de instancias devuelve otro
conjunto de instancias mediante un cambio en la intencin de identificacin. El conjunto de las
personas, por ejemplo, puede considerarse desde dos pticas de identificacin. Una sera la
individual, la que podra interesar a efectos fiscales o legales, queremos conocer a cada
individualidad del conjunto. El identificador (el CIF, por ejemplo) determina un individuo nico y a
todas sus propiedades.
Otra sera la poblacional, ms frecuente en el mbito social, donde no interesa identificar a cada
individuo sino a poblaciones de ellos que presentan un conjunto de propiedades similares. Son
estas propiedades similares las que definen una relacin cociente en el conjunto de las personas.
El identificador se convierte en un identificador de poblaciones y de las caractersticas comunes a
los individuos que las forman.
Cualquier conjunto de individuos puede convertirse en un conjunto de poblaciones mediante una
agregacin, o agrupacin, entorno a una o ms propiedades.
Por ejemplo, sea el conjunto de las personas identificadas mediante el dni. Al agrupar este
conjunto por provincia tenemos una representacin de las personas de cada provincia. Las
personas pierden su identificacin individual y pasan a tener identificacin poblacional. Podemos
saber cuantas personas hay en cada provincia, cuantas personas tienen cada edad o cuntas
personas hay en cada provincia con cada edad.
Una agrupacin se define a partir de una clase bsica, un criterio cociente y un criterio de
proyeccin.
La clase bsica est caracterizada por sus atributos, sus identificadores y sus instancias.
Por ejemplo la clase bsica:
Personas{<dni+nombre+apellidos+ provincia+poblacin+edad>}
Como la clase ya ha sido definida con anterioridad, no necesitamos presentar sus
atributos en la expresin de derivacin. S se indicar mediante selectores los posibles
criterios de seleccin a aplicar sobre el conjunto de instancias de la clase base.
El criterio cociente define el cambio en el punto de vista de identificacin. Por ejemplo:
<provincia+edad>.
Las propiedades del criterio cociente, o propiedades cocientes, pertenecen forzosamente
al conjunto de propiedades de la clase bsica. El resto de propiedades de la clase bsica
las denominaremos propiedades no cocientes.
La operacin de agrupacin la representamos mediante una barra inclinada (como la
cocientacin en Teora de Conjuntos) y se parentiza con las llaves de iteracin porque
devuelve un conjunto de instancias:
{clase bsica / criterio cociente}

118
El criterio de proyeccin define las propiedades que nos interesa conocer de la
agrupacin; es la forma en que resumimos cada conjunto de instancias de las
propiedades no cocientes.
Es obvio que a cada valor <provincia+edad> le corresponder un conjunto de valores
nombre, apellidos, poblacin o dni. Es necesario elegir para cada una de estas
propiedades la operacin agregada que a partir de todas sus instancias nos devuelve un
nico valor. Tradicionalmente SQL utiliza las operaciones agregadas max, min, sum, avg o
count.
En el ejemplo siguiente las lneas de factura se obtienen seleccionando todas las lineas de pedido
del cliente para un determinado mes agrupndolas por referencia y precio.
Factura=
< Numero factura+ G
Fecha factura+ I
Mes de facturacin+ I
CLIENTE(cif )= I
< nombre+
domicilio+
poblacin >+
LINEAS DE FACTURA= d { PEDIDO(CIF=cif y fecha_pedido.mes=Mes de facturacin).LINEAS /
<referencia+precio> }=
{<referencia+ {<referencia+
descripcin+ descripcin+
precio+ Precio+
cantidad facturada + suma(cantidad) >}
importe > } d Precio* cantidad facturada
> Factura

La expresin de agrupacin no tiene en cuenta descripcin. Desde el punto de vista conceptual
sera necesario indicar que una referencia determina un nico valor de descripcin y se
sobreentiende que por tanto la agrupacin no afecta a la descripcin. Pero si se piensa en el
mbito del diseo o de la construccin, en el lenguaje SQL, es necesario garantizar el valor nico
de la descripcin. Podemos asumir una regla implcita estableciendo que, a los campos que no
figuran en el criterio cociente pero s en el criterio de proyeccin, se les aplica una funcin
agregada por defecto.
.5 .5 .5 .5 Iteraciones derivadas con multiseleccin Iteraciones derivadas con multiseleccin Iteraciones derivadas con multiseleccin Iteraciones derivadas con multiseleccin
Otra funcionalidad de derivacin editorial es la multiseleccin. La multiseleccin permite elegir,
manualmente, un subconjunto de un conjunto derivado. La M MM Multiseleccin permite un M MM Marcado
de los elementos de un conjunto de iteracin que se requieren para una determinada funcin.
Por ejemplo, supongamos que queremos indicar que una factura se realiza a partir de los datos
que se almacenaron en el pedido correspondiente.
Factura=
< Nfac+ G
Fecha_factura+ G
segn pedido+ e Pedido( )
CLIENTE= d Pedido(segn pedido).CLIENTE
< CIF+
nombre+
Razn social+
calle+
Nmero+
Escalera+
puerta+
C.P.+
Provincia >> +
Especificacin de sucesos
119
LINEAS= M Pedido(segn pedido).LINEAS =
{ <referencia+ {<referencia
Descripcin+ Descripcin
Cantidad Cantidad_pedida
Precio + Precio_pedido>}
Importe d Cantidad*Precio
> } LINEAS +
Total d _ (Cantidad*Precio)
> PEDIDO

En este caso el usuario elige las lneas que se incluirn en la factura a partir del conjunto derivado.
Especificacin de sucesos
121
6.4.4 Especializacin Especializacin Especializacin Especializacin
El uso de estructuras de especializacin en formularios indica la existencia de variedades
estructurales excluyentes. Cada variedad estructural recoge diferentes campos que debern ser
cumplimentados segn el caso.
Normalmente aparecen campos cuyo valor puede determinar el uso de una u otra variedad
estructural. En este caso podemos hablar de indicadores de especializacin. Un indicador de
especializacin es un campo de un formulario cuyos valores determinan el uso de una u otra
variedad estructural. Por ejemplo, supongamos que un proyecto puede ser interno o externo.
Tendramos un campo del formulario Tipo de proyecto cuyos valores posibles seran
[interno|externo]. En el caso de que fuera interno en el formulario se indicar el Departamento
que lo realizar. En el caso de que sea externo en el formulario se indicar el CIF y la razn social
de la empresa adjudicataria.
La persona que cumplimente el formulario deber indicar la opcin deseada y segn la opcin
cumplimentar los campos adecuados.
En la estructura de adquisicin el indicador de especializacin se asocia a una operacin de
captura de eleccin.
< . . . +
Tipo de proyecto+ e [interno|externo]
REALIZACIN=
[ INTERNA= Tipo de proyecto=interno
< Departamento > i
| EXTERNA= Tipo de proyecto=externo
< cif+ i
Razn Social > i
]
>
Cada una de las variantes estructurales (INTERNA, EXTERNA) lleva asociada una condicin que se
vincula al indicador de especializacin.
Es posible tambin que en un formulario aparezcan variantes estructurales sin que exista un
indicador de especializacin nominal. Por ejemplo supongamos que en funcin del valor de un
campo es necesario cumplimentar de modo diferente el formulario.
< . . . +
importe+ i
[ Obra mayor= importe > 100 & importe < 200
<coeficiente de extrusin+ i
tasas de consolidacin>+ i
| Obra doiro= importe >= 200
< plazo reposicin+ i
retorno de freseles > i
] +
>
Obsrvese que se ha omitido el nombre de la estructura que contiene las diferentes variantes
estructurales.
Las estructuras opcionales se tratan como variantes con una sola opcin.
< . . . +
importe+ i
[ Obra mayor= importe > 100
<coeficiente de extrusin+ i
tasas de consolidacin>+ i
] +
>

122
Las condiciones de especializacin pueden afectar no solo a las estructuras sino tambin a los
dominios asociados a cada campo.
Cada comercial slo podr vender artculos asignados a su departamento. En este caso el
dominio en el que se pueden seleccionar artculos estar especializado segn las asignaciones a
departamentos existentes.
En este caso es conveniente asociar una funcin de especializacin al dominio.
Requisitos de uso
123
7 77 7- -- - Suces Suces Suces Sucesos y estado os y estado os y estado os y estado
7.1.1 Sucesos y Objetos Sucesos y Objetos Sucesos y Objetos Sucesos y Objetos
El mundo que nos rodea en la, aparentemente, constituido por una amalgama de fenmenos
dinmicos y continuos. Lo expresaron los filsofos presocrticos. El mundo est en continuo
cambio. Por contra las concepciones que elaboramos del mundo son estticas y discontinuas.
Sucesos y objetos son los dos mecanismos de categorizacin conceptual de nuestras percepciones
que reflejan la discontinuidad y el estatismo. Concebimos como objetos aquellos fenmenos en
los que no apreciamos cambios sustanciales. Concebimos como sucesos ciertas discontinuidades
que suponen cambios en el estado de las cosas.
La categorizacin de conceptos est basada, segn la mayora de expertos, en los eventos. Parar
Barsalou [Barsalou 1998] la categorizacin de conceptos se basa tanto en objetos como en
eventos:
it is not surprising that the cognitive system categorizes on the basis of both
individuals and events. If the cognitive system didnt establish representations of
individuals that exist across events, it couldnt construct the history of an individual, it
couldnt represent the fact that the appearance of an individual might vary widely
across occasions, it couldnt count the number of repeating individuals observed across
occasions, and it couldnt determine the properties that occur most often across the
individuals in a category.
In contrast, if the cognitive system didnt record information about events, it couldnt
distinguish individuals that occur frequently in a category from individuals that occur
rarely. Similarly, it couldn't distinguish the frequent properties of an individual from the
infrequent ones.
Tradicionalmente, en informtica, se habla de esttica y dinmica. Pero el trmino dinmica tiene
un significado particular. Nuestras percepciones de fenmenos tienden a conceptos estticos, los
objetos o individuos, o a conceptos dinmicos discretos, los eventos. Un evento es la percepcin
Dynamic "things" must not be confused with
static descriptions of their results.
Wolgfang Hesse


124
de una alteracin en un fenmeno observado. No tenemos la capacidad de concebir una
dinmica continua. Concebimos estados y cambios perceptibles. Toda nuestra cultura se llena de
eventos simblicos que rompen la continuidad. Fijamos arbitrariamente los principios de ao o
ciertas fechas sealadas que marcan de forma eventual el principio o fin de procesos dinmicos
continuos o una frontera arbitraria en un cambio gradual. Todas nuestras formas de medida no
son sino formas de discretizar, o cuantificar, fenmenos.
En esa discretizacin utilizamos propiedades que actan como sntomas del proceso continuo.
Aceptamos la temperatura y la humedad relativa como una descripcin de un proceso
climatolgico altamente complejo. Basta una indicacin de esas dos magnitudes para que nuestro
cerebro presuma un escenario complejo tropical, desrtico o polar.
La segunda de nuestras peculiaridades cognitivas es la necesidad de identificacin. Probablemente
fruto de la discretizacin, nuestra mente parece compelida a identificar cada uno de los objetos o
de los eventos que percibe y clasifica.
Los fenmenos son complejos. En los fenmenos percibimos propiedades que agrupamos en
forma de objetos. La composicin de objetos y propiedades es una forma de ver o intuir los
fenmenos.
En realidad consideramos un fenmeno como un entorno dinmico en el que somos capaces de
percibir objetos relacionados. Percibimos que existen patrones de relaciones entre objetos que se
repiten en el tiempo con ciertas analogas. Esa percepcin es nuestra intuicin de los fenmenos.
No sabemos si existe un nico fenmeno universal. Creemos que existen diferentes fenmenos
que no se influyen o que estn dbilmente influidos.
Nuestra observacin se limita a aislar aquellas caractersticas relacionadas que pensamos que
describen un fenmeno. Nuestras limitaciones cognitivas se traducen en una fragmentacin
continua de fenmenos. En los fenmenos localizamos individuos, objetos.
Los fenmenos que percibimos no tienen una forma de identificacin preestablecida. Seguro que
existe un criterio de identificacin para cocodrilos. Otra cosa es que quien observa y describe sea
capaz de aplicarlo. Podemos identificar lo que somos capaces de distinguir. El observador de un
sistema busca propiedades que diferencien los fenmenos o, si carece de criterios slidos para
ello les asigna un identificador sintctico (un cdigo). El observador de cocodrilos puede decidir
describir los sucesos con cocodrilos mediante un nombre que asigna a cada uno. Suponemos que
el suceso Luis duerme en la orilla y Alberto se come una zarigeya se refieren a especmenes
diferentes, pero en realidad no tenemos certeza. Supongamos que a los cocodrilos se le puede
adosar un emisor con una frecuencia identificativa. Nuestra certeza depende de la tasa de error
del dispositivo de identificacin o de errores de interferencias. Parece ms fiable que la
identificacin experta.
Que los humanos no dispongamos de criterios de identificacin para los fenmenos no significa
que sean iguales. La confusin es nuestra no de los fenmenos. Existen multitud de fenmenos
para los que no tenemos identificacin. No tenemos la capacidad de identificar tomos, y mucho
menos partculas o subpartculas. No tenemos la capacidad de identificar masas. Tenemos serias
dificultades para identificar colores. Cuando decimos color rojo no identificamos un fenmeno
sino una clase de fenmenos. Sin embargo no somos capaces de tratar computacionalmente lo
que no podemos identificar.
Los sucesos presentan dos aspectos identificacin. Uno externo, cual es el identificador mediante
el cual diferenciamos una ocurrencia del suceso de las dems. Otro interno, cual es la
composicin de identificadores que refiere el suceso.
Si las representaciones que hacemos de estado se basan en relaciones de objetos identificables,
para que un suceso describa un cambio de estado necesita describir el estado que requiere y el
que genera. Tanto uno como otro puede ser una composicin de identificadores, es decir pueden
ser estados compuestos.
Si los sucesos son lo que se comunica al sistema y no somos capaces de distinguirlos no podemos
saber lo que ha ocurrido.
Requisitos de uso
125
El problema con la identificacin es que, si es insuficiente, alcanzamos la confusin de
fenmenos. Un ejemplo puede ser el de los sucesos de entrada y salida de existencias en almacn
entra(producto, cantidad) sale(producto, cantidad) frente al cual la respuesta del sistema sea
actualizar el stock del producto indicado. Es un suceso histrico, en el sentido freudiano de olvido.
Es un suceso cuya ocurrencia no podr ser identificada por el sistema. El problema es obviamente
que el suceso no tiene un criterio de identificacin ni puede tenerlo si no ampliamos sus
propiedades. Podremos saber las existencias que nos quedan pero no podemos recordar cunto
ha entrado y cunto ha salido.

7.1.2 Sucesos y Clases de Sucesos Sucesos y Clases de Sucesos Sucesos y Clases de Sucesos Sucesos y Clases de Sucesos
De igual manera que la perspectiva esttica diferencia entre clase e instancia (entidades,
objetos...) en la perspectiva dinmica tambin debemos hacerlo.
Lo que el analista describe son clases de sucesos. Cada clase de sucesos tiene asociada una
poblacin de instancias. Denominaremos ocurrencias a las posibles instancias de una clase de
sucesos.
Por definicin las ocurrencias de una clase de sucesos siempre pueden acaecer de forma
concurrente. Por ejemplo Un socio solicita darse de alta denota una clase de sucesos cuyas
instancias siempre pueden concebirse como concurrentes. Cualquier par de clientes pueden llegar
al mismo tiempo y solicitar ser socios.
El aspecto opuesto es la serializacin. Existen instancias de sucesos que deben ocurrir en un cierto
orden y nunca de forma paralela.
Recurdese una de las caractersticas de los sucesos: La ocurrencia de un suceso necesita conocer
la ocurrencia previa de otros sucesos.
Para que pueda ocurrir un suceso de la clase El socio solicita una cinta en prstamo deben
haber tenido lugar previamente dos ocurrencias de suceso. Una de la clase Un socio solicita
darse de alta y otra de la clase Recibir pedido de distribuidora.
Los sucesos constructores generan estados particulares en el sistema. Cuando decimos que la
ocurrencia de un suceso necesita conocer la ocurrencia previa de otros sucesos nos referimos a
que todo suceso puede necesitar referirse a estados previamente generados por otras clases de
sucesos.
Podemos por tanto vincular y ordenar clases de sucesos si sabemos que existen relaciones de
precedencia temporal entre las instancias generadas por ellos. Cuando en un diagrama de sucesos
relacionamos dos sucesos A y B estamos expresando que una instancia u ocurrencia de la clase B
necesita la existencia previa de al menos una ocurrencia de la clase A.
7.1.3 Sucesos y estados Sucesos y estados Sucesos y estados Sucesos y estados
Todo suceso constructor es un generador o modificador de estados. La complejidad de un suceso
depende de la complejidad del estado asociado. En principio el concepto ms bsico de estado
estara asociado al concepto de identificador, sea de una entidad, de un objeto o de una relacin.
El menor estado que podemos generar aparece al incorporar un nuevo identificador al sistema
con sus propiedades asociadas es una instancia de una clase simple. Por ejemplo un cif de un
cliente junto con las propiedades que lo caractericen.
Pero siempre existirn sucesos que generen un estado complejo en el que aparecern diferentes
identificadores relacionados. Cada uno de ellos tendr sus propiedades asociadas.
Un suceso Tomar Pedido incorpora una instancia de la clase cabecera de pedido (es decir un
identificador de la clase cabecera de pedido junto con otras propiedades determinadas por l) y

126
varias instancias de la clase lnea de pedido (es decir varios identificadores de la clase lnea de
pedido relacionados cada uno de ellos con el identificador de pedido y con las propiedades que
los caracterizan).
Las relaciones temporales entre sucesos definen relaciones entre los estados generados por cada
uno de ellos.
Sea el esquema de sucesos de la figura.

Figura 65 Relaciones entre sucesos
El suceso 1 Alta Socio genera instancias de la clase Socio. El Suceso 2 Alta Huertos
genera instancias de la clase Huerto.
Si los sucesos estn relacionados tambin lo estarn los estados resultantes.
7.1.4 Relaciones d Relaciones d Relaciones d Relaciones de Cardinalidad e Cardinalidad e Cardinalidad e Cardinalidad
Siguiendo con el ejemplo anterior podemos decir que la cardinalidad entre estos dos sucesos es 1-
N.
Con ello estamos expresando que cualquier ocurrencia de alta socio podr relacionarse con
mltiples ocurrencias de la clase Alta huertos. Por el contrario toda ocurrencia de la clase Alta
huertos slo se relaciona con una sola ocurrencia de la clase Alta Socio.

Figura 66 Relaciones de cardinalidad entre sucesos
Obviamente el estado generado por el suceso 1 Alta socio tiene una relacin 1-N con el estado
generado por el suceso 2 Alta huertos.


Figura 67 Estado generado por un comportamiento
Requisitos de uso
127
Cuando tratamos con estados complejos las relaciones de cardinalidad pueden ser confusas. Es
necesario comprender la estructura de identificadores para que la relacin de cardinalidad sea
significativa.
En la figura siguiente se muestra un patrn de secuencia de sucesos con cardinalidad 1-1,

Figura 68 Clases sucesivas y cardinalidad.
En esta secuencia aparece un primer suceso 8 La Editorial solicita una exclusiva. Una vez se
atiende la solicitud se busca un fotgrafo que pueda realizarla. Cuando se conoce qu fotgrafo
quiere realizarla se le asigna mediante el suceso 9 Fotgrafo solicita asignacin de exclusiva. Por
ltimo, cuando el fotgrafo ha realizado la exclusiva, la entrega en la agencia provocando el
suceso 10 Fotgrafo finaliza exclusiva.
Cada ocurrencia de una clase slo se relaciona con una ocurrencia de la siguiente. Una exclusiva
slo se asignar a un fotgrafo pero adems una asignacin se refiere a una nica solicitud de
exclusiva.
Este patrn es tpico de las clases sucesivas. Toda la secuencia afecta a un mismo y nico
identificador de estado u objeto.
El primer suceso de la secuencia es un generador de estado (crea el identificador de exclusiva con
sus propiedades asociadas). Los siguientes son modificadores esenciales de estado. Se limitan a
aadir nuevas propiedades a un identificador existente. Desde el punto de vista del estado pueden
tratarse como especializaciones.
7.1.5 Diagramas de sucesos y diagramas de estados Diagramas de sucesos y diagramas de estados Diagramas de sucesos y diagramas de estados Diagramas de sucesos y diagramas de estados
Las relaciones que aparecen en los diagramas de comportamiento deben preservarse en los
diagramas de estados desde dos puntos de vista: la cardinalidad y la temporalidad.
Los diagramas de estados (de entidades u objetos) siempre contienen de forma implcita
informacin de temporalidad.
La informacin de temporalidad es informacin dinmica. Por ejemplo, en un diagrama ER una
relacin ya nos est diciendo implcitamente que para construir una instancia de relacin es
necesario construir primero las instancias de las entidades participantes.

128

Figura 69 Relacin temporalmente posterior" a las entidades.
Esta es una informacin dinmica en el sentido de requerir tres encapsulamientos dinmicos
diferentes. El suceso que genera instancias de A, el que genera instancias de B y el que genera
instancias de R.
Los diagramas ER utilizan el concepto de restriccin de existencia (o de cardinalidad mnima) para
anular esta informacin implcita.
Si manifestamos que la entidad B tiene una restriccin de existencia respecto a la relacin
indicamos que no existe ninguna instancia de B que no est vinculada a una instancia de R. Esta
forma de expresarlo es sesgadamente esttica.

Figura 70 Relacin temporalmente coexistente" con una entidad.
Existe otra manera de expresarlo con sesgo dinmico. El diagrama anterior requiere dos sucesos
constructores. Uno para generar instancias de A y otro para generar instancias de B
relacionndolas con instancias de A.
Podemos considerar sobre un diagrama ER las clases de equivalencia inducidas por la relacin ser
generado por el mismo suceso. Para el ejemplo considerado obtendramos diferentes
encapsulamientos de sucesos:

Figura 71 Sucesos y estados
La preservacin del orden implcito en el concepto de relacin exige que el esquema de
comportamiento refleje un orden parcial de sucesos de la forma siguiente:

Figura 72 Comportamiento equivalente".
Requisitos de uso
129
En el caso de existir restricciones de existencia la complementariedad sucesos/estados nos lleva a
las siguientes relaciones:

Figura 73 Sucesos y estados
Ntese que la preservacin de comportamiento exige que las ocurrencias del suceso A precedan
temporalmente a las del Suceso R-B relacionadas.
En [Casamayor 1994] se propone una tcnica para inferir transacciones a partir de estas clases de
equivalencia inducidas por las restricciones de existencia.
Como se argument en el apartado de comportamiento, cada suceso debe presentar como
interfaz de comportamiento a los dems sucesos las diferentes modalidades de estado que
genera, lo que incluye las modalidades de especializacin.
7.1.6 Especializacin de Especializacin de Especializacin de Especializacin de comportamiento y estado. comportamiento y estado. comportamiento y estado. comportamiento y estado.
Las relaciones de especializacin entre los estados del sistema se pueden deducir del
comportamiento externo.

Figura 7+ Especializacin de comportamiento y estado
La deteccin de patrones de comportamiento con cardinalidad 1-1, presenta
comportamiento de especializacin sucesiva.
.1 .1 .1 .1 Composicin de identificadores Composicin de identificadores Composicin de identificadores Composicin de identificadores
El anlisis de estado es, en definitiva, un anlisis de identificadores. La diversidad de identificacin
surge de forma externa, a travs de la cardinalidad de sucesos, o de forma interna estudiando las
relaciones de composicin de las estructuras comunicadas en cada acontecimiento.
En la figura siguiente el suceso 6 Editorial solicita reportaje genera un estado complejo compuesto
por diferentes formas de identificacin.

130

Figura 75 Composicin de identificacin

Requisitos de uso
131
8 88 8- -- - Requisitos de uso Requisitos de uso Requisitos de uso Requisitos de uso
8.1 LOS SUCESOS EN EL ENTORNO DE USO
Suponga que usted acude al servicio de correos para poner un telegrama. Lo primero que tiene
que hacer es localizar dnde puede realizar esta gestin. Posiblemente deba usted adems
proveerse del formulario correspondiente.
Una vez haya localizado el entorno adecuado es posible que requiera usted ciertas informaciones
previas que podran afectar a la forma o al contenido de su mensaje. Por ejemplo la lista de
precios. Imagnese que los precios van por bloques de palabras. Usted intentar maximizar el uso
del bloque.
Comenzar un proceso editorial en el que usted participar como aportador de informacin
escribiendo el mensaje en el formulario previsto para ello.
El proceso editorial continuar con la colaboracin de alguna persona de correos que proceder a
un cambio de formato introduciendo el texto que usted le proporcion mediante un teclado en
algn artefacto especfico.
Esta persona realizar ciertas validaciones. Comprobar, por ejemplo, que la poblacin a la que
usted quiere enviar su mensaje existe o que el pas al que usted pretende enviarlo dispone de
servicio telegrfico.
Calcular el importe contando las palabras y aplicando la tarifa correspondiente. Registrar en
algn soporte los datos que la organizacin de correos considere necesarios. Probablemente
registre los datos del emisor, del receptor, el importe cobrado, la fecha y da de la operacin.
Por ltimo emitir un recibo y una copia del mensaje enviado que le sern entregados para
acreditar la operacin.
La serie de actividades descritas en este ejemplo son habituales en cualquier interaccin de un
sistema de informacin; independientemente de los tipos soportes.


132

Figura 1 Nodelo de uso.
Como vemos en el ejemplo anterior, la descripcin de sucesos tiene dos mbitos descriptivos: los
requisitos del dominio del problema y los requisitos del entorno de uso.
Cuando nos movemos en el mbito del problema la cuestin se centra en identificar las
interacciones, los mensajes asociados y la reaccin del sistema frente a esos mensajes.
Cuando trabajamos en el mbito de la solucin la cuestin se centra en ofrecer un soporte
eficiente a la comunicacin. Pero podemos observar que aparecen requisitos que en el domino del
problema, en el modelo del negocio, ni se plantean. Cmo encuentra un usuario de mi servicio la
ventanilla adecuada? Cuantos recursos son necesarios para cumplimentar un cuestionario? El
entorno de uso incorpora aspectos pragmticos que en el entorno del negocio resultan
accesorios.
Una de las principales caractersticas del entorno de uso es facilitar la edicin de los mensajes.
Hasta tal punto que una interfaz puede considerarse un mero editor de estructuras. De hecho es
lo que el usuario percibe. El usuario no desencadena sucesos sino ms bien procesos editoriales
que permiten construir mensajes que se comunican al sistema. La mayor parte del tiempo que un
usuario pasa ante una interfaz la dedica a la edicin. Por ello el concepto base de nuestra
aproximacin es el co co co contexto editorial ntexto editorial ntexto editorial ntexto editorial.
Un contexto editorial identifica un editor de estructuras para uno o ms sucesos de usuario.
Cuando un contexto editorial se utiliza para varios sucesos de usuario es porque existe
compatibilidad estructural entre ellos. El caso ms tpico de un contexto editorial es la agrupacin
de los sucesos de alta, consulta, modificacin y borrado para una clase.
De forma general consideraremos que los requisitos del entorno de uso tienen que ver con los
tres aspectos siguientes:
Soporte a la localizacin de objetos y sucesos: el usuario debe localizar la clase de
suceso que necesita invocar dependiendo del tipo de mensaje que quiere comunicar (hay un
Requisitos de uso
133
nuevo cliente") o localizar instancias de objetos para luego aplicarle alguna funcin (localizar
al cliente Kaplan S.L."). En realidad el usuario localiza el contexto editorial que le permite
editar el mensaje y, una vez construido, comunicarlo al sistema.
Soporte a la edicin del mensaje: supone visualizar e introducir la informacin asociada a
la funcin seleccionada (suceso). En ocasiones este punto conlleva una edicin intensiva de
los datos y, por lo tanto, el usuario requiere de una bateria de funciones editoriales que le
ayuden en la tarea; en este proceso el sistema y el usuario se intercambian numerosos
mensajes.
Disparo de la funcin de negocio: el usuario indica que ha finalizado la edicin de los
datos para disparar la comunicacin efectiva del mensaje provocando la reaccin del sistema.
8.2 SOPORTE A LA LOCALIZACIN.
8.2.1 Localizacin de clases de fu Localizacin de clases de fu Localizacin de clases de fu Localizacin de clases de funciones. nciones. nciones. nciones.
La complejidad nos lleva a dividir y estructurar un sistema en partes relacionadas, con frecuencia
de modo jerrquico. A travs de las relaciones establecidas podremos localizar la parte que nos
interese.
Desde hace tiempo se plantean dos formas bsicas de organizacin de funciones en las interfaces
de usuario. Se conocen bajo la designacin de objetos-acciones o acciones-objetos. En cada
una de ellas se da prioridad a la localizacin por clases de funciones o por clases de objetos.
La primera actividad cuando pasamos del modelo de negocio al modelo de uso consiste en la
definicin de la arquitectura de invocacin de sucesos de usuario. Esto se realiza mediante la
navegacin explcita o taxonmica. Esta navegacin es la que permite crear la organizacin de
clases de funciones segn los criterios elegidos. Se basa en el uso de enlaces o invocaciones
explcitas a diferentes contextos de una aplicacin. Se denomina taxonmica porque la forma de
enlazar define de forma explcita la taxonoma o modelo organizativo de los sucesos de usuario.
La navegacin explcita o taxonmica est asociada a la localizacin del entorno de proceso de
una determinada funcin o suceso.
La navegacin explcita resuelve la localizacin de clases de sucesos. Una jerarqua de mens es
una organizacin de funciones basada en navegacin taxonmica.
En el caso de soportes nada o dbilmente informatizados corresponde a la bsqueda que se debe
realizar para encontrar el entorno de proceso adecuado; lo que puede suponer el hacer cola en la
ventanilla de informacin o consultar la informacin de un directorio para encontrar la ubicacin
correcta.
Si la organizacin dispone de una web que permita esos trmites usted deber navegar por la
web hasta localizar el formulario correspondiente.
.1 .1 .1 .1 Organizaciones de sucesos. Organizaciones de sucesos. Organizaciones de sucesos. Organizaciones de sucesos.
En la fase de captura de requisitos las composiciones temporales de sucesos resultan adecuadas
porque facilitan la exhaustividad. Es ms fcil para los usuarios ir narrando los pasos que siguen
para completar un proceso de negocio que enumerar todas las funciones que realizan. E igual
ocurre a la hora de validar. Es ms fcil para los usuarios detectar que han olvidado una etapa en
una secuencia de sucesos que detectar que en una lista de sucesos falta alguno.

134
En el entorno de uso los sucesos representados deben ser fcilmente localizados por los usuarios y
para ello ya no se usan organizaciones temporales sino espaciales. En las formas espaciales los
sucesos se pueden agrupar por diferentes criterios
porque son realizados por un determinado departamento o persona
porque afectan a un tipo de objeto determinado
porque se usan para un proceso funcional dado
porque as lo decide el usuario
El catlogo de sucesos que se ha ido obteniendo a partir de los sucesos de negocio debe
ampliarse con los sucesos de mantenimiento que derivan del catlogo de requisitos de datos y del
diagrama de clases de anlisis.
.2 .2 .2 .2 Reorganizacin de sucesos. Reorganizacin de sucesos. Reorganizacin de sucesos. Reorganizacin de sucesos.
Los sucesos catalogados durante el anlisis del modelo de negocio deben agruparse en contextos
segn criterios de localizacin que convengan a los usuarios. La reorganizacin de sucesos
preconfigura el contenido de los contextos editoriales contextos editoriales contextos editoriales contextos editoriales que se ir completando paulatinamente a
lo largo del proceso.
Para la reorganizacin de sucesos el analista cuenta con abundante informacin del usuario. Una
primera propuesta de organizacin del analista considerar la organizacin objetual y los sucesos
vinculados que son las dos formas ms frecuentes de contextualizacin.
Los requisitos de localizacin incorporan los siguientes aspectos:
La relacin de contextos: que contendr cada uno de los contextos editoriales con la lista de
los sucesos que comprende. Los contextos editoriales pueden describirse utilizando la
notacin propuesta en el captulo I.1 .
{Contexto editorial=
< Nombre del contexto+
Descripcin+
Formulario asociado+
{ Sucesos de negocio) +
> ) Contexto editorial
Figura 2 Netamodelo de los contextos editoriales.
El mapa de accesibilidad: que describe la organizacin y acceso a cada uno de los contextos.
Habitualmente ser un rbol como el utilizado para los mapas de un sitio web.

Requisitos de uso
135

Figura 3 Ejemplo de relacin de contextos.
8.2.2 Localizacin de instancias de objetos Localizacin de instancias de objetos Localizacin de instancias de objetos Localizacin de instancias de objetos
La localizacin de instancias de objetos tiene que ver con facilitar al usuario el acceso a las
instancias que debe tratar. Esto conduce a una suerte de navegacin diferente a la taxonmica. La
navegacin estructural se basa en utilizar la estructura de la memoria del sistema para la
localizacin de instancias de objetos.
La localizacin de instancias de objetos est relacionada con aquellos sucesos que suponen la
modificacin o borrado de objetos existentes. Por ejemplo el cambio de domicilio de un cliente.
Pero tambin tiene que ver con funciones asociadas a la creacin de objetos relacionados o
dependientes de otros. Por ejemplo el alta de un pedido de un determinado cliente.
Desde el punto de vista de la interfaz la navegacin estructural se materializa en estructuras de
interfaz asociadas a clases del modelo de datos y a sus relaciones.
La localizacin de instancias est ntimamente asociada al soporte editorial.
8.3 SOPORTE EDITORIAL
Un contexto editorial est formado por diferentes formularios que contienen funcionalidades de
soporte editorial. Las funcionalidades de soporte editorial pueden adscribirse a actividades de
localizacin, derivacin, edicin o a servicios asociados a cada una de ellas.
Localizacin de instancias de objetos:
Habitualmente un contexto editorial suele tener asociado un localizador de instancias de
objetos. Este localizador se define mediante una estructura que el usuario puede navegar con
los cursores o con disparos de funciones de recorrido. Los localizadores navegables estn
asociados a conjuntos de instancias de una clase derivada. Como conjuntos es posible

136
asociarle servicios de soporte a la localizacin: filtros, bsquedas, ordenacin. Estos servicios
pueden requerir el uso de formularios separados.
Derivacin estructural
La derivacin estructural permite iniciar la estructura de adquisicin de un suceso. En los
casos ms complejos puede solucionarse en formularios separados. Sobre todo si las
derivacin estructural es asistida y necesita la intervencin del usuario. Los formularios de
derivacin estructural son muy similares a los localizadores de instancias. Un localizador
permite acceder a un objeto nico. La derivacin estructural permite componer estructuras de
iteracin compleja. Obviamente la composicin requiere utilizar el acceso a cada objeto
constituyente.
La derivacin estructural puede requerir servicios de soporte similares a los de la localizacin.
Edicin
La funcionalidad de edicin es la ms evidente de una interfaz. Las estructuras de adquisicin
permiten indicar caractersticas editoriales. Pero es posible que en el entorno de uso
aparezcan funciones de soporte editorial que en el dominio del problema no surgieron. Por
ejemplo una funcin que duplique lineas de pedido para facilitar la insercin de nuevas lineas
similares a las existentes. Funcionalidad para iniciar determinados campos con el valor ms
frecuente. Funcionalidad para recordar el ltimo valor introducido.

8.3.1 Compatibilidad editorial: Contextos editoriales. Compatibilidad editorial: Contextos editoriales. Compatibilidad editorial: Contextos editoriales. Compatibilidad editorial: Contextos editoriales.
En el diseo de la interfaz que soporte los sucesos de usuario es posible aplicar reutilizacin.
Cuando sea posible, se resolvern dos o ms sucesos de usuario en lo que llamamos un contexto
editorial, de modo que se estar (re)utilizando un mismo conjunto de elementos de interfaz para
soportar la edicin de varios sucesos de usuario.
Dados dos sucesos de usuario, decimos que son editorialmente compatibles si sus estructuras de
adquisicin permiten la reusabilidad estructural; es decir, si la edicin necesaria para construir los
mensajes asociados a ambos sucesos (definidos en sus estructuras de adquisicin) tiene las
suficientes semejanzas como para poder ser soportada por la misma composicin de estructuras
de interfaz. Cuantas menos modificaciones sea necesario realizar en las estructuras de interfaz
entre su uso para un suceso y su uso para el otro, mayor ser la compatibilidad editorial de los
sucesos.
Un contexto editorial contexto editorial contexto editorial contexto editorial es un conjunto relacionado de estructuras de interfaz que dan soporte a un
conjunto de sucesos de usuario editorialmente compatibles. Un contexto editorial debe ser capaz
de presentar tantas variedades editoriales como funciones de usuario compatibles ofrezca.
Por ejemplo los sucesos de alta de un cliente, consulta de un cliente y modificacin de un cliente
tienen estructuras de adquisicin semejantes y, por lo tanto, son editorialmente compatibles; es
habitual la reutilizacin de las mismas componentes de interfaz para los tres sucesos. Diremos en
tal caso que los estamos resolviendo en un mismo contexto editorial. Este contexto presentar al
menos tres variedades editoriales, que darn lugar a diferentes modos de uso del contexto: el
modo alta, el modo consulta y el modo modificacin.
Cuando el proceso editorial asociado a un suceso de usuario es complejo, es habitual que se
descomponga en objetivos editoriales objetivos editoriales objetivos editoriales objetivos editoriales intermedios, asociados a sucesos de diseo. Los sucesos
de diseo no deben confundirse con sucesos de usuario, surgen de un refinamiento de stos para
hacer ms asequible la construccin del mensaje asociado.
Para describir un contexto editorial se especifican las siguientes propiedades.
1. Objetivos editoriales.
2. Sucesos de usuario de anlisis a los que se da soporte editorial.
Requisitos de uso
137
3. Sucesos de usuario de diseo, los cuales surgen por necesidades editoriales (almacenar
estados intermedios de la edicin de un formulario) o por necesidades de funciones
sobrevenidas de diseo (parametrizaciones de usuario, recuperaciones de histricos, etc.)
4. Sucesos de usuario accesibles. Los sucesos de usuario accesibles son aqullos cuyo
contexto de edicin se especifica separadamente pero que el usuario requiere que se
localicen asociados al contexto que se define. Estos sucesos pueden tener incluso
estructuras de adquisicin relacionadas con el contexto actual, pero por cualquier criterio
la especificacin y construccin se hace de forma separada (p.ej. los consultores
vinculados). Desde los formularios que concreten el contexto actual, se podr navegar a
los que soporten los sucesos accesibles.
5. Funciones editoriales. Ya sean disparadas por un suceso de usuario de diseo, o bien
disparadas internamente por la aplicacin, son en realidad requisitos solicitados por los
usuarios pero que se entienden como objetivos secundarios.
Requisitos de uso
139
9-Tcnicas de obtencin de informacin
141
9 99 9- -- - Tcnicas de obtencin de informacin Tcnicas de obtencin de informacin Tcnicas de obtencin de informacin Tcnicas de obtencin de informacin
9.1 ACTORES
La palabra stakeholders ha remplazado al trmino users. Encontrar una traduccin plausible para
stakeholders no es tarea fcil. Utilizar el trmino castellano actores para indicar todas aquellas
personas que forman parte de un problema o tienen que ver con su solucin.
9.2 FUENTES DE INFORMACIN.
La principal fuente de informacin para el anlisis de sistemas de informacin son los actores del
sistema. Pero tambin tenemos otras fuentes de informacin como la documentacin de la
organizacin, la legislacin u otros sistemas existentes con funcionalidad similar.
Los documentos organizacionales pueden ser de dos tipos.
Uno sera el constituido por los documentos bsicos usados en la operacin diaria como fichas de
clientes, pedidos, albaranes etc. Estos documentos son tiles para el anlisis de datos y en
permiten tambin establecer un seguimiento de sucesos asociados.
Otro sera la documentacin que la organizacin haya confeccionado sobre s misma. Es posible
que la organizacin disponga de manuales de procedimientos o que tenga una certificacin de
calidad. Estas fuentes son muy adecuadas para el anlisis de procesos.
El problema de los documentos organizacionales es que pueden estar desfasados. Incluso los
formatos de los formularios pueden ser inadecuados y el uso que se hace de ellos es ms rico que
el que muestra la estructura del formulario.


La mayora de tcnicas de obtencin de informacin requiere la participacin del usuario porque
es el que finalmente mostrar o no su satisfaccin con el sistema de informacin diseado.
9.3 ENTREVISTAS.
La entrevista es un encuentro planificado entre usuarios y analistas para identificar fuentes de
informacin u obtener requisitos.
9.3.1 Consideraciones generales sobre las entrevistas Consideraciones generales sobre las entrevistas Consideraciones generales sobre las entrevistas Consideraciones generales sobre las entrevistas
Los diferentes manuales que tratan el tema de las entrevistas consideran aspectos relativos al
entrevistador y al entrevistado.
El entrevistador debe tener, segn Silvia Royo apariencia agradable, modales corteses, simpata y
facilidad de palabra. Agilidad y flexibilidad mental. Facilidad para entrar en contacto con la gente.
Buenas dotes de observacin y sentido del detalle. Buena memoria. Capacidad de sntesis. La
descripcin es para entrevistadores de cuestionario. Es decir que llevan un guin de actuacin y
no es preciso que sean expertos en la materia sobre la que preguntan. Sin duda las caractersticas
que apunta son deseables para un ingeniero de requisitos.
Como muchas recomendaciones de las entrevistas provienen de la prctica mdica o del campo
de la psicologa el entrevistado aparece como dbil ante el entrevistador. Probablemente
responde a esa deformacin profesional que lleva a la dualidad sano/enfermo. Esa actitud, que
tambin aparece entre los informticos pero con la dualidad ignorante/sabio, conduce a
recomendaciones como las siguientes:
Realizar la entrevista en terreno del entrevistado. Acercarse al sujeto: recibirlo en casa.
Situar cmodamente al sujeto. Ponerse a cubierto de indiscreciones y testigos.
Minimizar la toma de notas porque intimida al entrevistado.
Evitar los silencios porque son intimidatorios.
No se debe experimentar asombro ante ninguna respuesta.

La primera cuestin es que cualquier entrevistado puede tener dotes sociales, intelectuales y
personales superiores al entrevistador. En muchos casos es posible que el que necesite
tranquilidad y sosiego sea el entrevistador.
Algunos manuales anglosajones de anlisis y consultora tambin consideran el temor del
entrevistado. Esto es posible si el entrevistado cree que el objetivo de las entrevistas es remplazar
personas por artefactos y puede acabar en el paro.

Hacer las cosas en terreno del entrevistado no responde a la debilidad sino a lo prctico. Suele ser
el que paga y no quiere desplazarse. SI la entrevista es con varias personas tiene menos costes
para la empresa. Los analistas estn ms habituados. Y es la costumbre, lo que se suele hacer
siempre.
Pero puede tener inconvenientes, por ejemplo las interrupciones o que el entrevistado no se
abstraiga de lo que estaba haciendo o de los problemas pendientes por resolver. Nunca debe
hacerse una entrevista en el despacho del entrevistado. Las interrupciones podran afectar a la
marcha de la entrevista. Siempre se debe buscar un espacio en el que se respete la actividad de
los asistentes.
9-Tcnicas de obtencin de informacin
143
Si seguimos las recomendaciones de la PNL (programacin neurolingistica) deberamos utilizar
siempre la misma sala. O una sala en la que la gente est habituada a hacer reuniones. Segn la
PNL las personas tenemos condicionantes, anclas, de modo que ciertos entornos predisponen
nuestra actividad para la PNL un ancla es un estmulo sensorial especfico que evoca una
experiencia determinada. De la misma forma que un espacio de estudio bien iluminado y
confortable en el que siempre estudiamos nos permite alcanzar la concentracin con mayor
rapidez una sala en buenas condiciones y en la que habitualmente se mantienen reuniones nos
predispone a la actividad de comunicarnos.
La toma de notas puede intimidar cuando se hacen preguntas ntimas. Pero raramente cuando se
pregunta por la actividad profesional. Mi experiencia es que a cualquier profesional se extraar
que un analista de requisitos no tome notas de lo que se le dice. En todas las reuniones de
empresa se suelen generar actas.
Es cierto que los silencios pueden intimidar pero tambin depende del resto de seales que
emitamos. Una sonrisa puede romper esa intimidacin. El silencio tambin puede hacer que el
entrevistado reflexione. Tampoco debemos tener prisa en hablar. Podramos estar interrumpiendo
al entrevistado o forzndolo a responder con ms rapidez. Cuando un silencio se produzca
preocpese de mantener el contacto. No se sienta molesto o incomodado, posiblemente
transmitir esta sensacin. Por el contrario, reljese y deje pasar unos segundos con una actitud
atenta. Mire a su interlocutor de forma amable. Sin urgirlo. Pero esperando por si tuviera algo
ms que decir. Tenga siempre frases preparadas para cambiar de tema. Si se le ocurren nuevas
ideas puede enviarme un correo...
Respecto al asombro, de nuevo, se trata de un problema de intimidad. Asombrarse no tiene
porqu ser malo. Si alguien cuenta que hace el mismo trabajo cuatro veces, por ejemplo
introducir un pedido, uno se puede asombrar sin perder el respeto por el entrevistado.
En resumen se trata ms bien de ser natural y relajado en vez de desconfiado y suspicaz. Y sobre
todo, se trata de que el entrevistado tenga la sensacin de que a) sabemos lo que estamos
haciendo, b) nos interesa su opinin y c) pretendemos ayudarle. Porque, en realidad, todo esto de
las aplicaciones va de hacerle la vida ms fcil a la gente. Si lo que queremos es simplemente salir
del paso o no complicarnos la vida con los problemas de los dems es difcil que una entrevista
para obtener requisitos funcione bien.
9.3.2 El proceso de la entrevista El proceso de la entrevista El proceso de la entrevista El proceso de la entrevista
Entrevistas y reuniones deben organizarse segn las tres fases siguientes:
.1 .1 .1 .1 Preparacin Preparacin Preparacin Preparacin: : : :
Los analistas deben preparar la entrevista con antelacin. Para ello, si es necesario, buscarn
documentacin sobre los asuntos que se vayan a tratar. Identificarn las personas adecuadas de la
organizacin para tales asuntos y acordarn un lugar y hora para celebrar la entrevista. Todo ello
ser comunicado, con tiempo suficiente para que puedan prepararse, a los usuarios. Si los
participantes ya han sido informados por la direccin se enviar una nota, habitualmente un
correo, en la que
Debe enviarse una nota escrita a todos los participantes que contendr:
Una descripcin del motivo de la entrevistas
La relacin de participantes
Objetivos
Lista de los temas a tratar
Fecha, hora y lugar de celebracin
Tiempo previsto


Todo analista debe tener una plantilla de convocatoria de reunin.
Al preparar la entrevista deber tener en cuenta en qu mbito de requisitos piensa trabajar. Para
cada mbito, excepto el inicial claro est, deber llevar documentacin de lo tratado o concluido
en el nivel superior. Si va a tratar un proceso lleve informacin del rea. Si va a tratar sucesos
aporte la documentacin del proceso. Si va a trabajar en requisitos de uso aporte la descripcin
de los sucesos involucrados y prototipos provisionales de pantallas.
.2 .2 .2 .2 Realizacin: Realizacin: Realizacin: Realizacin:
1 11 1 La La La La toma de contacto toma de contacto toma de contacto toma de contacto
En toda entrevista puede haber varios entrevistadores y varios entrevistados. Siempre habr un
coordinador, entre los entrevistadores, que ser el que establezca los aspectos de toma de
contacto y de procedimiento.
Dar la bienvenida a los participantes y justificar la razn de su presencia en la
organizacin. Indicar qu personas autorizan y se interesan en los asuntos que se
tratarn.
Proceder a la presentacin de las personas. Si es un grupo pequeo el coordinador
presentar a los entrevistadores y la razn por la que acuden a la reunin. Si el grupo
fuera numeroso, ms de seis personas, propondr que cada uno se presente e indique su
rol o inters en los temas que se van a tratar. En este caso deber haber previsto
cartulinas para hacer prismas con los nombres y roles de cada participante. Aunque
siempre es posible improvisarlo con folios.
Explicar qu se va a tratar y la forma de trabajo. Deber controlar los tiempos y las
transiciones entre temas. Si un tema no se finaliza en el tiempo previsto es preferible
hacer una ronda de intervenciones en la que cada participante indique los temas
pendientes. De este modo se prepara el guin de la siguiente entrevista.
Repase la documentacin aportada en la preparacin. Asuma que algunos usuarios no
habrn tenido tiempo ni de leerla. No dedique demasiado tiempo a ello. Simplemente
ofrezca las pistas de donde deben mirar si lo necesitan
2 22 2 Saber escuchar y preguntar Saber escuchar y preguntar Saber escuchar y preguntar Saber escuchar y preguntar
De forma general deben tenerse en cuenta las recomendaciones bsicas de toda comunicacin y
las normas elementales de educacin.
Se deben dar muestras de escucha como asentir o reafirmar.
La distribucin de tiempos entrevistado-analista debe mantener una relacin 80-20.
Puesto que el objetivo es obtener informacin el analista no debe ocupar ms de un 20%
del tiempo.
No discuta con los entrevistados. No pretenda demostrar que estn equivocados. Aunque
fuera un objetivo del proyecto no es el momento adecuado. Est ah para obtener
informacin.
No se deja llevar por los prejuicios personales. El aspecto, las ideas o la cultura de la
gente no tienen porqu ser los que usted desea. Debe intentar entender qu problemas
tienen los participantes y qu informacin necesitan para resolverlos adecuadamente.
No presuma que porque usen los mismos trminos que otras organizaciones ya no hace
falta que le cuenten ms. Los trminos carecen de valor en s mismos. Los significados
son lo importante y los significados dependen de las personas.
No utilice jerga tcnica. Esfurcese por aprender el lxico organizacional. Acercarse al
lenguaje de los usuarios. Por ejemplo un trmino tan habitual como interfaz de usuario
es muy confusa. Los usuarios hablan de pantallas.
9-Tcnicas de obtencin de informacin
145
No tiene que hacerse amigo de nadie. No tienen que caer bien. No tiene que impresionar
a nadie. En muchos casos los usuarios creen que estn perdiendo el tiempo en una
reunin de anlisis porque tienen trabajo que hacer. Por lo menos debe conseguir: que
crean que sabe preguntar y que crean que se interesa por sus problemas con el uso de la
informacin.
3 33 3 E EE El ll l control de la entrevista control de la entrevista control de la entrevista control de la entrevista
El analista debe mantener en todo momento el control de la entrevista. En los temas y en los
tiempos. El control de temas debe basarse en la propuesta realizada. Tenga en cuenta que si ha
decidido trabajar sobre un mbito determinado no debe profundizar en los superiores o inferiores.
Encontrar aspectos de ellos pero cntrese en el mbito y los elementos que identific de ese
mbito. Imagnese que est haciendo una reunin para describir un suceso X. A medida que lo
van describiendo aparecen otros sucesos que no haba detectado hasta ahora. Tome nota de ellos
y djelos como requisitos pendientes de refinar. Informe a los participantes que se tratarn en
otra reunin. En el mejor de los casos, si usted es de los que no tienen tiempo que perder, djelos
para el final de la reunin. Primero acabe lo que haba planificado. No entre a refinar nuevos
requisitos. Solo tome nota de ellos.
En algunos casos los usuarios tienden a presentar sus problemas recientes con la informtica.
Deber saber cmo abordar y soslayar este tipo de intervenciones. Argumente siempre cual es el
guin de la reunin pero sea comprensivo. Un usuario puede hacerle culpable de todos sus
problemas informticos. Si su sistema acaba de caer y ha perdido un par de horas de trabajo
pensar que usted pertenece a la casta de las personas culpables de sus problemas. Atindale,
djele que se desahogue. Dle la razn de forma condicionada desde luego si es como usted
dice tiene toda la razn para estar indignado. Tome nota del problema y emplcelo a
solucionarlo en el marco de una reunin ms adecuada.
Trate de identificar la motivacin de cada participante. Observe si hay reticencias polticas. Si los
cambios introducidos alteran la autoridad o responsabilidad de la persona. Intente adaptarse al
modelo mental de cada usuario. Maneje como pueda a los usuarios que se muestran contrarios.
Esto es una tontera. Esto no sirve para nada. Ya lo han intentado tres veces y solo perdemos
el tiempo. En este caso debe contar con el apoyo de la direccin. Nunca debe imponerse. Pero
debe mostrar firmeza en el trabajo.
Los participantes son los que saben del negocio. Usted sabe de requisitos. Ellos son los mejores en
su trabajo y usted tambin en el suyo. Nadie de la reunin est ms capacitado que usted para
estructura el conocimiento. Si no, no lo habran llamado.
4 44 4 Finalizacin la entrevista Finalizacin la entrevista Finalizacin la entrevista Finalizacin la entrevista
Agradezca a la gente su tiempo y su disposicin. Comunqueles que les enviar un resumen.
Ofrzcales una forma de contactar con usted para cualquier aclaracin que deseen hacer.
Si quedan temas pendientes intente acordar la prxima fecha de entrevista.
.3 .3 .3 .3 Seguimiento Seguimiento Seguimiento Seguimiento
Tras la entrevista se har un resumen lo antes posible, estructurando el conocimiento obtenido y
esbozando los modelos obtenidos.
Usted deber haber anotado cada requisito y quin lo aporta en lenguaje natural. EL acta
recoger todo lo que se expres. Pero adems a partir del acta elaborar un modelo estructurado
de especificacin. En muchos casos puede asociar los requisitos de usuario a la estructura que
haga.
Se enviar un resumen a los entrevistados y se les solicitar la validacin del mismo.


Las entrevistas constituyen una tcnica flexible por su interactividad. Permite profundizar en los
problemas que se consideren ms relevantes y adaptarse al conocimiento de los usuarios. En
general ofrece control de la situacin permitiendo las repreguntas, cambios de temas etc.
El inconveniente es que son costosas en tiempo y recursos. Son difciles de evaluar pero esa
dificultad radica tambin en que la informacin que se obtiene es rica y compleja.

Figura + Plantilla para acta de reuniones
9-Tcnicas de obtencin de informacin
147
9.4 ENTREVISTAS Y MBITOS DE LOS REQUISITOS.
9.4.1 Las entrevistas iniciales Las entrevistas iniciales Las entrevistas iniciales Las entrevistas iniciales
En la entrevista inicial aparecen las causas esenciales por las que se inicia el proyecto. Lo habitual
es que se deba a la falta de informacin adecuada, a la poca eficacia, o a lo que cuesta obtenerla,
a la poca eficiencia.
Pero como los humanos no siempre nos guiamos por la eficacia y la eficiencia pueden aparecer
otras razones diferentes. Por ejemplo que ahora tengo dinero, que ha salido una ayuda, que
tengo que consumir el presupuesto, que me hace ilusin, que todos tienen informtica y un largo
etctera.
En la entrevista inicial debe conseguir:
Conocer porqu sus clientes creen que tienen un problema, es decir los motivos de iniciar un
proyecto de anlisis.
Conocer quines son los responsables de definir el problema. Si se trata de las primeras
entrevistas todos los participantes deben de haber sido informados por la direccin de la
organizacin que estas reuniones se van a realizar y que la direccin desea que participen en
ellas. Las primeras reuniones deben ser convocadas por la direccin para evitar incidencias
con la coordinacin de horarios.

Existen, por otra parte, diferentes grados y perspectivas de inicial.
Una perspectiva es la de las personas. Bajo esta perspectiva las entrevistas iniciales permiten la
toma de contacto y el conocimiento preliminar de los actores que participarn en el proceso de
anlisis.
Otra perspectiva es la de proyecto. Iniciamos un nuevo proyecto del que deberemos obtener
informacin.
Pero ambas perspectivas pueden darse con diferentes grados. Sobre todo en la perspectiva
proyecto la gradacin aparece vinculada a los mbitos de los requisitos que se presentaron en el
segundo captulo.
Un proyecto puede abordarse desde el mbito sistema, rea o proceso. Una organizacin puede
requerir tan solo la mejora de un determinado proceso con el que tienen problemas. O puede
querer revisar el funcionamiento de todo su sistema de informacin.
Sea cual sea el mbito aparecen aspectos comunes. Estos aspectos aparecen en lo que en
diferentes mtodos se denomina documento de inicio de proyecto.
.1 .1 .1 .1 El documento de inicio de proyecto. El documento de inicio de proyecto. El documento de inicio de proyecto. El documento de inicio de proyecto.
El punto de partida en un desarrollo siempre es una descripcin inicial del sistema de inters. Esta
descripcin se obtendr de los responsables del sistema/rea o proceso que se vaya a analizar.
Bien porque existen especificaciones de procedimiento, bien porque se establezcan en una
entrevista especfica.
La descripcin inicial servir para identificar las fuentes de informacin esenciales para la captura
de requisitos. Es conveniente definir una ficha de inicio de proyecto que contenga la descripcin
general del sistema, rea o proceso a desarrollar.
La ficha deber tener una estructura similar a las que se presentan a continuacin.





Figura 5 Ejemplo de inicio de proyecto


9-Tcnicas de obtencin de informacin
149
1 11 1 Motivacin Motivacin Motivacin Motivacin. .. .
Razones por las que se inicia el proyecto. Deberan incluir mejoras en los costes econmicos,
temporales. Puede tratarse en muchos casos de problemas de imagen o de posicionamiento en el
mercado de servicios.
2 22 2 Objetivos Objetivos Objetivos Objetivos. .. .
Define las intenciones esenciales del sistema a desarrollar. Los objetivos deben considerarse
requisitos y se asociarn a indicadores que podrn adoptar dos formas. Indicadores objetivos
obtenidos a partir de informacin del propio sistema (tiempos y recursos utilizados) o indicadores
subjetivos y debern asociarse con encuestas de satisfaccin identificando adems a los usuarios
afectados.
3 33 3 Exclusiones: Exclusiones: Exclusiones: Exclusiones:
Cuando existan partes del sistema que no se desee analizar por razones de complejidad,
economa o no exista necesidad.
4 44 4 Subsistemas Principales: Subsistemas Principales: Subsistemas Principales: Subsistemas Principales:
Si el proyecto es complejo pueden aparecer varios subsistemas, reas de negocio o procesos de
negocio. Los subsistemas principales deben entenderse como requisitos genricos que
posteriormente debern refinarse.
5 55 5 Fuentes de Informacin Fuentes de Informacin Fuentes de Informacin Fuentes de Informacin. .. .
Personas o documentacin relevante que nos proporcionarn informacin de cada subsistema. De
cada persona deberemos anotar: Nombre, e-mail, telfono de contacto, subsistema/rea/proceso,
responsabilidad.
Es conveniente conocer los intereses, motivaciones y responsabilidad de cada participante. Aparte
de la informacin de contacto reseada antes podramos obtener informacin sobre los siguientes
aspectos de cada participante:
Rol: Participantes o Usuarios finales. Deberamos saber en calidad de qu interviene cada
persona. Diferenciar si va a ser un usuario final o es experto o autoridad en el negocio. Por lo
tanto si la visin de requisitos que aportar es estratgica, directivas, operacional o de cliente
o proveedor. Y por lo tanto si su relacin con el problema debe considerarse principal,
secundaria u ocasional.
Grupo de usuarios. Es importante saber si cada participante es representativo de la
problemtica de otras personas de la organizacin.
Experiencia en el negocio [Bsica|Avanzado|Experto]
Experiencia tecnolgica [Bsica|Avanzado|Experto]
6 66 6 Integracin. Integracin. Integracin. Integracin.
Necesidades de integracin con otros subsistemas o con sistemas externos (banca, gobierno...). La
integracin debe plantearse como un conjunto de requisitos de entrada salida con otros sistemas.
Constituyen conjuntos de interacciones comunicativas.
7 77 7 Restricciones Restricciones Restricciones Restricciones
Tcnicas
Lenguajes, plataformas u otros aspectos tcnicos que deben ser utilizados en el proyecto.
Econmicas
Presupuesto estimado.
Legales
Legislacin aplicable al proyecto. Nivel de privacidad LOPD.
Culturales
Consideraciones culturales especficas segn los mercados destino.


8 88 8 Requisitos genricos Requisitos genricos Requisitos genricos Requisitos genricos
Idiomas
Accesibilidad
Portabilidad
Confidencialidad y seguridad de accesos
9 99 9 Requisitos del entorno operacional Requisitos del entorno operacional Requisitos del entorno operacional Requisitos del entorno operacional
Se trata de todas aquellas caractersticas y modos de funcionamiento que condicionarn la futura
solucin
Disponibilidad. La disponibilidad determinar los requisitos de seguridad, respaldo y
contingencias de agentes soporte. La disponibilidad se puede dar en la forma 24/7 para
indicar 24 horas al da los siete das de la semana. Pero un aspecto importante es intentar
valorar el coste de cada hora que el sistema no est disponible. Estos aspectos determinan la
seguridad ante fallos.
Distribucin geogrfica
Entornos de operacin especiales: luminosidad, polvo, temperatura.
Usuarios previstos. Usuarios concurrentes
Crecimiento y evolucin estimada del sistema.

Figura 6 Estructura del documento de inicio de proyecto de la Autoridad Portuaria de valencia
10 10 10 10 Requisitos comunicativos Requisitos comunicativos Requisitos comunicativos Requisitos comunicativos
Son requisitos de informacin de mbito sistema. Siempre se trata de salidas. Es muy raro que a
nivel sistema se planteen entradas.
Consultores estratgicos: indicadores estratgicos, cuadro de mando....
9-Tcnicas de obtencin de informacin
151
Requisitos propagables (deberan ser estndares)
o toda entrada o salida del sistema se trazar indicando el usuario, el instante y la
terminal desde donde se trabaja
.2 .2 .2 .2 Requisitos in Requisitos in Requisitos in Requisitos ini ii iciales del mbito sistema: e ciales del mbito sistema: e ciales del mbito sistema: e ciales del mbito sistema: estndares. stndares. stndares. stndares.
Requisitos que puedan afectar al desarrollo
Se trata, en la mayora de los casos, de requisitos especificados en el mbito sistema pero
propagables a otros mbitos ms especficos. Son todos los patrones que pueden afectar a
elementos especficos del desarrollo. Por ejemplo la forma de presentar los formularios. La
manera de resolver el acceso a un conjunto de objetos. La disposicin de los elementos de los
mens o de los botones, la apariencia, color, zonas de mensajes de las pantallas, etc.
o Estndares de aspecto e imagen corporativa
o Estndares de uso de la interfaz:
Patrones estructurales: de mantenimientos bsicos, lista/detalle,
maestro/detalle,
Patrones de servicios: filtros, bsquedas, ordenaciones.
Patrones de disparo
o Estndares de arquitectura y lenguajes
o Estndares de documentacin
o Estndares de pruebas
o Estndares de programacin
o Estndares de nominacin de variables, campos, tablas de base de datos
Requisitos de comunicaciones
Son requisitos de informacin de mbito sistema. Se trata de requisitos propagables.
Por ejemplo la auditora de entradas o salidas.
De toda comunicacin de entrada o salida del sistema se registrar
indicando el usuario que la recibe o enva, el instante y la terminal desde
donde se trabaja
todas las comunicaciones a los administrados se efectuarn mediante
certificado con acuse de recibo.
Indicadores para el seguimiento de implantacin: cmo se est usando la
aplicacin, quin la usa y quin no. Nos dice cmo debemos reforzar la
formacin a revisar los requisitos.

9.4.2 Las entrevistas de Las entrevistas de Las entrevistas de Las entrevistas del mbito l mbito l mbito l mbito proceso proceso proceso proceso
En el mbito proceso el objetivo es determinar los objetos de negocio que lo caracterizan y las
interacciones comunicativas de entrada o salida relacionadas con ellos.
Normalmente un proceso de negocio se describe en la forma accin objeto. Por ejemplo Gestin
de pedidos, Gestin de reclamaciones, Gestin de facturas....
En la fase de proceso no debe profundizarse en la descripcin de cada interaccin. De hecho los
participantes de obtencin de requisitos de procesos no deberan ser los mismos que los del
mbito de sucesos.


Se est definiendo la poltica organizacional. La forma en que los diferentes departamentos
cooperarn para la prestacin de un servicio o la produccin de bienes. Lo que requiere, en ltima
instancia, la aprobacin de la direccin.
Obtenga la informacin general del proceso en primer lugar. Recuerde los apartados
caractersticos de un proceso.
Nombre
Motivos para el cambio
Objetivos
Fuentes de informacin
Desde el punto de vista informativo son especialmente importantes los aspectos comunicativos:
Objetos de negocio
Comunicaciones externas
Indicadores
Diagrama de comportamiento

Una vez determinada la motivacin para analizar el proceso compruebe que los objetivos del
proceso estn claros. Comience por intentar establecer relaciones entre los objetivos e indicadores
de negocio. Si nadie es capaz de establecerlos puede ser por diferentes razones. No tienen
costumbre de trabajar con indicadores o no estn las personas que tienen una visin tctica del
proceso. Compruebe que los usuarios que debern supervisar el funcionamiento del proceso estn
presentes. SI lo estn y no sale ningn indicador espere a que el proceso se haya definido
operacionalmente es decir espere a haber finalizado el diagrama de comportamiento
comunicativo.

A continuacin obtenga informacin de los objetos de negocio. El primer aspecto a dilucidar es el
tipo de objetos involucrados en el proceso.
Si los objetos son esencialmente derivados deber trabajar a partir del objeto. Deber conseguir
que los participantes describan el objeto y los analistas irn definiendo la estructura. Es muy
conveniente disponer de formularios de usuario para conducir las preguntas. El anlisis de la
composicin del objeto permitir llegar a los sucesos bsicos necesarios para la construccin del
objeto.
Si los usuarios describen actividades de gestin y procedimiento, si los objetos de negocio son
esencialmente bsicos se utilizarn las tcnicas de anlisis generativo.

Proceda segn las recomendaciones del anlisis generativo. Utilice la unidad reactiva como
criterio. Recurra a formularios o a descripciones de proceso existentes. Busque siempre la forma
en que se inician las cosas. Vaya siguiendo las diferentes actividades que conforman el proceso.
Busque siempre la intervencin externa de actores que aporten nueva informacin.
Una vez llegue a un primer bosquejo de comportamiento utilice las tcnicas del apartado 5.7
Anlisis del comportamiento comunicativo para revisar la bondad de la descripcin. Fjese
especialmente en la existencia de reglas de negocio de comportamiento. Las reglas de negocio de
comportamiento estn asociadas a la auditora de contenidos descrita en el apartado 5.7.3
Consultores de auditora. A partir de ellos podemos detectar la necesidad de comportamiento
aadido para supervisar la forma de operar. A veces la informacin de las reglas de negocio de
comportamiento puede surgir al analizar los requisitos de un determinado sucesos como se define
en el apartado 6.3.4 DESCRIPCIN DE LA REACCIN DEL SISTEMA.
9-Tcnicas de obtencin de informacin
153
9.4.3 Las entrevistas del mbito interaccin Las entrevistas del mbito interaccin Las entrevistas del mbito interaccin Las entrevistas del mbito interaccin
Estas entrevistas se realizan con las personas directamente involucradas en la operacin cotidiana.
Son las que tienen un conocimiento ms detallado de la informacin que se utiliza.
Para cada suceso deber pensar un protocolo de preguntas segn la lista de referencia que se
aport para el suceso.
1. 1. 1. 1. DESCRIPCIN GENERAL DESCRIPCIN GENERAL DESCRIPCIN GENERAL DESCRIPCIN GENERAL
Objetivos
Tenga en cuenta que est en el mbito de las interacciones. Los objetivos sern
comunicativos. Puede ocurrir que aparezcan objetivos sobre la comunicacin de entrada
(conocer las necesidades de un cliente) o de salidas vinculadas (informar a produccin
para que conozca los pedidos de clientes). No utilice la palabra objetivos. Recurar a las
palabras para qu.
Descripcin
Confeccione una descripcin fsica completa. Describa grficamente todos los
procedimientos fsicos que acompaan al suceso lgico. Preocpese de indicar las
responsabilidades de los agentes involucrados en soportar el transporte o el envo de
documentacin. Si el origen de la informacin es remoto respecto al contacto describa le
trasiego de informacin desde el inicio.
Necesidades y problemas.
Deje esta pregunta para el final. Cuando tenga una visin ms completa de la interaccin.
Utilice un lenguaje positivo. No use nunca la palabra problemas. Pregunte siempre por las
mejoras. Creen que podra mejorar la forma en que lo hacen ahora?
2. 2. 2. 2. DESCRIPCIN DEL CONTACTO DESCRIPCIN DEL CONTACTO DESCRIPCIN DEL CONTACTO DESCRIPCIN DEL CONTACTO
Disponibilidad
Restricciones temporales de disponibilidad, horario ...
Pregunte por los horarios de disponibilidad. Categorice la disponibilidad. El tiempo
que puede estar detenido o desatendida la comunicacin.
Actores secundarios
Averige que personas son necesarias para dar soporte al proceso. Tenga en cuenta
que en el caso de que se requiera alta disponibilidad los
Canales
Compruebe por qu canales diferentes puede llegar la informacin.
Seguridad
Autoridad
Averige quin est autorizado para establecer esta comunicacin. De quin se fa el
sistema de informacin.
Acreditacin del emisor
Averige si son necesarios protocolos de acreditacin de personas.
Acreditacin de lo emitido
Verificaciones sobre los datos aportados, ya sea mediante certificaciones
documentales ya mediante inspeccin visual, diagnstico, juicio, estimacin....
Verificacin de elementos fsicos asociados a la comunicacin.
Compruebe si junto con la informacin aportada es necesario verificar algn aspecto fsico.
Por ejemplo contar los bultos que entrega un mensajero. Identificar el dvd que devuelve un
socio de un videoclub. Verificar el funcionamiento de una tarjeta que se entrega a un cliente.



3. 3. 3. 3. DESCRIPCIN DE LA COMUNICACIN DESCRIPCIN DE LA COMUNICACIN DESCRIPCIN DE LA COMUNICACIN DESCRIPCIN DE LA COMUNICACIN
Estructura del mensaje
Utilice siempre formularios para definir las estructuras. Formularios basados en papel o
formularios de ordenador. Concrete siempre las cosas. Aunque documente mediante
estructuras utilice imgenes ms prximas al usuario. SI el usuario est acostumbrado a
algn programa existente obtenga las pantallas que est acostumbrado a utilizar.
Comprenda el modelo mental tecnolgico que el usuario tiene.
Restricciones comunicativas.
Es raro que los usuarios aporten restricciones. No entienden la palabra y tiene una carga
peyorativa. Lo mejor es preguntar por condiciones. Existe alguna condicin para que se
acepte un pedido?
Requisitos de fiabilidad
Adems de los contemplados en el apartado de contacto tendremos que ver si es
necesario aadir nuevos sucesos para autorizar o validar las comunicaciones poco fiables.
Requisitos de uso
Formularios y documentos de usuario
Requisitos de aspecto
Requisitos de soporte editorial: Localizadores/Filtros
4. 4. 4. 4. DESCRIPCIN DE LA REACCIN DEL SISTEMA DESCRIPCIN DE LA REACCIN DEL SISTEMA DESCRIPCIN DE LA REACCIN DEL SISTEMA DESCRIPCIN DE LA REACCIN DEL SISTEMA
Objetos de negocio bsicos
El usuario suele opinar poco sobre las operaciones internas de almacenamiento. La
estructura del mensaje determina la mayora del modelo de datos y de la estructura de
actualizacin.
Objetos de negocio derivados
Ser necesario un anlisis de objetos derivados para documentarlos debidamente.
Funciones de negocio
reglas de negocio de especializacin de tratamientos
reglas de negocio de especializacin de comportamiento
Sucesos vinculados
Pregunte por los consultores previos. Tenga en cuenta que la pregunta de consultores
previos solo tiene pleno sentido para el actor primario, el que aporta la informacin. Por
ejemplo al solicitar un prstamo el socio de una biblioteca es el actor primario. La
persona que lo atiende y que probablemente manipular el ordenador es el actor
secundario. Errneamente se suele preguntar a los usuarios que no siempre son los
actores primarios.
Hay alguna informacin que cree conveniente para hacer esto? Cree que su decisin
podra mejorar si dispusiera de alguna informacin?
Pregunte por todas aquellas personas que necesariamente deberan conocer el nuevo
hecho que se informa en la interaccin analizada o alguna de loas conclusiones extradas
de l.



9-Tcnicas de obtencin de informacin
155
9.5 LAS ENTREVISTAS Y LOS MBITOS DE LOS REQUISITOS.
En las entrevistas el analista debe estar atento a las expresiones de los usuarios. Debe utilizar la
taxonoma de requisitos para identificar de forma rpida los requisitos que vayan apareciendo.
En primer lugar todo requisito debe identificarse en el mbito correspondiente. Lo primero que
deber hacer es intentar asociar cada expresin a un suceso u objeto. Si la expresin es
demasiado genrica entonces mire a ver si se trata de un proceso es decir de un conjunto de
interacciones.
Pero sobre todo no permita que la falta de estructura de los usuarios influya en su criterio.
Necesita identificar el mbito y la caracterstica para saber si debe recabar ms informacin y
cmo debe seguir preguntando.
Lo primero que debe hacer un ingeniero de requisitos es localizar el mbito y la caracterstica
dentro del mbito que identifica cada requisito.

AREA
SSTEMA
PROCESO
OBJETO
SUCESO
CONSULTOR
Propiedad
Regla O
CONTACTO
DESCRPCON
REACCN
Disponibilidad
Seguridad
Verificacin
Restricciones
Fiabilidad
Uso
Dominios
Derivacin
nicial
Objetos bsicos
Objetos Derivados
Sucesos Vinculados
Basica
Derivada
Elemental
Compleja
Regla C
Regla C
Funcion
Funcion
Propiedad Estructura
Regla E
Funcion
Regla T
Funcion
Objetos de negocio ndicadores
Sucesos

Un requisito puede ser genrico. Un rea (comercial), un proceso (gestin de reclamaciones), un
objeto (pedido), un suceso (pasar pedido a produccin) o un consultor (listado de pedidos
pendientes de cargar). O puede ser especfico, una caracterstica de cualquiera de los anteriores.
Pero todo requisito siempre identifica un mbito concreto. Por ejemplo
Suponga que ha obtenido la siguiente descripcin de requisitos:
Tipo de financiacin de los proveedores: los proveedores se pueden clasificar en dos tipos
dependiendo si su pago es o no financiado.
Proveedores financiados: Los proveedores financiados son aquellos a los que se paga sin tener
que haber cobrado la mercanca una vez cumplido el plazo de pago que tiene asignado.
Proveedores no financiados: Los proveedores no financiados son aquellos a los que se paga
cuando la mercanca ha sido cobrada, excepto si se ha excedido el plazo de pago


correspondiente, momento en el cual se debe pagar la mercanca al proveedor por lo que se
debe proceder a la liquidacin aunque la mercanca an no haya sido cobrada (pasa por tanto a
ser financiado).
Esta descripcin contiene varios requisitos. Comencemos por tipo de financiacin cual es su
mbito? Parece una propiedad de un objeto de negocio. Segn la tabla de decisin para
clasificacin de propiedades consideraremos los dos aspectos de toda propiedad. Si es elemental
identificaremos el objeto asociado que la identifica. Si es bsica el suceso generador.


Identificamos la propiedad como adscrita al objeto Proveedores.
Ahora, para toda propiedad de objeto procederemos a su anlisis generativo. Deberemos
considerar si es bsica o derivada. Si es bsica localizaremos qu suceso la genera. Si es derivada
buscaremos la definicin de la funcin que la genera. Como vimos en el tema de objetos
derivados la funcin puede ser estructural a partir de otros objetos o algortmica mediante un
procedimiento definido. Si la derivacin requiere condiciones complejas podemos hablar de una
regla de negocio y procederemos al estudio de las condiciones mediante tablas de decisin o
rboles de decisin.
La pregunta a formular ser por tanto: quin o qu define el tipo de financiacin de un
proveedor? A partir de la respuesta identificaremos el suceso generativo o la funcin que lo
define.
Una vez identificada la propiedad Tipo Financiacin y su gnesis procederemos a considerar
porqu es importante en el contexto. A falta de ms informacin se deduce que se est tratando
el pago a proveedores. Se tratara por tanto de formular las preguntas que nos permitieran
relacionar esta caracterstica con el suceso u objeto correspondiente. En principio parece que
contribuira a formar parte de alguna condicin relacionada con el pago, es decir de alguna
funcin o regla.
El control de la entrevista debe llevarlo el analista identificando los requisitos que se expresan y
descartando los que no tengan que ver con el mbito que se trata.
Por ejemplo, si se estn definiendo procesos el analista buscar:
Caractersticas del proceso, descripcin de objetos de negocio del proceso o identificacin de
sucesos y comunicaciones relacionadas con ellos.
Deber escuchar los detalles que le den los usuarios pero reconducir el tema al comportamiento
y a la bsqueda de sucesos y comunicaciones externas.
Cuando trabaje en especificacin de sucesos convocar las reuniones para abordar la descripcin
de cada suceso. Ir desgranando de forma sistemtica, utilizando la ficha de sucesos, las
caractersticas del suceso. Identificar la complejidad de la estructura comunicativa y considerar
los aspectos bsicos y derivados del suceso.
9-Tcnicas de obtencin de informacin
157
Las preguntas esenciales de todo suceso son siempre:
qu me comunican y para qu me lo comunican
a quin informo de lo que me comunican y para que quiere saberlo
Porque el ingeniero de requisitos siempre debe pensar en primer lugar en la informacin y en la
utilidad que tienen para los usuarios.