Software Requirement Engineering

1. Lecture No 2 & 3.
1
SOFTWARE REQUIREMENTS ENGINEERING

2. SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
What is SRS?
 Def: A documents use to describe the behavior of the software
system, functional, no-functional requirement of the software
system.
 SRS is a description of a software system to be developed.
 It lays out functional and non-functional requirements of the
software to be developed.
 It may include a set of use cases that describe user interactions
that the software must provide to the user for perfect
interaction. 2

3. SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
 Users of the SRS:
• Development Team
• Maintenance Team
• Clients
• Technical writers
3

4. SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
Contents of the SRS
1. Category: What kind of your software is e.g: Desktop
application, Web based application, Android application
2. Purpose: Describe what is the purpose of making this system
3. Scope: What is the area it covering, what is its range, to what
limits it will help you.
4. Introduction: Define the existing system and proposed system.
(In the perspective how the proposed one is better than existing.)
4

5. SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
Contents of the SRS
5. Advantage: Define the advantage of the system. (In every
perspective).
6. Functional Requirement of the System
7. Non-Functional Requirement of the System
8. Software Tools: Mention the software tools which will
involve in all this development process.
5

6. SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
Contents of the SRS
9. Development: What kind of environment will be needed
to deploy the software. E.g. OS, RAM, Processor etc.
10. Hardware Specifications: The hardware required to
develop this system.
6

7. SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
SRS Structure
1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Scope
1.4 Definitions
1.5 References
2. Overall Description
2.1 User Interfaces
2.2 System Interfaces
2.3 Constraints, assumptions and dependencies
2.4 User characteristics 7

8. SOFTWARE REQUIREMENTS SPECIFICATION (SRS)
SRS Structure
3. System Feature and Requirement
3.1 Functional Requirements
3.2 Use Case
3.3 External Interface Requirement
3.4 Logical database requirement
3.5 Non-functional Requirements
4. Deliver for Approval
8

9. KINDS OF SOFTWARE REQUIREMENTS
1. Functional requirements
2. Non-functional requirements
3. Domain requirements
4. Inverse requirements
5. Design and implementation constraints
9

10. FUNCTIONAL REQUIREMENT
• Statements describing what the system should do.
• Functionality of the system
• Statements of services the system should provide.
• Reaction to particular inputs
• Behavior in particular situations
• Abnormal behavior is also documented as functional
requirements in the form of exception handling.
• Customers and developers usually focus all their attention on
functional requirements.
10

11. FUNCTIONAL REQUIREMENT
• Examples of Functional Requirements
• The user shall be able to search either the entire database of
patients or select a subset.
• Every order shall be allocated a unique identifier (ORDER_ID)
which the user shall use to access that order.
• The system shall allow customers to return non-perishable items
within fifteen days of the purchase. A customer must present the
original sale receipt to return an item.
11

12. FUNCTIONAL REQUIREMENT
• Comments on Functional Requirement:
• Incomplete and ambiguous requirements are open to multiple
interpretations and assumption.
• This can lead to the development of poor quality, or faulty,
software products.
• The level of details are different in all the requirements.
12

13. NON-FUNCTIONAL REQUIREMENT
• Most non-functional requirements relate to the system. They
include constraints on timing, performance, reliability, security,
maintainability, accuracy, the development process, standards,
etc.
• They are often more critical than individual functional
requirements.
• Must be built into the framework of the software product.
• Failure to meet a non-functional system requirement may make
the whole system unusable.
13

14. NON-FUNCTIONAL REQUIREMENT
 Example on Non-functional Requirements
• If an aircraft system does not meet reliability requirements, it will not
be certified as “safe”.
• If a real time control system fails to meet its performance
requirements, the control functions will not operate correctly.
 Observations of Non-Functional Requirements
• Non-functional requirements can be written to reflect general goals
for the system.
• Example include:
• -Ease of use
• Recovery from failure
• Rapid user response
14

15. NON-FUNCTIONAL REQUIREMENT
 Observations of Non-Functional Requirements
• Non-functional requirements are sometimes written as general
goals.
 Verifiable and Unverifiable NFR
o Verifiable
Experienced controllers shall be able to use all the system
functions after a total of two hours ”training. After this training,
the average number of errors made by experienced user shall not
exceed two per day.
15

16. NON-FUNCTIONAL REQUIREMENT
 Verifiable and Unverifiable NFR
o Unverifiable
The system should be easy to use by experienced controllers and
should be organized in such a way that user error are minimised.
16

17. NON-FUNCTIONAL REQUIREMENT
NFR Block Diagram:
17
Non Functional
Requirement
Organizational
Requirements
External
Requirements
Product
Requirements

18. NON-FUNCTIONAL REQUIREMENT
Product Requirement Block Diagram:
18
Product
Requirements
Usability
Requirement
Efficiency
Requirement
Reliability
Requirement
Portability
Requirement
Usability
Requirement
Space
Requirement

19. NON-FUNCTIONAL REQUIREMENT
Organization Block Diagram:
19
Organization
Requirement
Implement Deliver
Standard

20. NON-FUNCTIONAL REQUIREMENT
External Requirement Block Diagram:
20
External
Requirement
Interoperable Ethical Legislative
Privacy
Requirement
Safety

21. NON-FUNCTIONAL REQUIREMENT
 Interoperability
is a characteristic of a product or system, whose interfaces
are completely understood, to work with other products or
systems.
 Legislature
is a deliberative assembly with the authority to make laws
for a political entity such as a country or city.
21

22. NON-FUNCTIONAL REQUIREMENT
Software Metrics for Non-Functional Requirements
22
S.
No
Property Measure
1 Speed • Processed transactions/second
• Response Time
• Screen refresh time
2 Size • K bytes
• Number of function points
3 Ease of use • Training time
• Number of help frames

23. NON-FUNCTIONAL REQUIREMENT
Software Metrics for Non-Functional Requirements
23
S.
No
Property Measure
4 Reliability • Mean time to failure
• Probability of unavailability
• Rate of failure occurrence
• Availability
5 Robustness • Time to restart after failure
• Percentage of events causing failure
6 Portability • Percentage of target-dependent
statements
• Number of target systems

24. DOMAIN REQUIREMENT
 Requirements that come from the application domain and reflect
Fundamentals characteristics of that application domain.
 These can be both the functional or non-functional requirements
 These requirements, sometimes, are not explicitly mentioned
 There absence can cause significant dissatisfaction.
24

25. DOMAIN REQUIREMENT
 Example of Domain Requirement
• Banking domain has its own specific constraints, for
example, banks do not allow over-draw on most accounts,
however, most banks allow some accounts to be overdrawn.
25

26. INVERSE REQUIREMENT
 They Explain what the system shall not do. Many people find it
convenient to describe their needs in this manner.
 These requirements indicate the indecisive nature of customers
about certain aspects of a law software product.
 Example: The system shall not use red color in the user interface,
whenever it is asking for inputs from the end-user.
26

27. DESIGN AND IMPLEMENTATION CONSTRAINTS
 They are development guidelines within which the designer must
work.
 These requirements can seriously limit design and implementation
options.
 Can also have impact on human resources.
27

28. REQUIREMENTS PROBLEMS
 The requirements don’t reflect the real needs of the customers for
the system
 Requirements are inconsistent and/or incomplete
 It is expensive to make changes to requirements after they have
been agreed upon
 There are misunderstandings between customers, those developing
the system requirements, and software engineers developing or
maintaining the system.
28

29. REQUIREMENTS PROBLEMS
 Problems with Natural Languages
o Requirements specification in natural language pose some
problems which include
o Lack of clarity
o Requirements amalgamation
o Requirement confusion
 A natural language requirements specification is over-flexible.
“You can say the same thing in completely different ways”.
 It is not possible to modularized natural language requirements. It
may be difficult to find all related requirements.
29

30. REQUIREMENTS PROBLEMS
 Impact of wrong Requirements
 When requirements are wrong, systems are late, unreliable and
don’t meet customers need.
o This result in enormous loos of time, revenue, market share, and
trust of customers.
30