Software Requirements Engineering: Shah Nawaz (Lecturer), Department of Software Engineering, LGU

Software Requirements Engineering
What, Why, Who, When,

and How of Software
Requirement Engineering
Shah Nawaz [Lecturer], Department of Software Engineering, LGU

1 What, Why, Who, When, and How
“What” of Software Requirement Engineering:
What a software must do to add value to stakeholders.
Capabilities of a software product are functional requirement. The

characteristics, properties or qualities that software have are nonfunctional
requirements. Business requirement — Why software product is
developed and what problem is solving. It include the object of customer
or requests of organisation.
For example:
Swipe credit card
Enter PIN
Request Receipt
“Why” of Software Requirement Engineering:
Eliciting, analyzing, and writing good requirements are the most difficult
parts of software engineering.
According to Karl Wiegers (2004) : “If you don’t get the requirements right,
it doesn’t matter how well you do anything else.”
There are many issues that can have a negative impact on software
development projects and products if practitioners don’t do a good job of
defining their software requirements.
These issues include:

• Incomplete requirements • Lack of user involvement
• Requirements churn • Wasted resources
• Gold plating • Inaccurate estimates
“Why” of Software Requirement Engineering:
Noritaki Kano developed a

model of the relationship
between customer
satisfaction and quality
requirements
For example, remember

when cup holders in cars
were first introduced? Note
that the entire excited
quality line is in the
satisfied region. It should
be remembered.
“Who” of Software Requirement Engineering:
Stakeholders are individuals who affect or are affected by the software product
and therefore have some level of influence over the requirements for that
software product.
There are three main categories of stakeholders:

 the acquirers,
 suppliers of the software product, and
 other stakeholders.
Acquirer
The acquirer type stakeholders can be divided into two major groups.
o The Customers - who request, purchase, and/or pay for the software product
for their business objectives.
o The Users(end-users) - who actually use the product directly.
“Who” of Software Requirement Engineering:
Suppliers
The suppliers of the software product include individuals and teams that are
part of the organization that develop, distribute or outsource the product.
Other stakeholders include.

• Legal or contract management
• Manufacturing or product release management
• Sales and marketing
• Upper management
• Government or regulator agencies
• Society at large]
“When” of Software Requirement Engineering:
Requirements development encompasses all the activities involved in

identifying, capturing, and agreeing upon the requirements. This includes
the definition and integration of the business requirements, the user
requirements, and software product level requirements.
Requirements management encompasses all of the activities involved in
requesting changes to the baselined requirements, performing impact
analysis for the requested changes, approving or disapproving those
changes, and implementing the approved changes. Requirements
management is an ongoing activity throughout the software development
life cycle.
The implemented software product is validated against its requirements
during the testing phases of the life cycle to identify and correct defects
and to provide confidence that the product meets those requirements.
“How” of Software Requirement Engineering:
Software requirements
engineering is made up
of two major processes:
requirements
development and
requirements
management.
Requirements
development
encompasses all of the
activities involved in
eliciting, analyzing,
specifying, and
validating the
requirements.
“How” of Software Requirement Engineering:
One good practice for requirements specification is to have predefined

templates. So that requirements analyst focus on content instead of format.
The last step in the requirements development process is to validate the
requirements to ensure that they are well written, complete, and will satisfy the
customer needs.One of the primary tools for requirements validation is to
conduct formal peer reviews of the requirements specification documents
before they are base lined.
The peer review process should look at the requirements specification as a

whole to ensure that it is:
Complete, Consistent, Modifiable, Unambiguous, Concise, Finite, Measurable,

Feasible, Testable, Traceable.
Thanks!
Any questions?

Software Requirements Engineering: Shah Nawaz (Lecturer), Department of Software Engineering, LGU

Uploaded by

Copyright:

Available Formats

Software Requirements Engineering: Shah Nawaz (Lecturer), Department of Software Engineering, LGU

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Requirements Engineering: Shah Nawaz (Lecturer), Department of Software Engineering, LGU

Uploaded by

Copyright:

Available Formats

Software Requirements Engineering

What, Why, Who, When,

Shah Nawaz [Lecturer], Department of Software Engineering, LGU

What a software must do to add value to stakeholders.

Capabilities of a software product are functional requirement. The

These issues include:

Noritaki Kano developed a

For example, remember

There are three main categories of stakeholders:

Other stakeholders include.

Requirements development encompasses all the activities involved in

One good practice for requirements specification is to have predefined

The peer review process should look at the requirements specification as a

Complete, Consistent, Modifiable, Unambiguous, Concise, Finite, Measurable,

You might also like