“Requirements” ? - According to IEEE standard 729 Importance of Requirement Specification Boundary of two worlds Why is it so Hard? Building the right system right Requirement may solve the dual function Requirements Type of Requirements Types of System/Software Requirements Requirement Engineering Problems with natural language The Requirements Engineering Process Feasibility Study Feasibility study issues Requirements Elicitation Requirements Analysis Requirements Specifications Requirements Validation and Verification Validation Vs. Verification

1. Software
Engineering L4
Sameera
Gunathilaka
Lead Software
Engineer
ERP Technical
Consultant
IT1204 – Software Engineering
Institute of Technology, University of Moratuwa
1

2. SDLC –
Waterfall
Model
IT1204 – Software Engineering Institute of Technology, University of Moratuwa 2

3. “Requirements” ?
The requirements themselves are the
descriptions of the system services and
constraints that are generated during the
requirements engineering process.
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 3

4. According to IEEE standard 729, a
requirement is..
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 4
A condition or capability needed by a user to solve a problem or achieve
an objective
A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification or other
formally imposed documents
A documented representation of a condition or capability as in above two

5. Importance of Requirement Specification
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 5

6. Boundary of two worlds
IT1204 – Software Engineering
Institute of Technology, University of Moratuwa
6

7. Why is it so
Hard?
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 7
We know why projects fail,
we know how to prevent
their failures. So why do they
still fail?
GAP – real world problem vs
computer program
• Strengths of a requirement
• Must/Shall
• Should
• Will

8. Building the right system right
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 8

9. Requirement
may solve the
dual function
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 9
May be the basis for a bid
for a contract
•Therefore must be open to
interpretation
May be the basis for the
contract itself
•Therefore must be defined in
detail

10. Requirements
• “If a company wishes to let a contract for a large
software development project, it must define its needs
in a sufficiently abstract way that a solution is not
pre-defined.
• The requirements must be written so that several
contractors can bid for the contract, offering, perhaps,
different ways of meeting the client organization’s
needs.
• Once a contract has been awarded, the contractor
must write a system definition for the client in more
detail so that the client understands and can validate
what the software will do.
• Both of these documents may be called the
requirements document for the system

11. Type of Requirements
1. Business Requirements
• Why the organization is undertaking the project
• They state some benefits that the developing organization or its customers expect to receive
from the product
• Several documents such as a project charter, business case, or in a project vision and scope
statements
• Problem Statement
• Project Vision
• Project Constraints (Budget, Schedule, and Resources)
• Project Objectives
• Project Scope Statements
• Business Process Analysis
• Stakeholder Analysis
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 11

12. Type of Requirements
2. User Requirements
• Describe what the user does with the system
• An important and difficult step of designing a software product is determining
what the user actually wants it to do
• The information they provide may also be incomplete, inaccurate and self-
conflicting
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 12

13. Type of Requirements
3. System/Software Requirements
• The traditional “shall” statements that describe what the system
“shall do.”
• The building blocks developers use to build the system
• Incorporate both software and hardware components
• It may also include training and organizational change
requirements
• Domain, Functional and Non-Functional requirements
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 13

14. Types of
System/Software
Requirements
IT1204 – Software Engineering Institute of Technology, University of Moratuwa 14

15. Type of System/Software Requirements
Functional Requirements
• End user specifically
demands as basic facilities
that the system should
offer
• Need to be necessarily
incorporated into the
system as a part of the
contract
• Input to be given to the
system, the operation
performed and the output
expected
Non-Functional
Requirements
• Quality constraints that
the system must satisfy
according to the project
contract
• Requires the knowledge
of the functionality of the
system, as well as the
knowledge of the context
within which the system
will operate
Domain Requirements
• Characteristic of a
particular category or
domain of projects

16. Requirement Engineering
Process of
establishing
the needs of
stakeholders
that are to be
solved
by a software
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 16

17. Problems with
natural
language
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 17
Precision is difficult without making the document difficult to readLack of clarity
Functional and non-functional requirements tend to be mixed-up
Requirements
confusion
Several different requirements may be expressed together
Requirements
amalgamation
The readers and writers of the requirement must interpret the same
words in the same way. NL is naturally ambiguous so this is very difficult
Ambiguity
The same thing may be said in a number of different ways in the
specification
Over-flexibility

18. The Requirements
Engineering Process
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 18

19. Requirements
specification
Requirements
validation
Requirements
elicitation
Systemrequirements
specification and
modeling
System
requirements
elicitation
User requirements
specification
User
requirements
elicitation
Business requirements
specification
Prototyping
Feasibility
study
Review s
System requirements
document
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 19

20. Feasibility Study
• Aims to answer three basic questions:
• Would the system contribute to
overall organizational objectives?
• Could the system be engineered
using current technology and within
budget?
• Could the system be integrated with
other systems already in use?

21. Feasibility
study issues
(a high-level
checklist)
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 21
How would the organization cope if the system
wasn’t implemented?
What are the current process problems and how
would the system help with these?
What will the integration problems be?
Is new technology needed? New skills?
What must be supported by the system, and
what need not be supported?

22. Requirements Elicitation
IT1204 – Software Engineering Institute of Technology, University of Moratuwa
It is the practice of
obtaining the
requirements of a
system from users,
customers and
other stakeholders.
The practice is also
sometimes
referred to as
Requirement
gathering.
22

23. Requirements Elicitation
• Guidelines of Requirements Elicitation
• Assess the business and technical feasibility for the proposed system
• Identify the people who will help specify requirements.
• Define the technical environment (e.g. computing architecture, operating system,
telecommunication needs) into which the system or product will be placed
• Identify “domain constraints” (i.e. characteristics of the business environment specific to the
application domain) that limit the functionality or performance of the system or product to build
• Define one or more requirements elicitation methods (e.g. interviews, team meetings, ..etc)
• Solicit participation from many people so that requirements are defined from different point of
views.
• Create usage scenarios of use cases to help customers/ users better identify key requirements.
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 23

24. Requirements Analysis
IT1204 – Software Engineering Institute of Technology, University of Moratuwa
Requirements
Analysis,
determining
whether the
stated
requirements are
clear, complete,
consistent and
unambiguous.
24

25. Requirements
Analysis
Stakeholder Identification
• Stakeholders are people or organizations that have
a valid interest in the system. They may be affected
by it directly or indirectly.
• Stake holders may include:
• Anyone who operates the system
• Anyone who benefits from the system
• Anyone involved in purchasing or procuring
the system
• People opposed to the system (negative
stakeholders)
• Organizations responsible for the system
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 25

26. Requirements
Analysis
Stakeholder Interviews
• Interviews are a common
technique used in requirement
analysis.
• This technique can serve as a
means of obtaining the highly
focused knowledge from different
stakeholders perspectives
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 26

27. Requirements
Specifications
Requirements Specification is the direct result of a
requirement analysis and can refer to:
• Software Requirements Specification
• Hardware Requirements Specification
IT1204 – Software Engineering Institute of Technology,
University of Moratuwa 27

28. Requirements
Validation and
Verification
• Validation (& Verification), is the
process of checking whether the
requirements, as identified, do not
contradict the expectations about the
system of various stakeholders and do
not contradict each other
• Quality control of the requirements
IT1204 – Software Engineering Institute of Technology, University of Moratuwa 28

29. Validation Vs. Verification
Validation: “Am I building the right product?” checking a work product
against higher-level work products or authorities that frame this
particular product.
• Requirements are validated by stakeholders
Verification: “Am I building the product right?” checking a work
product against some standards and conditions imposed on this type of
product and the process of its development.
• Requirements are verified by the analysts mainly
IT1204 – Software Engineering
Institute of Technology, University of Moratuwa
29

30. Thank you
IT1204 – Software Engineering
Institute of Technology, University of Moratuwa
30