REQUIREMENT ENGINEERING

JIMMA UNIVERSITY
JIMMA INSTITUTE OF TECHNOLOGY
FACULTY OF COMPUTING AND INFORMATICS

CHAPTER SIX

REQUIREMENTS MANAGEMENT
 Topics we will cover
2

 Requirements Management

 Requirements change factors

 Stable and volatile requirements

 Best practices for requirements management

 Requirement management planning and process

What should you care about in the
software development
3
process?

Discussion
 What should I care about ?
4

 Fewer requirements defects

 Reduce development rework
 Fewer unnecessary features
 Lower enhancement costs
 Faster development How?
 Fewer miscommunications
 Reduced scope creep
 Reduced project Chaos
 More accurate system testing estimates
 High customer and team members satisfaction
 Requirements Management
5
 The process of managing changes to the requirements for a
system
 Requirements cannot be managed effectively without
requirements traceability.
 A requirement is traceable if you can discover who suggested
the requirement, why the requirement exists, what
requirements are related to it and how that requirement
relates to other information such as systems designs,
implementations and user documentation.
 Good requirement management planning and process allows
you to execute that plan, helping to reduce costs, accelerate time
to market and improve quality control.
 “The purpose of requirements management is to ensure product
development goals are successfully met.”
 Change - A Constant
6

 No matter where you are in the system life cycle the system
will change, and the desire to change it will persist
throughout the life cycle.
 Change always has a price
 Knowledge of knowing more about things motivates us for
changes.
Where do requirement changes come
from? 7

Discussion
Where do requirement changes come
from?
8
What do you think are the factors for
requirements change
9
?

Discussion
 Requirements Change Factors

 Requirements for complex systems are continuously changing (during

RE process and after a system has gone into service) because of
 Requirements errors, conflicts and inconsistencies

 As the system development proceeds, some errors and

inconsistencies may be discovered that were not revealed earlier
(in validation) and must be corrected.
 Evolving customer/end-user knowledge of the system

 Customers and end-users may develop a better understanding of

what they really require from a system.
 Technical, schedule or cost problems

 Problems may be encountered in implementing a requirement. It

may be too expensive or take too long to implement certain
requirements.
10
 Requirements Change Factors

 Changing customer priorities

Customer priorities change during system development as a

result of a changing business environment, the emergence of new
competitors, staff changes, etc.
 Environmental changes
 The environment in which the system is to be installed may
change so that the system requirements have to change to
maintain compatibility.
 Organizational changes
 The organization which intends to use the system may change its
structure and processes resulting in new system requirements.
 New Technology
 technology push
11
Main Concerns in Requirements Management
12

 The principal concerns of requirements management are:

 Managing changes to agreed requirements
 Managing the relationships between requirements
 Managing the dependencies between the requirements
document and other documents produced in the systems
engineering process
 Stable and Volatile Requirements
13

 Some requirements are usually more subject to change than others

 Stable requirements are concerned with the essence of a system

and its application domain. They change more slowly than volatile
requirements.
 E.g. Student detail in student information system
 Volatile requirements are specific to the instantiation of the
system in a particular environment and for a particular customer.
 E.g. In a hospital, requirements derived from health-
care policy
 Types of Volatile Requirements
14
 Mutable requirements
 These are requirements which change because of changes to the
environment in which the system is operating
 Example
 The requirements for a system which computes tax deductions evolve as
tax laws are changed
 In hospital system, the funding of patient care may change and thus
require different treatment information to be collected.
 Emergent requirements
 These are requirements which cannot be completely defined when
the system is specified but which emerge as the system is designed
and implemented.
 Requirements emerge; as the system is designed & implemented and
as users have contact with new system.
 Types of Volatile Requirements
15
 Consequential requirements
 These are requirements which are based on assumptions about how
the system will be used. When the system is put into use, some of
these assumptions will be wrong.
 Requirements that result from the introduction of the new digital
system.
 Introducing the new digital system may change the organizations
processes and open up new ways of working which generate new
system requirements .
 Compatibility requirements
 These are requirements which depend on other equipment or
processes.
What do you think are the best practices
for requirements management?
16

Discussion
 Best Practices for Requirements
Management
17

 Requirements traceability: Link individual artifacts to test cases for full visibility of

changes in engineering requirements as they happen. Capture all annotations, maintain

them and make them easily accessible.
 Variant management: Digitally manage the entire version and variant process while

monitoring the progression of the system through a shared dashboard. Store data in a
central location and present it in document format. Application Lifecycle Managment
tools are used.
 Engineering compliance: Incorporate industry standards and regulations into your

requirements to achieve compliance early on. Building compliance into the end-to-end
engineering lifecycle makes achieving compliance less complex.
 Agile management: Streamline engineering processes to enable global collaboration

and the reality of a single source of truth. Build confidence in the teams doing the work by
showing them the value of their efforts in real time.
Requirement Management Planning and
Process
18
 Change Control
19

 Change control/management is concerned with procedures, processes and

standards which are used to manage changes to system requirements.
 Requirements changes may lead to overruns in project’s schedule, budget,
negative impact on the product’s quality.
 Therefore, there is need for change impact analysis, and decision
making whether to approve a change request at all or not.
 Change management policies (plan of action) may cover:
 Change request process

 The information required to process for each change request

 The process used to analyze the impact and costs of change and the
associated traceability information
 Change Request Board (should be independent)

 The software support (if any) for the change control process
Activities for change management process
20

 The change management process has three main activities.

 Identifying requirements problem
 Caused by analysis of the requirements, new customer needs, or
operational problems
 Requirements changes are proposed (specified)
 Analyzing proposed changes
 Check how many requirements (and, if necessary, system
components) are affected
 Time and money, to make the change.
 Implementing changes
 A set of modifications to the requirements document or a new
document version has to be validated (quality checking
procedures)
 Remember
21

 Requirement change requests may be rejected: reasons for

rejection
 Change request is invalid: customer has misunderstood some
requirements, proposed change isn’t necessary
 Too many dependent requirements: consequential changes are
unacceptable to the user
 Costs are too high or take too long
 Version Control
22

 A: I finally finished implementing the multivendor catalog query feature

 B: Oh, the customers canceled that feature two weeks ago…
 A: What do you mean? This feature is on the page 6 of my latest SRS.
 B: It is not in my copy. I have version 1.5. What version do you have?
 A: My says ‘version 1.5’ also. These documents should be identical, but
obviously they are not. So, is this feature still in the baseline or did I just waste
40 hours of my life?

 The conversation depicts that people waste time working from

obsolete or inconsistent requirements.
 Each revision of the requirements document must be uniquely
identified according to a standard convention
 Version 1.0 draft 1  Version 1.0 draft 2 …Version 1.1
 Requirements Status Tracking
23

 How are you coming on that subsystem, Betty?

 Pretty good, Dave. I’m about 90 percent done.
 Hmm.. Weren’t you 90 percent done a couple of weeks ago?
 I thought I was, but now I’m really 90 percent done.

 “The first half of a software project consumes the first 90% of the
resources and the second half consumes the other 90% of the
resources.”
 For controlling better how the project proceeds, the
implementation status of each requirement should be monitored.
 This provides a more accurate gauge of project progress.
 Possible Requirement Statuses
24
 At every moment, each requirement is one of the following:
 Proposed – the requirement has been proposed by an
authorized source
 Approved – the requirement has been included into the
approved baseline of a requirements document.
 Implemented – the code that implements the requirement has
been designed and written.
 Verified – the correct functioning of the implemented
requirement has been confirmed in the integrated product.
 Deleted – an approved requirement has been removed from the
baseline, for a reason.
 Rejected – a proposed requirement was not approved for a
reason.
 Requirements Tracing
25

 Traceability information is information which helps you assess

the impact of requirements change.
 It links related requirements and other system representations
 Requirements are the first layer in the software development
work products hierarchy – so, a change in requirements affects
everything: design, code, tests.
 There are also several levels of requirements: features, use cases,
functional requirements – a change in an upper level affects the
lower levels.
 Therefore, links among requirements, as well as links between
requirements and other work products must be maintained –
requirements tracing.
 Requirements Identification
26

 It is essential for requirements management that every

requirement should have a unique identification
 The most common approach is requirements numbering based on
chapter/section in the requirements document
 Problems with this are:
 Numbers cannot be unambiguously assigned until the document
is complete
 Assigning chapter/section numbers is an implicit classification of
the requirement. This can mislead readers of the document into
thinking that the most important relationships are with
requirements in the same section
 Requirements Identification Techniques
27

 Dynamic renumbering
 Some word processing systems allow for automatic renumbering of
paragraphs and the inclusion of cross-references. As you re-organize
your document and add new requirements, the system keeps track of
the cross-reference and automatically renumbers your requirement
depending on its chapter, section and position within the section
 Database record identification
 When a requirement is identified it is entered in a requirements
database and a database record identifier is assigned. This database
identifier is used in all subsequent references to the requirement
 Symbolic identification
 Requirements can be identified by giving them a symbolic name
which is associated with the requirement itself. For example, EFF-1,
EFF-2, EFF-3 may be used for requirements which relate to system
efficiency
 Storing Requirements
28

 Requirements have to be stored in such a way that they can be

accessed easily and related to other system requirements

 Possible storage techniques are

 In one or more word processor files - requirements are stored

in the requirements document
 In a specially designed requirements database
 Traceability
29

 Traceability information is information which helps you assess the

impact of requirements change. It links related requirements and
the requirements and other system representations
 Types of traceability information
 Backward-from traceability: Links requirements to their
sources in other documents or people
 Forward-from traceability: Links requirements to the
design and implementation components
 Backward-to traceability: Links design and implementation
components backs to requirements
 Forward-to traceability: Links other documents (which may
have preceded the requirements document) to relevant
requirements.
 Types of Traceability
30
 Requirements-sources traceability
 Links the requirement and the people or documents which
specified the requirement
 Requirements-rationale traceability
 Links the requirement with a description of why that
requirement has been specified.
 Requirements-requirements traceability
 Links requirements with other requirements which are, in
some way, dependent on them. This should be a two-way
link (dependents and is dependent on)
 Types of Traceability
31

 Requirements-architecture traceability
 Links requirements with the sub-systems where these
requirements are implemented. This is particularly important
where sub-systems are being developed by different sub-
contractors
 Requirements-design traceability
 Links requirements with specific hardware or software
components in the system which are used to implement the
requirement
 Requirements-interface traceability
 Links requirements with the interfaces of external systems
which are used in the provision of the requirements
 Key Points
32

 Requirements Management

 Requirements change factors

 Stable and volatile requirements

 Best practices for requirements management

 Requirement management planning and process

Any Question?

33