Upload
margot
View
56
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Processes in Requirements Engineering. Raimundas Matulevi č ius. 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. - PowerPoint PPT Presentation
Citation preview
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.