Chapter 2 Software Requirement Analysis and Specification 22.1.2018
Chapter 2 Software Requirement Analysis and Specification 22.1.2018
Chapter 2 Software Requirement Analysis and Specification 22.1.2018
CHAPTER TWO
Software Requirement Analysis
Requirement Analysis
The process of studying and analyzing the customer and the user
needs to arrive at a definition of the problem domain and system
requirements
Objectives:
Discover the boundaries of the new system (or software) and how it
must interact with its environment within the new problem domain
When the client approaches the organization for getting the desired
product developed, it comes up with a rough idea about what all
functions the software must perform and which all features are
expected from the software.
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.
The requirements received from client are written in natural
language.
Questionnaires
A document with pre-defined set of objective questions and
respective options is handed over to all stakeholders to answer, which
are collected and compiled.
A shortcoming of this technique is, if an option for some issue is not
mentioned in the questionnaire, the issue might be left unattended.
Task analysis
Team of engineers and developers may analyze the operation for
which the new system is required. If the client already has some
software to perform certain operation, it is studied and requirements
of proposed system are collected.
Domain Analysis
Every software falls into some domain category. The expert people
in the domain can be a great help to analyze general and specific
requirements.
Brainstorming
An informal debate is held among various stakeholders and all their
inputs are recorded for further requirements analysis.
Prototyping
Prototyping is building user interface without adding detail
functionality for user to interpret the features of intended software
product. It helps giving better idea of requirements.
If there is no software installed at client’s end for developer’s
reference and the client is not aware of its own requirements, the
developer creates a prototype based on initially mentioned
requirements.
The prototype is shown to the client and the feedback is noted. The
client feedback serves as an input for requirement gathering.
Observation
Functional Requirements
Requirements, which are related to functional aspect of software
fall into this category.
They define functions and functionality within and from the
software system.
EXAMPLES -
• Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given
separate rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.
Non-Functional Requirements
User acceptance majorly depends upon how user can use the
software. UI is the only way for users to perceive the system. A
well performing software system must also be equipped with
attractive, clear, consistent, and responsive user interface.