REQUIREMENT ENGINEERING PROCESS

CHAPTER 2

Prepared by: Mesay Aschalew

Content
 Requirement Engineering Process
 Process Models
 Actors in Requirements engineering process
 Process support
 Process Improvement
RE process - inputs and outputs
RE process
 Requirements engineering process
includes requirements elicitation, requirements
modeling, requirements analysis, requirements
verification & validation, and requirements
management.
Input/output description
RE process variability
 RE processes vary radically from one organisation
to another
 Factors contributing to this variability include
 Technical maturity
 Disciplinary involvement

 Organisational culture

 Application domain

 There is therefore no ‘ideal’ requirements

engineering process
Process models
 A process model is a simplified description of a
process presented from a particular perspective
 Types of process model include:
 Coarse-grain activity models
 Fine-grain activity models

 Role-action models

 Entity-relation models
Process models
Process models
 A role/action model: This process model represents
the roles of the people involved in the software
process and the activities for which they are
answerable.
 Reuse-oriented software engineering: This process
modeling approach is based on the continuation of
a significant number of reusable components.
Process models
 An entity–relationship model (or ER
model) describes interrelated things of interest in
a specific domain of knowledge.
 A basic ER model is composed of entity types (which
classify the things of interest) and specifies
relationships that can exist between entities
(instances of those entity types).
Coarse-grain activity model of RE
RE process activities
 Requirements elicitation
 Requirements discovered through consultation with
stakeholders
 Requirements analysis and negotiation
 Requirements are analysed and conflicts resolved through
negotiation
 Requirements documentation
 A requirements document is produced
 Requirements validation
 The requirements document is checked for consistency and
completeness
Context of the RE process
Actors in the RE process
 Actors in a process are the people involved in the
execution of that process
 Actors are normally identified by their roles rather
than individually
 Requirements engineering involves actors who are
primarily interested in the problem to be solved
(end-users, etc) as well actors interested in the
solution (system designers, etc.)
 Role-action diagrams document which actors are
involved in different activities
Role descriptions
Human and social factor
 Requirements engineering processes are dominated
by human, social and organisational factors
b e c a u s e t h ey a l wa y s i n v o l v e a r a n g e o f
stakeholders from different backgrounds and with
different individual and organisational goals.
 System stakeholders may come from a range of
technical and non-technical background and from
different disciplines
Types of stakeholder
 Software engineers responsible for system
development
 System end-users who will use the system after it
has been delivered
 Managers of system end-users who are responsible
for their work
 External regulators who check that the system meets
its legal requirements
 Domain experts who give essential background
information about the system application domain
Factors influencing requirements
 Personality and status of stakeholders
 The personal goals of individuals within an
organisation
 The degree of political influence of stakeholders
within an organisation
Process support
 CASE tools provide automated support for software
engineering processes
 T h e m o s t m a t u r e C A S E t o o l s s u p p o r t we l l -
understood activities such as programming and
testing and the use of structured methods
 Support for requirements engineering is still limited
because of the informality and the variability of the
process
CASE tools for RE
 Modelling and validation tools suppor t the
development of system models which can be used to
specify the system and the checking of these models
for completeness and consistency.
 The tool package which supports this book includes
this type of tool.
 Management tools help manage a database of
requirements and support the management of
changes to these requirements.
A requirements management system
Requirements management tool
 Requirements browser
 Requirements query system
 Traceability support system
 Report generator
 Requirements converter and word processor linker
 Change control system
Process improvement
 Process improvement is concerned with modifying
processes in order to meet some improvement
objectives
 Improvement objectives
 Quality improvement
 Schedule reduction

 Resource reduction
Planning process improvement
 What are the problems with current processes?
 What are the improvement goals?
 How can process improvement be introduced to
achieve these goals?
 How should process improvements be controlled and
managed?
RE process problems
 Lack of stakeholder involvement
 Business needs not considered
 Lack of requirements management
 Lack of defined responsibilities
 Stakeholder communication problems
 Over-long schedules and poor quality requirements
documents
Process maturity
 Process maturity can be thought of as the extent
that an organisation has defined its processes,
actively controls these processes and provides
systematic human and computer-based support for
them.
 The SEI’s Capability Maturity Model is a framework
for assessing software process maturity in
development organisations
Good practice for RE process
improvement
 RE processes can be improved by the systematic
introduction of good requirements engineering
practice
 Each improvement cycle identifies good practice
guidelines and works to introduce them in an
organisation
Examples of good practice guidelines

 Define a standard document structure

 Uniquely identify each requirement
 Define policies for requirements management
 Use checklists for requirements analysis
 Use scenarios to elicit requirements
 Specify requirements quantitatively
 Use prototyping to animate requirements
 Reuse requirements
Types Of Software Process Models

 Software Processes is a coherent set of activities for

specifying, designing, implementing and testing
software systems.
 There are many different software processes but all
involve:
 Specification – defining what the system should do;
 Design and implementation – defining the organization of
the system and implementing the system;
 Validation – checking that it does what the customer wants;
 Evolution – changing the system in response to changing
customer needs.
Types Of Software Process Models
 software development process is SDLC models which stands for
Software Development Life Cycle models.
 The models specify the various stages of the process and the order
in which they are carried out.
 The most used, popular and important SDLC models are given
below:
 Waterfall model
 V model
 Incremental model
 RAD model
 Agile model
 Iterative model
 Spiral model
Waterfall model
 he waterfall model is a breakdown of project
activities into linear sequential phases, where each
phase depends on the deliverables of the previous
one and corresponds to a specialisation of tasks.
Waterfall model
 The advantages of waterfall model are
 Easy to understand and implement.
 Reinforces good habits: define-before-design and design-before-
code.
 Identifies deliverables and milestones
 Works well on mature products and weak teams.
 The disadvantages of the waterfall model are
 Real projects rarely follow the sequential approach.
 There is uncertainty at the beginning of the project regarding
requirements and goals. This model does not accommodate these
uncertainties very well.
 It does not yield a working version of the system until late in the
process.
V model
 The V-model represents a development process that may be
considered an extension of the waterfall model and is an
example of the more general V-model.
 Instead of moving down in a linear way, the process steps
are bent upwards after the coding phase, to form the
typical V shape.
 The V-Model demonstrates the relationships between each
phase of the development life cycle and its associated
phase of testing.
 The horizontal and vertical axes represent time or project
completeness (left-to-right) and level of abstraction
(coarsest-grain abstraction uppermost), respectively.
V model
V model
 Advantages of V-model
 Simple and easy to use.
 Testing activities like planning, test designing happens
well before coding. This saves a lot of time. Hence
higher chance of success over the waterfall model.
 Proactive defect tracking – that is defects are found at
early stage.
 Avoids the downward flow of the defects.

 Works well for small projects where requirements are

easily understood.
V model
 Disadvantages of V-model
 Very rigid and least flexible.
 Software is developed during the implementation
phase, so no early prototypes of the software are
produced
Incremental model
 The incremental build model is a method of software development
where the model is designed, implemented and tested incrementally (a
little more is added each time) until the product is finished.
 It involves both development and maintenance.
 The product is defined as finished when it satisfies all of its
requirements.
 Each iteration passes through the requirements, design, coding and
testing phases.
 And each subsequent release of the system adds function to the
previous release until all designed functionally has been implemented.
 This model combines the elements of the waterfall model with the
iterative philosophy of prototyping.
Incremental model
Incremental model
 Advantages:
 Divides project into smaller parts
 Creates working model early and provides valuable feedback
 Feedback from one phase provides design information for the
next phase
 Very useful when more staffing is unavailable
 Increments can be planned to manage technical risks
 Disadvantages:
 User community needs to be actively involved in the project. This
demands on time of the staff and add project delay
 Communication and coordination skills take a center stage
 Informal requests for improvement for each phase may lead to
confusion
RAD model
 Rapid application development was a response to
plan-driven waterfall processes
 Rapid application development (RAD) is often
referred as the adaptive software development.
 RAD is an incremental prototyping approach to
software development that end users can produce
better feedback when examining a live system, as
opposed to working strictly with documentation.
 It puts less emphasis on planning and more emphasis
on an adaptive process.
RAD model
 RAD may resulted in a lower level of rejection when the
application is placed into production,
 but this success most often comes at the expense of a
dramatic overruns in project costs and schedule.
 RAD approach is especially well suited for developing
software that is driven by user interface requirements.
 Thus, some GUI builders are often called rapid
application development tools.
 RAD can quickly give the customer something to see and
use and to provide feedback regarding the delivery
and their requirements.
RAD model
RAD model
 We have to use RAD model in the following cases, such
as:
 RAD should be used when there is a need to create a system
that can be modularized in 2-3 months of time.
 It should be used if there’s high availability of designers for
modelling and the budget is high enough to afford their cost
along with the cost of automated code generating tools.
 RAD SDLC model should be chosen only if resources with high
business knowledge are available and there is a need to
produce the system in a short span of time (2-3 months).
RAD model
 Advantages of the RAD Model
 Reduced development time.
 Increases reusability of components

 Quick initial reviews occur

 Encourages customer feedback.

 Integration from very beginning solves a lot of

integration issues.
RAD model
 Disadvantages of RAD Model
 Depends on strong team and individual performances for
identifying business requirements. Only system that can
be modularized can be built using RAD
 Requires highly skilled developers/designers.

 High dependency on modelling skills

 Inapplicable to cheaper projects as cost of modelling

and automated code generation is very high
Agile model
 Agile is an umbrella term for a set of methods and
practices based on the values and principles
expressed in the Agile Manifesto that is a way of
thinking that enables teams and businesses to
innovate, quickly respond to changing demand,
while mitigating risk.
 Organizations can be agile using many of the
available frameworks available such as Scrum,
Kanban, Lean, Extreme Programming (XP) and etc.
Agile model
 Agile development is one kind of iterative and
Incremental development model.
 Where Software is developed in incrementally,
rapid cycles.
 Which gives in small incremental releases with each
and every release building on previous functionality?
 In every each release is thoroughly tested to ensure
software quality is maintained or not.
 Which used for time critical applications.
Agile model
Agile model
 Advantages of Agile
 Agile methodology has an adaptive team which is able
to respond to the changing requirements.
 The team does not have to invest time and effort and
finally find that by the time they delivered the product,
the requirement of the customer has changed.
 Face to face communication and continuous inputs from
customer representative leaves no space for guesswork.
 The documentation is crisp and to the point to save time.
 The end result is the high quality software in least
possible time duration and satisfied customer.
Agile model
 Disadvantages of Agile
 In case of some software deliverables, especially the large
ones, it is difficult to assess the effort required at the
beginning of the software development life cycle.
 There is lack of emphasis on necessary designing and
documentation.
 The project can easily get taken off track if the customer
representative is not clear what final outcome that they want.
 Only senior programmers are capable of taking the kind of
decisions required during the development process. Hence it
has no place for newbie programmers, unless combined with
experienced resources.
Iterative model
 It does not attempt to start with a full specification
of requirements by first focusing on an initial,
simplified set user features, which then progressively
gains more complexity and a broader set of
features until the targeted system is complete.
 When adopting the iterative approac h, the
philosophy of incremental development will also
often be used liberally and interchangeably.
Iterative model
Iterative model
 This process is then repeated, producing a new
version of the software for each cycle of the model.
 We use Iterative model in these situations.
 Requirements of the complete system are clearly
defined and understood,
 When the project is big.

 Major requirements must be defined; however, some

details can evolve with time.
 Iterative model
 Advantages of Iterative Model
 We can only create a high-level design of the application before
we actually begin to build the product and define the design
solution for the entire product. Later on we can design and built a
skeleton version of that, and then evolved the design based on
what had been built.
 We are building and improving the product step by step. Hence
we can track the defects at early stages. This avoids the
downward flow of the defects.
 We can get the reliable user feedback. When presenting sketches
and blueprints of the product to users for their feedback, we are
effectively asking them to imagine how the product will work.
 Less time is spent on documenting and more time is given for
designing.
 Iterative model
 Disadvantages of Iterative Model
 Each phase of iteration is rigid with no overlaps
 Costly system architecture or design issues may arise
because not all requirements are gathered up front for
the entire lifecycle
Spiral model
 It is a risk-driven software development process model
w h i c h wa s i n t r o d u c e d f o r d e a l i n g w i t h t h e
shortcomings in the traditional waterfall model.
 The exact number of loops of the spiral is unknown
and can vary from project to project.
 This model supports risk handling, and the project is
delivered in loops.
 Eac h loop of the spiral is called a Phase of the
software development process.
 The initial phase of the spiral model in the early
stages of Waterfall Life Cycle that is needed to
develop a software product.
Spiral model
Spiral model
 Requirements are collect during the planning phase.
 In the risk analysis phase, a process is going on to
identify risk and their alternate solutions.
 A prototype is produced at the end of the risk
analysis.
 The evaluation phase permits the customer to assess
the output of the project to date before the project
goes to the next spiral.
Spiral model
 The advantages of spiral model are
 Was designed to include the best features form
Waterfall and Prototyping Model
 Good for large and mission-critical projects

 Introduces a new component – risk assessment

 Similar to prototyping model, an initial version of

system is developed and modified based on input from
customer
Spiral model
 The disadvantages of the spiral model are
 Can be a costly model to use
 Risk analysis requires highly specific expertise

 Project’s success is highly dependent on risk analysis

phase
 Doesn’t work well for smaller projects
 Read the papers
[Link]
[Link]

[Link]
[Link]
SDLC OR PHASES OF SOFTWARE
PROCESS MODEL
Factors affecting the Choice of Models
in the Software Industry
 Nature of Project
 Project size Project duration

 Project complexity

 Level and type of expected risk

 Level of understanding of user requirement

 Level of understanding of the application area

 Customer Involvement

 Experience of developers

 Team size

 Man-machine interaction

 Availability of tools and technology

 Version of the product

 Level of consistency require

Reference: Factors Affecting the Choice of Software Life Cycle Models in the Software
Industry-An Empirical Study Journal of Computer Science 8 (8): 1253-1262, 2012ISSN
1549-3636 © 2012 Science Publications
Comparison chart of various model
based on usage

Reference: Factors Affecting the Choice of Software Life Cycle Models in

the Software Industry-An Empirical Study Journal of Computer Science 8
(8): 1253-1262, 2012ISSN 1549-3636 © 2012 Science Publications
Reading
 Structured System Analysis and Design
 Object Oriented System Analysis and Design
Difference Between Structured and
Object-oriented analysis
Difference Between Structured and
Object-oriented analysis
Summary
 The requirements engineering process is a structured set
of activities which lead to the production of a
requirements document.
 Inputs to the requirements engineering process are
information about existing systems, stakeholder needs,
organisational standards, regulations and domain
information.
 Requirements engineering processes vary radically from
one organisation to another. Most processes include
requirements elicitation, requirements analysis and
negotiation and requirements validation.
Summary
 Requirements engineering process models are
simplified process description which are presented
from a particular perspective.
 Human, social and organisational factors are
important influences on requirements engineering
processes.
 Requirements engineering process improvement is
difficult and is best tackled in an incremental way.
 Requirements engineering processes can be
classified according to their degree of maturity