Requirement Analysis
Software Requirements: Functional & non-functional –
A software requirement can be of 2 types:
Functional requirements
Non-functional requirements
Functional Requirements:
These are the requirements that the end user specifically demands as basic facilities that the
system should offer. All these functionalities need to be necessarily incorporated into the
system as a part of the contract. These are represented or stated in the form of input to be
given to the system, the operation performed and the output expected. They are basically
the requirements stated by the user which one can see directly in the final product, unlike the
non-functional requirements.
For example, in a hospital management system, a doctor should be able to retrieve the
information of his patients. Each high-level functional requirement may involve several
interactions or dialogues between the system and the outside world. In order to accurately
describe the functional requirements, all scenarios must be enumerated.
There are many ways of expressing functional requirements e.g., natural language, a
structured or formatted language with no rigorous syntax and formal specification language
with proper syntax.
Non-functional requirements:
These are basically the quality constraints that the system must satisfy according to the
project contract. The priority or extent to which these factors are implemented varies from
one project to other. They are also called non-behavioral requirements.
They basically deal with issues like:
● Portability
● Security
● Maintainability
● Reliability
● Scalability
● Performance
● Reusability
● Flexibility
NFR’s are classified into following types:
● Interface constraints
● Performance constraints: response time, security, storage space, etc.
● Operating constraints
● Life cycle constraints: maintainability, portability, etc.
● Economic constraints
The process of specifying non-functional requirements requires the knowledge of the
functionality of the system, as well as the knowledge of the context within which the system
will operate.
https://www.geeksforgeeks.org/software-engineering-classification-of-software-requirements/
user-system requirement
The requirements for a system are the descriptions of the services that a system should
provide and the constraints on its operation. These requirements reflect the needs of
customers for a system that serves a certain purpose such as controlling a device, placing
an order, or finding information. The process of finding out, analyzing, documenting and
checking these services and constraints is called requirements engineering (RE).
Some of the problems that arise during the requirements engineering process are a result of
failing to make a clear separation between these different levels of description. we
distinguish between them by using the term user requirements to mean the high-level
abstract requirements and system requirements to mean the detailed description of what the
system should do. User requirements and system requirements may be defined as follows:
User requirements are statements, in a natural language plus diagrams, of what services the
system is expected to provide to system users and the constraints under which it must
operate. The user requirements may vary from broad statements of the system features
required to detailed, precise descriptions of the system functionality.
System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements document (sometimes
called a functional specification) should define exactly what is to be implemented. It may be
part of the contract between the system buyer and the software developers.
Different kinds of requirement are needed to communicate information about a system to
different types of reader. Figure illustrates the distinction between user and system
requirements.
https://collegenote.pythonanywhere.com/curriculum/software-engineering-csit/54/309/
engineering process – feasibility
studies – elicitation – validation & management –
Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed
project or system. Feasibility study is one of stage among important four stages of Software
Project Management Process. As name suggests feasibility study is the feasibility analysis
or it is a measure of the software product in terms of how much beneficial product
development will be for the organization in a practical point of view. Feasibility study is
carried out based on many purposes to analyze whether software product will be right in
terms of development, implantation, contribution of project to the organization etc.
Types of Feasibility Study :
The feasibility study mainly concentrates on bellow five mentioned areas. Among these
Economic Feasibility Study is most important part of the feasibility analysis and Legal
Feasibility Study is less considered feasibility analysis.
Technical Feasibility –
In Technical Feasibility current resources both hardware software along with required
technology are analyzed/assessed to develop project. This technical feasibility study gives
report whether there exists correct required resources and technologies which will be used
for project development. Along with this, feasibility study also analyzes technical skills and
capabilities of technical team, existing technology can be used or not, maintenance and up-
gradation is easy or not for chosen technology etc.
Operational Feasibility –
In Operational Feasibility degree of providing service to requirements is analyzed along with
how much easy product will be to operate and maintenance after deployment. Along with
this other operational scopes are determining usability of product, Determining suggested
solution by software development team is acceptable or not etc.
Economic Feasibility –
In Economic Feasibility study cost and benefit of the project is analyzed. Means under this
feasibility study a detail analysis is carried out what will be cost of the project for
development which includes all required cost for final development like hardware and
software resource required, design and development cost and operational cost and so on.
After that it is analyzed whether project will be beneficial in terms of finance for organization
or not.
Legal Feasibility –
In Legal Feasibility study project is analyzed in legality point of view. This includes analyzing
barriers of legal implementation of project, data protection acts or social media laws, project
certificate, license, copyright etc. Overall it can be said that Legal Feasibility Study is study
to know if proposed project conform legal and ethical requirements.
Schedule Feasibility –
In Schedule Feasibility Study mainly timelines/deadlines is analyzed for proposed project
which includes how many times teams will take to complete final project which has a great
impact on the organization as purpose of project may fail if it can’t be completed on time.
Feasibility Study Process :
The below steps are carried out during entire feasibility analysis.
Information assessment
Information collection
Report writing
General information
Need of Feasibility Study :
Feasibility study is so important stage of Software Project Management Process as after
completion of feasibility study it gives a conclusion of whether to go ahead with proposed
project as it is practically feasible or to stop proposed project here as it is not right/feasible to
develop or to think/analyze about proposed project again.
Along with this Feasibility study helps in identifying risk factors involved in developing and
deploying system and planning for risk analysis also narrows the business alternatives and
enhance success rate analyzing different parameters associated with proposed project
development.
https://www.geeksforgeeks.org/types-of-feasibility-study-in-software-project-
development/
Requirements elicitation (also known as requirements capture and requirements acquisition)
is a process of collecting information about software requirements from different individuals
such as users and other stakeholders. Stakeholders are individuals who are affected by the
system, directly or indirectly. They include project managers, marketing personnel,
consultants, software engineers,maintenance engineers, and the user.
Various issues may arise during requirements elicitation and may cause difficulties in
understanding the software requirements. Some of the problems are listed below.
Problems of scope: This problem arises when the boundary of software (that is, scope) is
not defined properly. Due to this, it becomes difficult to identify objectives as well as
functions and features to be included in the software.
Problems of understanding: This problem arises when users are not certain about their
requirements and thus are unable to express what they require in the software and which
requirements are feasible. This problem also arises when users have no or little knowledge
of the problem domain and are unable to understand the limitations of the computing
environment of the software.
Problems of volatility: This problem arises when requirements change over time.
Requirements elicitation uses elicitation techniques, which facilitate software engineers to
understand user requirements and software requirements needed to develop the proposed
software.
Elicitation Techniques
Various elicitation techniques are used to identify the problem, determine its solution, and
identify different approaches for the solution. These techniques also help the stakeholders to
clearly express their requirements by stating all the important information.
The commonly followed elicitation techniques are listed below.
Interviews: These are conventional ways of eliciting requirements, which help software
engineers, users, and the software development team to understand the problem and
suggest solutions for it. For this, the software engineer interviews the users with a series of
questions. When an interview is conducted, rules are established for users and other
stakeholders. In addition, an agenda is prepared before conducting interviews, which
includes the important points (related to software) to be discussed among users and other
stakeholders. An effective interview should have the following characteristics.
Individuals involved in interviews should be able to accept new ideas. Also, they should
focus on listening to the views of stakeholders related to requirements and avoid biased
views.
Interviews should be conducted in a defined context to requirements rather than in general
terms. For this, users should start with a question or a requirements proposal.
Scenarios: These are descriptions of a sequence of events, which help to determine
possible future outcomes before software is developed or implemented. Scenarios are used
to test whether the software will accomplish user requirements. It also helps to provide a
framework for questions to software engineers about users’ tasks. These questions are
asked from users about future conditions (what-if) and procedures (how) in which they think
tasks can be completed.
Generally, a scenario includes the following information:
● Description of what users expect when the scenario starts
● Description of how to handle the situation when the software is not functioning
properly
● Description of the state of the software when the scenario ends.
Questionnaire: Questionnaire is an effective tool of gathering requirements and produces a
written document. The major advantage of questionnaire is that it requires less effort and
gathers information from many users in a very short time. In this method, preparing right and
effective questionnaires is the critical issue. This is because different users work with
different parts of the system, and have knowledge of that part only. Thus, a single
questionnaire is not appropriate for all the users. The analyst must prepare different sets of
questionnaires for different group of users. He should consider various issues while
preparing questionnaires like the length of questionnaires, whether to ask close-ended or
open-ended questions, and so on. Once the questionnaires are prepared, they are
distributed to the users. In this method, users get sufficient time, which enables them to give
correct answers of the queries.
On site observation: Generally, users are not able to express the process of how they
work. Thus, to have a close look of the system, the analyst may decide to perform the site
visit. Site visit enables the analyst to observe the current system, which helps him to detect
the problems of existing system.
Prototypes: Prototypes help to clarify unclear requirements. Like scenarios, prototypes also
help users to understand the information they need to provide to the software development
team.
Quality function deployment (QFD): This deployment translates user requirements into
technical requirements for the software. For this, QFD facilitates the development team to
understand what is valuable to users so that quality can be maintained throughout software
development. QFD identifies the following user requirements.
General requirements: These requirements describe the system objectives, which are
determined by various requirements elicitation techniques. Examples of general
requirements are graphical displays requested by users, specific software functions, and so
on.
Expected requirements: These requirements are implicit to software as users consider
them to be fundamental requirements, which will be accomplished in the software and hence
do not express them. Examples of expected requirements are ease of software installation,
ease of software and user interaction, and so on.
Unexpected requirements: These requirements specify the requirements that are beyond
user expectations. These requirements are not requested by the user but if added to the
software, they become an additional feature of the software. An example of unexpected
requirements is to have word processing software with additional capabilities such as page
layout capabilities along with the earlier features.
https://ecomputernotes.com/software-engineering/requirementselicitation
Requirements validation is the process of checking that requirements defined for
development, define the system that the customer really wants. To check issues related to
requirements, we perform requirements validation. We usually use requirements validation
to check error at the initial phase of development as the error may increase excessive
rework when detected later in the development process.
In the requirements validation process, we perform a different type of test to check the
requirements mentioned in the Software Requirements Specification (SRS), these checks
include:
● Completeness checks
● Consistency checks
● Validity checks
● Realism checks
● Ambiguity checks
● Verifiability
The output of requirements validation is the list of problems and agreed on actions of
detected problems. The lists of problems indicate the problem detected during the process of
requirement validation. The list of agreed action states the corrective action that should be
taken to fix the detected problem.
There are several techniques which are used either individually or in conjunction with
other techniques to check to check entire or part of the system
Test case generation:
Requirement mentioned in SRS document should be testable, the conducted tests reveal the
error present in the requirement. It is generally believed that if the test is difficult or
impossible to design than, this usually means that requirement will be difficult to implement
and it should be reconsidered.
Prototyping:
In this validation techniques the prototype of the system is presented before the end-user or
customer, they experiment with the presented model and check if it meets their need. This
type of model is generally used to collect feedback about the requirement of the user.
Requirements Reviews:
In this approach, the SRS is carefully reviewed by a group of people including people from
both the contractor organisations and the client side, the reviewer systematically analyses
the document to check error and ambiguity.
Automated Consistency Analysis:
This approach is used for automatic detection of an error, such as nondeterminism, missing
cases, a type error, and circular definitions, in requirements specifications.
https://www.geeksforgeeks.org/software-engineering-requirements-validation-
techniques/
software prototyping – S/W documentation – Analysis
and modelling
The Software Prototyping refers to building software application prototypes which displays
the functionality of the product under development, but may not actually hold the exact logic
of the original software.
Software prototyping is becoming very popular as a software development model, as it
enables to understand customer requirements at an early stage of development. It helps get
valuable feedback from the customer and helps software designers and developers
understand about what exactly is expected from the product under development.
What is Software Prototyping?
Prototype is a working model of software with some limited functionality. The prototype does
not always hold the exact logic used in the actual software application and is an extra effort
to be considered under effort estimation.
Prototyping is used to allow the users evaluate developer proposals and try them out before
implementation. It also helps understand the requirements which are user specific and may
not have been considered by the developer during product design.
Following is a stepwise approach explained to design a software prototype.
Basic Requirement Identification
This step involves understanding the very basics product requirements especially in terms of
user interface. The more intricate details of the internal design and external aspects like
performance and security can be ignored at this stage.
Developing the initial Prototype
The initial Prototype is developed in this stage, where the very basic requirements are
showcased and user interfaces are provided. These features may not exactly work in the
same manner internally in the actual software developed. While, the workarounds are used
to give the same look and feel to the customer in the prototype developed.
Review of the Prototype
The prototype developed is then presented to the customer and the other important
stakeholders in the project. The feedback is collected in an organized manner and used for
further enhancements in the product under development.
Revise and Enhance the Prototype
The feedback and the review comments are discussed during this stage and some
negotiations happen with the customer based on factors like – time and budget constraints
and technical feasibility of the actual implementation. The changes accepted are again
incorporated in the new Prototype developed and the cycle repeats until the customer
expectations are met.
https://www.tutorialspoint.com/sdlc/sdlc_software_prototyping.htm
Software documentation is written material, images, or video instructions that come with
computer software. As a rule, software documentation explains how to use a program or a
service.
However, there may be different types of software documentation, depending on the
audience it is created for.
Here are some examples of the software documentation types:
Requirements documentation
Typically created in the beginning of a software development project. Has the goal to clearly
and precisely specify the expectations in regards to the software being created. May include
functional requirements, limitations, hardware or software requirements, compatibility
requirements, and so on.
Architecture documentation
Defines the high-level architecture of the software system being created. May describe the
main components of the system, their roles and functions, as well as the data and control
flow among those components.
Technical documentation
Documentation of the software code, algorithms, APIs. Written for the technical audience like
software developers
End user documentation
https://clickhelp.com/software-documentation-glossary/software-documentation/
Requirement analysis is significant and essential activity after elicitation. We analyze,
refine, and scrutinize the gathered requirements to make consistent and unambiguous
requirements. This activity reviews all requirements and may provide a graphical view of the
entire system. After the completion of the analysis, it is expected that the understandability of
the project may improve significantly. Here, we may also use the interaction with the
customer to clarify points of confusion and to understand which requirements are more
important than others.
Draw the context diagram:
The context diagram is a simple model that 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
T The context diagram of student result management system is given below
Development of a Prototype (optional):
One effective way to find out what the customer wants is to construct a prototype, something
that looks and preferably acts as part of the system they say they want.WeWe can use their
feedback to modify the prototype until the customer is satisfied continuously. Hence, the
prototype helps the client to visualize the proposed system and increase the understanding
of the requirements. When developers and users are not sure about some of the elements, a
prototype may help both the parties to take a final decision.
Some projects are developed for the general market. In such cases, the prototype should be
shown to some representative sample of the population of potential purchasers. Even
though a person who tries out a prototype may not buy the final system, but their feedback
may allow us to make the product more attractive to others.
The prototype should be built quickly and at a relatively low cost. Hence it will always have
limitations and would not be acceptable in the final system. This is an optional activity.
Model the requirements:
This process usually consists of various graphical representations of the functions, data
entities, external entities, and the relationships between them. The graphical view may help
to find incorrect, inconsistent, missing, and superfluous requirements. Such models include
the Data Flow diagram, Entity-Relationship diagram, Data Dictionaries, State-transition
diagrams, etc.
Finalise the requirements:
After modeling the requirements, we will have a better understanding of the system
behavior. The inconsistencies and ambiguities have been identified and corrected. The flow
of data amongst various modules has been analyzed. Elicitation and analyze activities have
provided better insight into the system. Now we finalize the analyzed requirements, and the
next step is to document these requirements in a prescribed format.
https://www.javatpoint.com/software-engineering-requirement-analysis
A software requirements specification (SRS) is a document that describes what the
software will do and how it will be expected to perform. It also describes the functionality the
product needs to fulfill all stakeholders (business, users) needs.
A typical SRS includes:
A purpose
An overall description
Specific requirements
The best SRS documents define how the software will interact when embedded in hardware
— or when connected to other software. Good SRS documents also account for real-life
users.
Why Use an SRS Document?
A software requirements specification is the basis for your entire project. It lays the
framework that every team involved in development will follow.
It’s used to provide critical information to multiple teams — development, quality assurance,
operations, and maintenance. This keeps everyone on the same page.
Using the SRS helps to ensure requirements are fulfilled. And it can also help you make
decisions about your product’s lifecycle — for instance, when to retire a feature.
Writing an SRS can also minimize overall development time and costs. Embedded
development teams especially benefit from using an SRS.
A software requirements specification (SRS) includes in-depth descriptions of the software
that will be developed.
A system requirements specification (SyRS) collects information on the requirements for a
system.
“Software” and “system” are sometimes used interchangeably as SRS. But, a software
requirement specification provides greater detail than a system requirements specification.
How to Write an SRS Document
Create an Outline (Or Use an SRS Template)
Your first step is to create an outline for your software requirements specification. This may
be something you create yourself. Or you may use an existing
1. Introduction
1.1 Purpose
1.2 Intended Audience
1.3 Intended Use
1.4 Scope
1.5 Definitions and Acronyms
2. Overall Description
2.1 User Needs
2.2 Assumptions and Dependencies
3. System Features and Requirements
3.1 Functional Requirements
3.2 External Interface Requirements
3.3 System Features
3.4 Nonfunctional Requirement
2. Start With a Purpose
The introduction to your SRS is very important. It sets the expectation for the product you’re
building.
So, start by defining the purpose of your product.
Intended Audience and Intended Use
Define who in your organization will have access to the SRS — and how they should use it.
This may include developers, testers, and project managers. It could also include
stakeholders in other departments, including leadership teams, sales, and marketing.
Product Scope
Describe the software being specified. And include benefits, objectives, and goals. This
should relate to overall business goals, especially if teams outside of development will have
access to the SRS.
Definitions and Acronyms
It’s smart to include a risk definition. Avoiding risk is top-of-mind for many developers —
especially those working on safety-critical development teams.
Here’s an example. If you’re creating a medical device, the risk might be the adevice fails
and causes a fatality.
By defining that risk up front, it’s easier to determine the specific requirements you’ll need to
mitigate it.
Give an Overview of What You’ll Build
Your next step is to give a description of what you’re going to build. Is it an update to an
existing product? Is it a new product? Is it an add-on to a product you’ve already created?
These are important to describe upfront, so everyone knows what you’re building.
You should also describe why you’re building it and who it’s for.
User Needs
User needs — or user classes and characteristics — are critical. You’ll need to define who is
going to use the product and how.
You’ll have primary and secondary users who will use the product on aa regular basis. You
may also need to define the needs of a separate buyer of the product (who may not be a
primary/secondary user). And, for example, if you’re building a medical device, you’ll need to
adescribe the patient’s needs.
Assumptions and Dependencies
here might be factors that impact your ability to fulfill the requirements outlined in your SRS.
What are those factors?
Are there any assumptions you’re making with the SRS that could turn out to be false? You
should include those here, as well.
Finally, you should note if your project is dependent on any external factors. This might
include software components you’re reusing from another projec
Detail Your Specific Requirements
The next section is key for your development team. This is where you detail the specific
requirements for building your product.
Functional Requirements
Functional requirements are essential to building your product.
If you’re developing a medical device, these requirements may include infusion and battery.
And within these functional requirements, you may have a subset of risks and requirements.
External Interface Requirements
External interface requirements are types of functional requirements. They’re important for
embedded systems. And they outline how your product will interface with other components.
There are several types of interfaces you may have requirements for, including:
User
Hardware
Software
Communications
System Features
System features are types of functional requirements. These are features that are required in
order for a system to function.
Other Nonfunctional Requirements
Nonfunctional requirements can be just as important as functional ones.
These include:
Performance
Safety
Security
Quality
Get Approval for the SRS
Once you’ve completed the SRS, you’ll need to get it approved by key stakeholders. And
everyone should be reviewing the latest version of the document.
https://www.perforce.com/blog/alm/how-write-software-requirements-specification-srs-
document
