Resume of the article “From conceptual modelling to Requirements Engineering”

Eugenio Mauri

Description

Resume of the article “From conceptual modelling to Requirements Engineering” by Eugenio Mauri at I.A.E. Pantheon Sorbonne , Sorbonne Graduate Business School, Master Systèmes d'Information et de Connaissance

Informations

• Publié par: EugenioMauri
• Publié le: 03 juillet 2012
• Nombre de lectures: 57
• Langue: English

Extrait

Eugenio MAURI MASTER SIC – TP “UE02 - Requirements Engineering”

 IAEParis, 1/2/2011

Resume of the article “From conceptual modelling to Requirements Engineering”

In order to build more stable systems providing better quality, engineers focus has moved from pure Conceptual Modelling (CM) to Requirements Engineering (RE). In fact RE manages change better by improving the process of requirements elicitation, validation and representation. CM major defaults are:

- CMwould focus only on “what” the system should do (while RE shifted the focus also on “why” it should do it); - CMassumed that all requirements were given (while re implies that they might need to be discovered or re-defined) - CMassumed that given requirements were stable (while RE takes into account the changing environment in which they evolve) - CMassumed that requirements could be validated against functionalities (while RE emphasise organisational needs and normal or exceptional use cases) - CMwould not provide tracing (while RE implies tracing of assumptions, decisions, alternatives, etc…) - CMwould nor provide guidance (while RE puts some focus on this)

Several Conceptual Models exist (MERISE, NIAM, etc…) in order to define the Universe of Discourse (the first phase of system life cycle). They all fall into three main categories: process-oriented, data-oriented or behaviour-oriented. Since these were basically three different perspectives not integrated to one another, some new conceptual models were created to integrate some of these aspects; also loosely connected conceptual models (so to represent the Universe of Discourse with few connected conceptual schemas) were invented. CM community developed activity process models (ex: Waterfall Model) that emphasised the product aspects of systems instead of the process employed to deliver the product; they were too restrictive because based on wrong assumptions such as predictable development path, no need for tracking, linear execution, de-correlation between activities and delivered products.

RE distinguishes 2 types of requirements: user-defined (e.g.: coming from people) and domain-imposed (e.g.: domain laws). From this assumption the Universe of Discourse has to be divided in two: - SubjectWorld (business domain, real world) - UsageWorld (describes the activities of agents, individuals, groups)

A third world, the System World, can also be added to the Universe of Discourse to better represent the system specifications environment (system model). 4 types of relationships link these 3 Worlds: Domain genericity, Usage fit and Intentional are the 3 relationship that address the “Why” question and provide th the rationale for system development; the 4relationship (Representation) was the only focus of CM. The Intentional relationship between the Usage World and the System World is the link between the system to be built and the changing environment where it has to be developed and can be better defined by goal driven approaches. Goal driven approaches, together with scenario modelling and use case development, help relating organisational objectives with system functions, particularly by taking into account users’points of views. Scenario based approaches are in fact used to define the Usage fit relationship between the Usage World and the System World.

Goal modelling has proven to be useful for specifying purposeful systems, however in reality, goals are not always given and sometimes they are difficult to define. Scenario based approach is an alternative approach, based on captured examples of normal or exceptional use cases of agent behaviours that help in eliciting requirements in envisioned situations. Different types of scenarios exist (descriptive, explanatory, exploratory) but they all concentrate on the functional features required in a system. They can be formulated at different degree of abstraction (instance scenario type scenario, mixed scenario) and expressed with different notations (informal, semi-formal, and formal). Goal driven and scenario based approaches have been coupled together in the CREWS-L’Ecritoire approach, to infer goal specification from operational scenario, discover more goals and check if a system fulfils expected goals. The CREW-L’Ecritoire process aims at discovering and eliciting requirements through a bi-directional coupling of goals and scenarios. Thanks to this bi-directional coupling, when a goal is discovered, a scenario can be authored for it and once a scenario has been authored, it is analysed to yield goals. In this process, goal discovery and scenario authoring are complementary steps and goals are incrementally discovered by repeating the goal-discovery, scenario-authoring cycle. This process is based on Requirement Chunks: a goal-scenario couple, where a goal is defined as something that stakeholders hope to achieve and a scenario is a possible behaviour made of interactions between agents. Requirement chunks can be of 3 different levels of abstractions (contextual, functional, and physical) and be linked together by 3 types of relationships (composition, alternative and refinement). Guidance is provided during the process for Goal Analysis (based on linguistic analysis) and Scenario Authoring (based on style/content guideline). Domain genericity relationship between the Subject and System World, represent non-functional quality criteria such as confidentiality, performance, accuracy and timeliness. It also suggested the possibility to create generic domain models, as template for requirements or set of predefined requirements. Model libraries can in fact be created, in order to reduce requirement engineering effort when dealing with applications that have similar requirements or share the same environment. Requirement engineering process is supported by guidance (whether active or passive) but, in order to do so, an adequate process model must be in place. Activity-oriented, Product-oriented and Decision-oriented process models are not completely suitable for this. A big effort from the requirement engineering community is being put in place in order to address in process models its two most important needs:

- generatealternatives for a given product situation - reduceprescription

Tracing, along with guidance, is another important feature of RE; requirement traceability (divided in pre-traceability and post-traceability) is a vital component when implementing a quality system since essential for change integration and also important for system acceptance. The three parts of process traceability (traceability of process execution, traceability of product evolution and traceability of the relationship between the previous two) must allow for tracing of the requirements produced. CM was made easier by CASE tools which provided for documentation and verification support but on the other hand they did not provide any help for distributed work, reusable components, internet access, portability, standardisation, etc… Basically they did not provide enough process support and did not adapt to specific systems’needs. Trying to answer these two basic needs, some more sophisticated tools were created, offering a single repository for both method

engineers and application engineers, allowing for process-integrated environment support.