Week 11 Requirements Management

1. Requirements Management

REQUIREMENTS
MANAGEMENT
DR. CHANDRA REKA

2. OUTLINE

CONCEPT OF REQUIREMENTS MANAGEMENT
PROCESS AND IMPORTANCE
REQUIREMENT RISK
REQUIREMENT TRACKING

3. Learning Outcomes

At the end of this lesson, you should be able to:
◦ - Describe the concept of requirements management
◦ - Discuss the process involved in requirements management
◦ - Elaborate the importance of Requirement change management
◦ - examine the Requirement Tracking process
◦ - Identify the Requirement risk
SWE307
3

4. Why Requirements Management?

• Better requirements validation
• Cope with complexity
• Manage change
• More agility
• Manage subcontractor value
• Better project efficiency
chain
• Better project governance
• Lower risk of project failure
• Control project scope
• Meet compliance mandates
• Deliver what the customer
• Get to market faster
needs
• Prove contractual
• More stakeholder engagement completeness
SWE307
4

5. Smarter products & systems are changing our planet

Smarter products & systems are changing our planet
Smarter automobiles
Smarter health care
Smarter devices
Source: IBM
SWE307
Smarter energy
Smarter defense systems
5

6. Estimated lines of code: Roughly 100 million

◦ You might be surprised to find out
that the software used to run some
high-end vehicles can run to into the
hundreds of millions of lines. This
code is usually used to run and
monitor various parts of a car's
engine, but is also used in features
like entertainment, dashboard, and
security systems.
https://interestingengineering.com/whats-thebiggest-software-package-by-lines-of-code

7. Estimated lines of code: About 61 million

◦ Another of the world's largest software packages by
lines of code is Facebook. Estimated to require over 60
million lines to operate, this social media giant has been
repeatedly refined since its release in 2004.
https://interestingengineering.com/whats-thebiggest-software-package-by-lines-of-code

8. Software Is Driving Much of the Value as System Complexity Grows

Software Is Driving Much of the Value as
• F-22 Raptor,
System Complexity Grows
released in 2003,
Automotive
• 90% of innovation is
based on
electric/electronic
systems
Aerospace &
Defense
contains 1.7
million lines of
code
• F-35 Lightning II,
scheduled for
2010, will have
5.7 million lines
of code
• 80% of this innovation
is based on embedded
software
“Embedded software has evolved from a hidden component driving functionality to the
keystone of product differentiation and end-user experience.”
VDC Research, October, 2008
SWE307
Source: IBM
8

9. Software Is Driving Much of the Value as System Complexity Grows

Lines of codes
Software Is Driving Much of the Value as
System Complexity Grows
Source: informationisbeautiful.net
SWE307
9

10. Poor Requirements Management =Impact on your Business

Requirements Rework
Errors, late detected in the Maintenance phase
can cost up to 200 times more than detected
early in Requirement Analysis phase1
More than 40% of development budget
can be consumed by poor requirements2
Project Impacts
41% of projects fail to deliver the expected
business value and ROI
49% of projects overrun original estimates3
28% of projects on time and on budget4
Project Delays
Being late to market by 6 months or more will cost
organizations 33% of the 5-year ROI5
Requirements issues drive excessive rework,
delays, poor quality, and project failures
200
Relative Cost to Repair
Time not spent in
requirements is time
spent in rework
(at cost x200)
50
20
10
5
1-2
0
Analysis
Design
Coding
Unit Test
Acceptance
Test
Stage in which Requirements Error Is Discovered
“Our research indicates 80-plus percent of development failures result directly from
poor requirements gathering, management, and analysis.”
SWE307
Maintenance
IDC, November 2007
Source: IBM
10

11. Project Failure and Success Factors

◦ The Standish Group 1994 CHAOS study reports that the three most
common causes of project failure are:
◦ - lack of user input,
◦ - incomplete requirements and
◦ - changing requirements.
◦ The three most important factors for project success are:
◦ - user involvement
◦ - executive management support (Source: Standish Group Report, 2014)
◦ - a clear statement of requirements

12. Requirements Management

Requirements management encompasses those tasks that
record and maintain the evolving requirements and
associated context and historical information from the
requirements engineering activities.
Requirements management also establishes procedures for
defining, controlling and publishing the baseline requirements
for all levels of the system-of- interest. Effective requirements
ISO/IEC/IEEE 29148:2018(E)(2018)
management occurs within the context of Source:
an organization's
project and technical processes
SWE307
12

13. Requirements Management

• Requirements Engineering development deliverables
comprise of:
vision, scope, use-case, specification, data dictionary
requirements baseline of the development effort
requirement agreement between customer and developer
agreement is the bridge between requirements Development
and Management
• Requirements Management is about managing
changes to the above
systematic approach to eliciting, organizing, documenting,
and targeting system requirements
SWE307
13

14. The purpose of Requirements Management

◦ The purpose
of requirements
management is to ensure
that the organization
validates and meets the
needs of its customers
and external and internal
stakeholders.

15. Requirements Management Involves

Requirements document :
controlling changes to the requirements
keeping project plans current with the requirements
controlling versions of both individual requirements and requirements
documents
tracking the status of the requirements
managing the logical links between individual requirements and
other project work products
SWE307
15

16. Example

17. Major Requirements Management Activities

SWE307
17

18. Requirements Change Management

◦ There are procedures, processes, and standards
which are used to manage changes to system
requirements
◦ Change management policies may cover:
change request process and the information
required to process each change request
process used to analyse the impact and costs of
change and the associated traceability
information
membership of the body that formally considers
change requests
software support (if any) for the change control
process
◦ A change request may have a status as well as
requirements
E.g., proposed, rejected, accepted, included...
SWE307
18

19. Change Management Process

◦ Some requirements problem is identified
could come from an analysis of the requirements, new customer needs, or
operational problems with the system
the requirements are analysed using problem information and requirements
changes are proposed
◦ The proposed changes are analysed
how many requirements (and, if necessary, system components) are affected?
roughly how much would it cost, in both time and money?
◦ The change is implemented
a set of amendments to the requirements document or a new document
version is produced (of course this should be validated with whatever normal
quality checking procedures are in place)
SWE307
19

20. Sources of Change

◦ New market conditions dictate changes to product requirements or business rules
◦ New customer needs demand modification of data, functionality, or services
◦ Business reorganization causes changes in project priorities or SE team structure
◦ Budgetary or scheduling constraints require system to be redefined
20

21. Change Requests

◦ Requests can come from users, customers, or management
◦ Change requests should be carefully analyzed as part of the
maintenance process before they are implemented
◦ Some changes requests must be implemented urgently due to their
nature
◦ fault repair
◦ system environment changes
◦ urgently required business changes
21

22. Change Request Form

SWE307
• Proposed changes are usually
recorded on a change request
form which is then passed to all
of the people involved in the
analysis of the change
• Change request forms may
include
date, Customer, Requester,
Product including version
description of change
request including rationale
fields to document the
change analysis
signature fields
status
comments
22

23. Factors that influences change

1. The consequences of not making the change
When assessing a change request, you have to consider what will happen if the change is not implemented.
2. The benefits of the change
Will the change benefit many users of the system, or will it only benefit the change proposer?
3. The number of users affected by the change
If only a few users are affected, then the change may be assigned a low priority. In fact, making the change
may be inadvisable if it means that the majority of system users have to adapt to it.
4. The costs of making the change
If making the change affects many system components
5. The product release cycle
If a new version of the software has just been released to customers

24. Change Prediction

24
Change Prediction
• Predicting the number of changes requires understanding the relationships between a
system and its environment
• Tightly coupled systems require changes whenever the environment changes
• Factors influencing the system/environment relationship
◦ number and complexity of system interfaces
◦ number and volatility of system requirements
◦ business processes where the system is used

25.

EXERCISE 1
01
CASE STUDY:
“MySejahtera is a mobile application developed by the Government of Malaysia to facilitate
contact tracing efforts in response to the COVID-19 pandemic in Malaysia. The main goal is quick
identification of persons who may have come into close contact with anyone who has tested
positive for COVID-19”
What are the factors that influence the decision on whether or not a change should be
Implemented in MySejahtera application?
Post your discussion in the MS Teams
** You may use any contact tracing application of your choice- China,
Tunisia, Indonesia, etc.

26. Requirements Management part II

DR. CHANDRA REKA
REQUIREMENTS
MANAGEMENT PART
II

27. Version Control Terms

◦ Entity
◦ composed of objects at the same revision level
◦ Variant
◦ a different set of objects at the same revision level and coexists with
other variants
◦ New version
◦ defined when major changes have been made to one or more
objects
27

28. Tools for Change Management

• Tool facilities may include:
Electronic change request forms which are filled in
by different participants in the process
A database to store and manage requests
A change model which may be instantiated so
that people responsible for one stage of the
process know who is responsible for the next
process activity
Electronic transfer of forms between people with
different responsibilities and electronic mail
notification when activities have been completed
Electronic signatures
Discussion forums
In some cases, direct links to a requirements
database
SWE307
28

29. Example – DOORS Change Proposal System

https://www.youtube.com/watch?v=G65e5yaxlAI
SWE307
29

30. Requirements Tracking - Status

Proposed - requested by an authorised source
Approved – has been analysed, it impact on the project, been estimated and
allocated to the baseline
Implemented – code that implements the requirement has been designed, written
and unit tested., and can be raced to the design and code elements.
Verified – the correct functioning of the requirement has been confirmed, the
requirement has been traced to test cases
Deleted – removal of an approved requirement from the baseline with supporting
explanation
Rejected – a proposed requirement but is not planned for implementation with
supporting explanations
SWE307
30

31. Requirements Version Control

Each circulated version of the
requirements documents should include a
revision history that identifies the changes
made, the date of each change the
individual who made the change
- Eg. Simplest way is to manually label
each revision
- Using Microsoft word-processing
revision features
- More sophisticated techniques, use
version control tools
SWE307
31

32. Distribution of Requirements status throughout the project

Tracking the distribution of requirements status throughout a project’s development cycle.
(Source: Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2011)
SWE307
32

33. Tracing Requirements

Requirements traceability identifies and documents the lineage of
each requirement, including its backward traceability, its forward
traceability, and its relationship to other requirements. Traceability is
used to help ensure that the solution conforms to requirements and to
assist in scope, change, risk, time, cost, and communication
management. It is also used to detect missing functionality or to identify
if there is implemented functionality that is not supported by any
requirement.
Source: BABOK (2015)
SWE307
33

34. Tracing Requirements

Traceability
It is the links that follow the life of a requirement both forward and
backward, ie. from origin through implementation, to facility
traceability requirements
It must be uniquely and persistently labeled
write requirements in fine-grained fashion rather than large
paragraphs containing several requirements (specific, measurable,
realiable)
SWE307
34

35. Four types of Tracing Requirements

1. Forward traceability :
to facilitate which requirements will be affected when
changes are done
2. Backward traceability:
customers needs to identify the origin of each requirement eg.
via use cases
3. Forward from requirements
Defining the links to specific product elements, to ensure every
requirement has been transformed to a component
4. Backward to requirements
Everyone can be aware on why each requirement was created
SWE307
35

36. Tracing Requirements can help…

- detect implied legitimate requirements, unexpected
functionalities with no corresponding requirements
or “orphan” code which indicates gold plating.
- Unimplemented requirements via test cases derived
from and traced back to requirements
SWE307
36

37. Requirements Tracking Benefits

• Certification – of safety critical products, all requirements are implemented
• Change impact analysis – avoid overlooking systems elements that would be
affected
• Maintenance – facilities making changes correctly and completely.
• Project tracking - accurate record of implementation status
• Reengineering – transferring from legacy systems to new systems
• Reuse – facilitate reusing product components of related requirements
• Testing – knowing which test relates to which requirements.
SWE307
37

38. Requirements Traceability Matrix

SWE307
38

39. Requirements Risk

Software project may encounter various types of risks:
• Technical risks include problems with languages, project size, project
functionality, platforms, methods, standards, or processes. These risks
may result from excessive constraints, lack of experience, poorly
defined parameters, or dependencies on organizations outside the
direct control of the project team.
• Management risks include lack of planning, lack of management
experience and training, communications problems, organizational
issues, lack of authority, and control problems.
Boehm (1989)
SWE307
39

40. Requirements Risk

Software project may encounter various types of risks:
• Financial risks include cash flow, capital and budgetary issues, and
return on investment constraints.
• Contractual and legal risks include changing requirements, marketdriven schedules, health & safety issues, government regulation, and
product warranty issues.
• Personnel risks include staffing lags, experience and training
problems, ethical and moral issues, staff conflicts, and productivity
issues.
• Other resource risks include unavailability or late delivery of
equipment & supplies, inadequate tools, inadequate facilities,
distributed locations, unavailability of computer resources, and slow
response times.
Boehm (1989)
SWE307
40

41. Requirements Risk

• part of software
development
• frequently identified
intuitively, but a formal risk
management process is
needed
• Barry Boehm (1998)
proposed a formal risk
management process
Boehm (1989)
SWE307
41

42. Risk Management Process

Risk Identification
• list all conceivable risks
• use creative methods, e.g. brainstorming, and analytical
methods or risk checklist
Risk Analysis
• evaluates the risks
• determines the probability of occurrence
• identifies the possible negative effects for each risk
Boehm (1989)
SWE307
42

43. Risk Identification Checklist

• managers and
system engineers
may use to help
identify and
resolve the most
serious risk items
on the project
Boehm (1989)
SWE307
43

44. Risk Management Process

Risk Prioritization
• specify the sequence in which the risks are to be dealt with
• losses caused when risk occur are evaluated
• order risk items, determine which are most important
• use a scale of 0 - 10
Risk Management Planning
• specify measures intended to reduce the probability of risk
events occurring
• diminish the negative impacts following the occurrence of
the risk event
SWE307
44
Boehm (1989)

45. Risk Management Process

Risk Resolution
• defined measures are carried out
• implement whatever prototypes, simulations, benchmarks, surveys,
or other risk reduction techniques are called for in the plans
Risk Monitoring
• keeps track of the efficiency of the measures implemented
• ensures risk resolution process is a closed-loop process by tracking
risk reduction progress and applying whatever corrective action is
necessary to keep the risk-resolution process on track
Boehm (1989)
SWE307
45

46.

EXERCISE 2
02
Change is a fact of life for large software systems such as Grab. Organizational needs and
requirements change during the lifetime of a system, bugs have to be repaired, and systems
have to adapt to changes in their environment. Grab as shown in Figure 1, has undergone such
changes. The app has transformed from a simple e-hailing service into an all-encompassing
app which includes services such as food delivery, hotel bookings, grocery and package
delivery, and financial services. Though the changes were made, change management was
adapted to ensure that the evolution of the system is controlled and that the most urgent and
cost-effective changes are prioritized.
Figure 1: Grab Application
Explain the factors that influence the decision on whether or not a change should be
implemented.

47. Reference Materials

◦ Boehm, B. W. (1989). Tutorial: Software Risk Management, IEEE Computer Society.
◦ informationisbeautiful.net (2015). Codebases. Millions of Lines of Codes.
https://informationisbeautiful.net/visualizations/million-lines-of-code/
◦ ISO/IEC/IEEE. (2018). Systems and software engineering — Life cycle processes — Requirements engineering.
ISO/IEC/IEEE 29148:2018(E).
◦ https://interestingengineering.com/whats-the-biggest-software-package-by-lines-of-code
SWE307
47