Software Engineering

Practices

Symbiosis International (Deemed University)

1
Unit 2: Software Requirements
Analysis
Dr. Pallawi Bulakh
M.Sc. M.Phil.Ph.D. NET with JRF
(Computer Science and Applications)

2
Software Requirements Analysis:
• Software Requirements Specification Techniques,
• Fact-finding methods Requirements Specifications,
• Software Requirement Specification (SRS),
• requirements definition,
• IEEE standard SRS format,
• Role & Skills of System Analyst.
3
Session Objectives
● To study techniques for eliciting requirements,
● To Develop effective functional and non-functional
requirements.
● To study different fact-finding techniques.
● To exactly document the requirements in SRS
● To explain the critical role of people in requirements
engineering processes
4
Software Requirements
• Software requirements are illustrations about
the attributes and functionalities of the
software product to be built

5
6
Requirement Specification
• The outcome of requirements
specifications is known as Software
Requirement Specification (SRS)
• The requirement specification or
requirement analysis is done in the
following steps:
1.Draw the context Diagram
2.Develop the prototype.
3.Model the requirements.
4.Finalize the requirements. 7
1. Draw the context diagram:
• The context diagram defines the
boundaries and interfaces of the
proposed systems with the external
world.
• It identifies the entities outside the
proposed system that interact with
the system.

8
2. Develop the prototype:

• Prototype is an effective way to

understand customer
requirements.
• Helps in clearly understanding the
user requirements.
• Gives a vision and acceptability of
the user for the right direction.

9
3. Model the requirements
• Graphical representation of the functions, data
and relationship amongst them is done.
• Here, the tools are Data Flow Diagram, Entity-
Relationship diagram, state transition diagram
etc.

10
4. Finalize the requirements:

• Once the requirements are modelled, the system is

understood in a better manner.
• The relationship between the data and entities is well
formulated.
• This helps in creating a finalized document specifying
the requirements in a particular format.

11
 The software requirements are of
three types:
● Functional requirements
● Non-functional requirements
● Domain requirements

12
1. Functional Requirements
• Requirements for which the system is to be built.
• These requirements can be a business process, a user
interaction or any specific functionality that the system
should perform.
• The system is built only for the functional requirement.
• These requirements are the basic part of the agreement
between the customer and the developer.

13
 Functional requirements contd..
• These requirements are prescribed in the
format of input process and output.
• The functional requirements need to be
noted carefully.
• These requirements need multiple user
interactions during the actual performance.
• The functional requirements can be
expressed using natural language processing
or some graphical representations as well.
14
Non-functional requirements:
• These are the minimum integrity constraints that the
system should satisfy as stated in the project contract.
• Not necessarily related to the system functionality.
• These requirements are the quality initiative that the
system must satisfy.

15
Non-functional requirements:
• The non-functional requirements state the system
• Behaviour
• system portability,
• availability,
• scalability,
• reliability,
• performance,
• reusability, etc.
• Can be further classified into Operating constraints,
interface constraints, economic constraints, and life
cycle constraints. 16
3. Domain requirements:

• Domain requirements are

the specific requirements
for a particular category of
projects.
• domain requirements can
be functional or non-
functional.

17
Fact-finding techniques

Fact-finding or requirement elicitation is a technique to

find out the exact specification of the product to be built

18
Interviews
• One to-one type of
Communication to collect
the requirements.
• Interviews are a strong
medium to collect
requirements.
• Interviews prove to be a
powerful medium for the
collection of data.
19
Interviews
• Interviews are either structured or unstructured.
• structured interviews are planned activities and follow a
particular pre-decided pattern.
• Non-structured interviews are not a planned activity
and the type of information collection is not pre-
decided.
• Unstructured interviews are more flexible than
structured interviews.
• Interviews can be conducted through written and oral
mediums. 20
Surveys:

• Organizations conduct surveys to

collect data from various
stakeholders.
• These surveys are queries about
requirements for the product to
be developed.

21
Surveys

• Surveys can be conducted

in online or offline mode.

22
Questionnaires:
• Set of questions and related options for
finding out the answers for the fact
collection or requirement gathering.
• All stakeholders are requested to attempt
• Then the data collected is compiled.
• This data is analyzed using various tools
and statistical techniques.

23
Good questionnaire
1.Have a Goal in Mind
2.Draft Clear and Distinct Answers and
Questions
3.Ask One Question at a Time
4.Check for Bias and Sensitivity
5.Include Follow-Up Questions

24
Observations:
• Observations are a strong
medium to understand the
system thoroughly.
• Here, the analyst duly visits
the organization and
understands the working flow
of the system.

25
Research:
• The research is a fact-finding
technique where the existing
problem is solved with the
abundant amount of
information available on the
internet by applying similar
references to the problem.

26
Software Requirement specification
(SRS)
• The SRS is developed based on the
understanding and agreement between
the customer and the developer.
• The SRS document consists of all the
important necessities required for
software development.

27
SRS
• To get the exact software done,
the customer should have
appropriate and clear
understanding of what he is
looking for.
• This demands continuous
communication with the
customer which in turn delivers
a good SRS document.
28
29
30
Properties of Good SRS
● Concise: The SRS report should be concise and at the
same time correct and unambiguous
● Structured: The SRS document should be in a structured
format and equally well to understand
● Black box view: The SRS document should depict the
functionality of the system but at the same time it
should not depict how the functionality is being achieved31
 Properties of good SRS
● Conceptual integrity: The SRS document should show Conceptual
integrity so that the reader can well understand. It Should be able
to characterize the wanted and unwanted responses in a good
manner.
● Verifiable: All the requirements specified in SRS should be Correct.
● It should be traceable whether all the requirements stated in the
SRS are implemented or not.

32
Requirement definition:
IEEE standard 729, a requirement is defined as follows:
● 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. 33
IEEE standard SRS format:

1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Project Scope
1.5 References 34
IEEE standard SRS format:

2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints 35
IEEE standard SRS format:

3. System Features
3.1 System Feature 1
3.2 System Feature 2 (and so on)

36
IEEE standard SRS format:

4. External Interface Requirements

4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces
37
IEEE standard SRS format:

5. Other Nonfunctional Requirements

5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes

38
IEEE standard SRS format:

6. Other Requirements
Appendix A: Glossary
Appendix B: Analysis Models
Appendix C: Issues List

39
Role and skill of system analyst:

1. Defining user requirements:

1. communicates with the user and their requirements

for the proposed system.

2. methods used to collect such requirements are

interviews or communication with the users.

40
Role and skill of system analyst:

2. Prioritizing requirements: It is the skill set of the system

analyst to prioritize the specifications and finalize the
requirements of the users. The requirements of the users
change according to the needs of the organization.

41
Role and skill of system analyst:
• Prioritizing requirements:
• prioritize the specifications
• finalize the requirements of the users.

42
 Skills of a systems analyst
1.Communication: must have good communication skills
so as to communicate with a lot of people in various
departments.

2.Critical thinking: must have good critical thinking

abilities to understand, evaluate and solve the problem.

43
 Skills of a systems analyst
3.Business analytics: must possess knowledge of business
analysis so as to gain the competitive advantage in
Problem handling with the help of Information
Technology.

4. Technical analysis: A system analyst should be good in

technical areas like programming Information Technology44
Skills of a systems analyst

5. Management: should possess good managerial and

leadership skills so as to handle different people in
different departments of an organization. They also need
good HR values and good management skills.

45
Session Outcomes
In this session, you learned about:
1. Concept of Software, Software Products.
2. The Software Engineering Process.
3. Software Development Process Model and its types.

46
47
Thank You

48