Description

This article starts from a simple, yet highly fertile observation: the development of an information system cannot be understood solely as a technical activity aimed at programming, but must be viewed in the context of the broader system in which it will be installed and used. In other words, an information system appears because, in a real system — usually an enterprise or an institution — there are problems, needs, bottlenecks, and expectations that must be understood before the requirements of the new system can be properly formulated.

To this end, the article proposes viewing the analysis through the lens of stakeholders' concerns. The text clearly states that understanding concerns means being able to describe them, and for each concern, a high-level specification must be elaborated. This specification describes the problem associated with the concern and the roles of the stakeholders who manifest that concern.

A very important point is the basic model of the information system. In the article, an IS is described by four types of entities: agent, activity, tool, and object. This scheme - for me it is a paradigm I hold very dear - is important not only as a conceptual simplification, but also because it provides a frame of reference for identifying concerns in relation to the structure and functioning of the system.

The proposed method has four steps: identifying concerns, classifying them, identifying the relationships between them, and prioritizing their resolution. In the article, the emphasis is placed mainly on the first two steps, as these are the decisive ones for the requirements gathering phase. The concerns are then identified from four perspectives on the development of an information system: social, functional, informational, and technological.

The social perspective views the system from the point of view of the needs, interests, and preoccupations of the stakeholders affected by its evolution. Here appear, for instance, the concerns of management, users, the system engineer, or other participants in business processes. The functional perspective looks at the system through the activities it supports or automates. The informational perspective sees it as a distributed repository of data, information, and knowledge. And the technological perspective regards the ICT infrastructure and software products that make the functioning of the system possible.

The article is not limited to general statements. It also discusses concrete examples of concerns, formulated as high-level specifications, such as the preoccupation related to the introduction of a new information technology and its effect on the nature of work. Here one can already see something very important for subsequent works: the concern is not just a label, but a structure that links a problem, a hypothesis, an expected conclusion, and a stakeholder role.

The chosen case study is from the Romanian public administration and concerns the activity of an office managing fiscal certificates. There, the method is used to identify the stakeholders, institutional objectives, and concerns arising from the social, informational, functional, and technological perspectives. Even if the article acknowledges that, due to space limitations, the concerns are only enumerated and not fully detailed, the case study has the merit of showing that the method does not remain at an abstract level.

Towards the end, the text also proposes a general classification of concerns into two main categories: concerns oriented towards obtaining something new by using the system, and concerns oriented towards checking, validating, or demonstrating expected properties and situations. This distinction is useful, because it already suggests a typology of the purposes that the analysis can serve.

The article's place in my research path

Viewed in retrospect, the article is important not only for what it says explicitly, but also for what it prepares. The methodological core, i.e., the notions of high-level specification, perspective, stakeholder vocabulary, and concern classification, will be taken up and carried forward in my collaboration with Crenguța in the works on ontology, conceptual facets, and multi-faceted views.

More precisely, the article establishes three ideas propagated by me in all my software engineering courses and which will be further developed. First, that analysis must start from stakeholders' concerns. Second, that these concerns can be systematically described through high-level specifications. And finally, that to understand an information system, multiple perspectives must be used, not a single dominant decomposition.

Therefore, in Crenguța's series, I see this text as the genesis paper. It directly opens the way to Understanding Concerns with Ontologies, to the article on concern-based ontology, and then to the articles on building the facets of information systems.

Links

• Back to Crenguța Bogdan's page
• Understanding Concerns with Ontologies (2008)
• Towards an Ontology using a Concern-Oriented Approach for Information Systems Analysis (2007)
• A Concern-Oriented and Ontology-Based Approach to Constructing Facets of Information Systems (2007)
• Concern-Oriented and Ontology-Based Analysis of Information Systems (2010)
• Conceptual modeling and ontologies