Software requirement

1. Software Requirements
Specification & Analysis
Course Code: SE 212
1

2. Course Outline
 Attendance: 07
 Class Test: 15
 Assignment: 05
 Presentation: 08
 Mid Exam: 25
 Final Exam: 40
2

3. Software Engineering
 Software is a program or set of programs containing
instructions that provide desired functionality.
 Engineering is the process of designing and building
something that serves a particular purpose and finds a
cost-effective solution to problems.
 Software engineering includes a variety of techniques,
tools, and methodologies, including requirements
analysis, design, testing, and maintenance.
3

4. Objectives
 To introduce the concepts of user requirements and
system requirements
 To describe the functional and non-functional
requirements
 To explain how software requirements may be organized
in a requirements documents
4

5. Software Requirement
 It is any kinds of requirements which describes
features and functionalities of the desire systems.
 It is expectations of users from a system
 It could be hidden or obvious, known or unknown.
5

6. Software Requirement
 According to IEEE:
 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 1 and 2.
6

7. Types of Software Requirement
 Functional requirements
 Non-functional requirements
 Domain requirements
7

8. Functional Requirements
 It defines what function a system is likely to perform
 The end user specifically demands as basic facilities that
the system should offer.
 It must be directly in the final product.
8

9. Non-functional Requirements
 It defines how the system should perform the system priority
 It extents to which these factors are implemented varies from
one project to other.
 It ensures Portability.
 It ensures Security.
 It ensures Maintainability.
 It ensures Reliability.
 It ensures Scalability.
 Performance
 Flexibility
9

10. Difference Between Functional and Non-
Functional Requirement
Functional Requirement Non-Functional Requirement
It is mandatory. It is not mandatory.
A functional requirement defines a system
or its component.
A non-functional requirement defines the
quality attribute of a software system.
Functional requirement is specified by
User.
Non-functional requirement is specified by
technical peoples e.g. Architect, Technical
leaders and software developers.
Usually easy to define. Usually more difficult to define.
It is captured in use case. It is captured as a quality attribute.
Defined at a component level. Applied to a system as a whole.
10

11. Domain Requirements
 Domain requirements are expectations related to
a particular type of software, purpose or industry
vertical.
 It can be functional or nonfunctional.
11

12. Other common software requirement
 User requirements: These requirements describe what the end-user
wants from the software system.
 System requirements: These requirements specify the technical
characteristics of the software system, such as its architecture,
hardware requirements, software components, and interfaces.
 Regulatory requirements: These requirements specify the legal or
regulatory standards that the software system must meet.
 Interface requirements: These requirements specify the interactions
between the software system and external systems or components,
such as databases, web services, or other software applications.
 Design requirements: These requirements describe the technical
design of the software system.
12

13. Requirement Engineering
 The process to gather the software requirements from
client, analyze and document them is known as
requirement engineering.
 It is a four step process, which includes –
 Feasibility Study
 Requirement Gathering
 Software Requirement Specification
 Software Requirement Validation
13

14. Feasibility Study
 It comes up with rough idea about what all functions the
software must perform
 It is a detailed study about whether the desired system
and its functionality are feasible to develop
 It focuses towards goal of the organization.
 It analyzes whether the software product can be
practically materialized in terms of implementation,
contribution of project to organization, cost constraints
and as per values and objectives of the organization.
14

15. Requirement Gathering
 Gathering requirements from the user.
 Analysts and engineers communicate with the client and
end-users to know their ideas on what the software should
provide and which features they want the software to
include.
15

16. Software Requirement Specification
 SRS is a document created by system analyst after the
requirements are collected from various stakeholders.
 SRS defines how the intended software will interact with
hardware, external interfaces, speed of operation, response
time of system, portability of software across various
platforms, maintainability, speed of recovery after crashing,
Security, Quality, Limitations etc.
 SRS should come up with following features:
 User Requirements are expressed in natural language.
 Technical requirements are expressed in structured language,
which is used inside the organization.
 Design description should be written in Pseudo code.
 Format of Forms and GUI screen prints.
 Conditional and mathematical notations 16

17. Software Requirement Validation
Requirements can be checked against following
conditions -
 If they can be practically implemented
 If they are valid and as per functionality and domain of
software
 If there are any ambiguities
 If they are complete
 If they can be demonstrated
17

18. Software Requirements Characteristics
A complete Software Requirement Specifications must be:
 Clear
 Correct
 Consistent
 Coherent
 Comprehensible
 Modifiable
 Verifiable
 Prioritized
 Unambiguous
 Traceable
 Credible source
19

19. Advantages
 Better organization: Classifying software requirements helps
organize them into groups that are easier to manage, prioritize, and
track throughout the development process.
 Improved communication: Clear classification of requirements makes
it easier to communicate them to stakeholders, developers, and other
team members. It also ensures that everyone is on the same page
about what is required.
 Increased quality: By classifying requirements, potential conflicts or
gaps can be identified early in the development process. This reduces
the risk of errors, omissions, or misunderstandings, leading to higher
quality software.
 Improved traceability: Classifying requirements helps establish
traceability, which is essential for demonstrating compliance with
regulatory or quality standards.
20

20. Disadvantages
 Complexity: Classifying software requirements can be
complex, especially if there are many stakeholders with
different needs or requirements. It can also be time-
consuming to identify and classify all the requirements.
 Rigid structure: A rigid classification structure may limit
the ability to accommodate changes or evolving needs
during the development process. It can also lead to a
siloed approach that prevents the integration of new ideas
or insights.
 Misclassification: Misclassifying requirements can lead to
errors or misunderstandings that can be costly to correct
later in the development process.
21

21. Thank You!
22