17.02.2003 SIF 8060 - Modellering av informasjonssystemer, 2003 1

Processes in Requirements Engineering

Raimundas Matulevičius

2

Overview

Loucopoulos P., Karakostas V., “System Requirements Engineering, McGraw-Hill, 1995. Chapter 2.

Nguyen L., Swatman P. A., “Managing the Requirements Engineering Process”., in proc. REFSQ’2001

3

A Framework for describing RE Processes

Three fundamental concerns of RE: Understanding of a problem. Formally describing a problem. Agreement on the nature of the problem.

The proposed framework focuses on the dynamics (‘how’) as opposed to the deliverables (‘what’) of RE.

Framework consists of 3 sub-processes: Elicitation, Specification, Validation.

4

Framework for RE processes

5

How to understand process?

Each process is described in terms of the following: The purpose of the process; The input to the process and its origins; The activities which take place during the

process and techniques used; The final and intermediate deliveries; The interaction with other requirements

engineering processes.

6

Requirements elicitationPurpose: At the beginning, an analyst knows very little about the software

problem to be solved. Gain knowledge relevant to the problem, which can be used to

produce a formal specification of the software need solve the problem.

Input Domain experts, literature about the domain, existing software

systems, similar applications, national and international standards, other stakeholders.

Activities Identifying all the sources of requirements knowledge. Acquiring the knowledge. Deciding on the relevant of the knowledge to the problem in

hand. Understanding the significance of the elicited knowledge and its

impact on the software requirements. Reuse knowledge acquired in similar problem domains.

7

Requirements elicitation (cont.)

Deliverables Model creation process: start with conceptual models and

end with the requirements specification model. The analyst starts formulating models of the problem domain

in the early stages of RE. As the RE process progresses, the conceptual model s

become more software oriented than problem domain oriented.

Interactions Elicitation can be viewed as providing ‘the raw material’ to

other processes.

8

Requirements specificationA specification can be viewed as a contract between user and software developers

which defines the desired functional behavior of the software artifact, without showing how such functionality is going to be achieved.

Purpose: Agreement between the software developers and the users on

what constitutes the problem which must by solved by the software system.

A blueprint for the development of the software systemInput From elicitation - ‘Raw knowledge’ should be converted into

meaningful information in order to produce a formal specification model.

From validation – what is valid and what is not in the formal specification and as such it acts as a force for changing the formal requirements model.

Activities Analysis and assimilation of requirements knowledge. Synthesis and organization of the knowledge into a coherent

and logical requirements model.

9

Requirements specification (cont.)

Deliverables The majority of RE approaches assume that the outcome of this

process is the requirements specification model: User oriented models specifying the behavior, non-functional

characteristics, etc., of the software which serve as point of understanding between the analyst, the customer and the user.

Developers-oriented models specifying the behavior, non-functional properties of the software system as well as constraints on resources, design constraints, etc, which act as blueprints for further development stages.

Interactions To elicitation - during specification it might apparent that more

information about the model is required. To validation –completion of some part of the specification

model can cause the need for validation.

10

Requirements validationRequirements validation is an ongoing process of RE which aims

to ensure that the right problem is being tackled at any time.

Purpose: Requirements validation certifies that the requirements model is

consistent with customers’ and users’ intentions. The need for validation: when a new piece of information is

assimilated in the current requirements model and when different pieces of information are integrated into coherent whole.

Input Any (formal, semi-formal or informal) requirements model.Activities Prepare the settings for an experiment. Performing the experiment and analysis its results.

11

Requirements validation (cont.)

Deliverables

Validation delivers a requirements model which is consistent and in accordance with the user’s expectations.

Interaction The need for validation is triggered by the acquisition of new

knowledge about the problem domain (elicitation) or by the formulation of a requirements model (specification).

12

Comparison of terminology Elicitation:

Requirements identification, requirements determination, requirements acquisition.

Specification: Software requirements analysis, requirements analysis,

problem analysis, problem definition, requirements definition.

The synthesis phase of specification contains activities: external product description (specification of the

functionality of software), requirements presentation (in which the results of

requirements identification are portrayed) software requirements specification (complete

documentation of what the software does externally) Validation:

Requirements communication

13

Software development models

The waterflow model; The spiral model; The prototyping model; The operational model; The transformational model; The knowledge-based model; The domain analysis model.

14

The waterflow model Software development consist of stepwise

transformation from the problem domain to the solution through a number of phrases which are wholly satisfied before their successors begin.

Critics: Lack of user involvement in the development after

requirements specification has ended. Inflexibility to accommodate prototypes. Unrealistic separation of specification from design. Inability to accommodate reused software. Maintainability problems. Complicated system integration.

Waterflow model takes a static viewpoint of RE by ignoring issues such as inherently dynamic nature (volatility of requirements and its impact on earlier and later phrases of development)

15

The spiral model Organizes the iterative nature of development

and the need to plan and assess risk at each iteration.

Activities: Plan next stage; Determine objectives, alternatives, constraints; Evaluate alternatives, identify and resolve risks; Develop, verify next level product

The spiral model introduces additional sub-processes of RE known as requirements risk analysis, using techniques such as simulation, prototyping.

16

The prototyping model Constructs and experiments with a mock-up version of the software

system, in order to gain some understanding of the functionality and behavior required from it.

Prototyping has to be constructed for one of the following reasons: To understand the requirements for the user interface To examine the feasibility of proposed design approach. To understand system performance issues.

After several revisions: Refine the prototype into a complete system Begin a conventional development process having benefited from

developing the prototype. RE framework in prototyping context:

Elicitation of requirements is achieved by involving the user in experimental use of the prototype.

Analysis of requirements is done by analyzing the structure and behavior of the prototype.

Formal specification coincides with prototype development. Validation is achieved by validating the prototype against the users’

intentions.

17

The operational model System model, that can be evaluated or executed in

order to generate the behavior of the software system. Purpose is to analyze not only required behavior but also required structure. How to decompose the problem domain functions into

succession of lower-level functions. How to introduce features such as information hiding and

abstraction into the design. How to take into account implementation issues.

Decisions about the structure should be made early in the development lifecycle.

RE framework in operational context: Elicitation is carried out at an initial stage (the construction of

the operational specification) Specification coincides with the construction of an executable

specification model. Validation coincides with the exercise of the operational

specification model.

18

The transformational model Attempts to automate labor-intensive stages of

development such as design and implementation by using the concept of transformation.

A transformation is defined as mapping from a more abstract object (such as specification) to a less abstract one (such as design or piece of code). In order to make transformations – object should be

represented in abstract way. RE framework in transformational context:

Requirements elicitation is the phase which derives an initial informal and incomplete requirements model, prior starting transformational development.

Requirements specification produces the formal specification model.

Requirements validation is the transformational phase where the formal model is validated by the user.

19

The knowledge based model

“Intelligent” implies that the tools incorporate a knowledge-base: Knowledge about how to perform some aspects of RE. Knowledge about the characteristics of some problem

domain, which can be employed in RE.

The major difference between knowledge based and non-knowledge-based approaches exist in the degree of intelligent tool usage in a process within RE.

20

The domain analysis model An activity, that takes place prior to RE. While RE is

concerned with analysis and specifying the problem of developing of a application, domain analysis has been concerned with identifying commonalities between different applications under the same domain. Phases such as problem understanding which are

traditionally considered in RE are reduced to ‘selecting and retrieving the contents of the appropriate library which contains the analysis of the domain under consideration.

The effort for requirements elicitation is significantly reduced since to a large extent elicitation has already be done as part of domain analysis.

Requirements specification consist of selection of an appropriate component from the reusable analysis of components library with possible adaptation if necessary.

The need for validation is reduced since the library components have already been validated as part of domain analysis.

21

Managing RE process A formal requirements specification is the end-product of a large

number of decisions, negotiations and assumptions made throughout RE process and such a specification is valid as the assumptions and decisions which underlie it.

It is important to be able to recreate the rationale behind some specification item in order to question its appropriateness and validity in the light of changed circumstances.

This not possible without assistance from rationale recording process which runs throughout RE: Provides a communication mechanism among the members of the

development team The effort required to produce the rationale behind a specification

forces requirements engineers to deliberate more carefully about their decisions.

IBIS – Issue-based Information System

22

Conclusions Requirements elicitation - the process of acquiring all the

necessary knowledge which is used in production of formal requirements specification model.

Requirements specification – the process which receives input the deliverables of requirements elicitation in order to create a formal model of requirements.

Requirements validation – the process which attempts to certify that the produced formal requirements model satisfies the users’ needs.

23

Some other RE approaches Pohl (1994) dimensions

Representation, Agreement, Specification Kotonya, Sommerville (1998) activities

Elicitation, Analysis and negotiation, Documentation, Validation

Management – is the process of managing changes to a system’s requirements.

Ferdinandi (2002) activities Requirements process/development

• Allocation, Elicitation, Analysis, Specification, Validation, Approval

Requirements management• Configuration identification, Baseline Management, Change

Control, Library control, Status control, Reviews and Audits.

24

Managing the Requirements Engineering Process

Nguyen L., Swatman P. A., “Managing the Requirements Engineering Process”., in proc. REFSQ’2001

25

Overview of research project Design explanation, which represents and explains the

rationale behind the design activities can provide the system developer and the project manager with many potential benefits in understanding and monitoring the RE process.

Action research: involves a conscious effort of the researcher to apply a theory

in a real-world situation to test the theory and in turn, provide practical outcomes for theory building.

Limitations - the difficulty in generalization of the results, the subjectivity of the approach.

Setting – systematic documentation of the requirements model and underlying arguments could be useful in understanding the evolution of requirements and in monitoring and improving RE processes.

FOOM (Formal Object Oriented Method) is based on a synthesis of socio-organizational theory, the object-oriented approach, and mathematical formal specification.

26

Research process

The RE process was cyclic with each cycle consisting of the elicitation, modeling and validation of requirements.

Requirements discussions, analyses and decisions were captured and documented using design explanation.

Issue-Based Information System (IBIS) Question-Option-Criteria notation.

27

Interpretation of Research Findings These cycles resulted in a new, significant understanding

of the RE process and a new approach to using design explanation within it.

The process of RE was found not to be a smooth and incremental evolution, but the one which involved occasional “crisis” points at which the requirements model was reconceptualised, restructured and simplified. – FIG.3.

During the process, the problem space was continuously explored and structured Components of the requirements model were introduced as new information was being acquired, accumulated and represented. The overall complexity grow in time.

At the critical point, the problem was reconceptualised, the problem space was reshaped and the model was simplified and restructured. The complexity of the requirements model was reduced significantly.

28

Implications of Research Findings New Challenges

Since current systems development life cycle models, approaches and tools tend to impose an incremental evolution of the requirements model, they should be critically reviewed whether they assist or handicap the systems developer and project manager.

Based on new understanding of the RE process, how best can we monitor and manage it?

Understanding complexity The essential complexity reflects the intrinsic understanding of the

problem. This complexity increases as the problem space is explored and our understanding is expanded.

The incidental complexity represents the complexity of expression/representation rather than of substance in the model.

Findings: RE is creative and opportunistic. Extends the understanding by revealing the effects of creative and

opportunistic insights in problem understanding and solving activity. Suggests a way of increasing these effects using a post hoc examination

of the problem space.

29

Implications of Research Findings The system developers:

continually explore and develop their understanding of requirements problem

radically reconceptualize the problem of different perspectives at some stages.

The complexity of the requirements model, if being well monitored, would signal the project/process manager when managerial actions might be needed.

There is a need to document the rationale behind the RE process: The IBIS base describes in chronological order, how

requirements evolve over time. IBIS arguments need to be reviewed and converted into

QOC analyses to aid the evolution of the requirements model as a whole.

Supporting Creativity of the RE process IBIS: reflection-in-action; QOC: reflection-on-action

30

Implications of Research Findings Most current CASE tools are neither syntax directed

or based on form of orderly editor which support the cumulative and incremental model of specification development.

Future CASE tools need to provide the requirements engineer with flexible environment, which promotes design reflectivity and creativity and supports reconceptualization of the problem and major restructuring of specification.

How we can (and should) train requirements engineers to work effectively in an environment, where insight and creativity are required, now becomes a central issue in Information Technology education.

31

Conclusions and Future Research New understanding of RE process:

The complexity in the RE over time should be monitored. Design explanation can be used to provide the rationale

behind the dynamics of the complexity in requirements model.

The design explanation base and the complexity of the model being monitored enable to understand the on-going creative process.

Future research: Consolidating theory; Further developing the new understanding; Testing the catastrophe-cycle model and evaluating the

new approach to using design explanation.

32

Summary

Requirements engineering: Elicitation, Specification, Validation; Software development models; Requirements management:

Maintain rationale behind requirements; Look for new methods for RE process.