BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

1. Introduction.
2. Requirement Analysis Process. Current Application Analysis.
3. Requirement gathering techniques & Fact Finding, Recording Outcome.
4. DFD, Data Dictionary and Process Specification.
5. Importance of Requirement Specifications.
6. Software Requirement Specification Document.

Requirement is important to develop any software. These requirement must be consistent,

correct and unambiguous.

There are two types of software requirements:

1) Functional requirements
2) Non Functional requirements
Functional Requirements:
· Functional requirements define what a product must do and what its features and functions
are.
· It is stated by end user and can be seen directly in the final system.
· It can be a data manipulation, business process, user interaction or any other specific
functionality which define what system is likely perform.
For example:
1) Authentication of user whenever he/she logs into the system.
2) System shutdown in case of a cyber-attack.
3) A Verification email is sent to user whenever he/she registers for the first time on some software
system.
Nonfunctional requirements:

· Nonfunctional requirements are basically the quality attribute that system must satisfy
according to the project contract.
· It focus on quality and characteristics that system must process
· It defines how system should perform.
· They deal with issues like -
Portability, Security, Maintainability, Reliability, Scalability, Performance, Reusability,
Flexibility etc.

For Example:

l P a g e 1 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

1) Emails should be sent with a latency of no greater than 12 hours from such an activity.
2) The processing of each request should be done within 10 seconds.
3) The site should load in 3 seconds when the number of simultaneous users are > 10000.

Functional Requirements Non Functional Requirements

A functional requirement defines a system or A non-functional requirement defines the
its component. quality attribute of a software system.
It specifies “What should the software system It places constraints on “How should the
do?” software system fulfill the functional
requirements?”
Functional requirement is specified by User. Non-functional requirement is specified by
technical peoples e.g. Architect, Technical
leaders and software developers.
It is mandatory. It is not mandatory.
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.
Helps you verify the functionality of the Helps you to verify the performance of the
software. software.
Usually easy to define. Usually more difficult to define.
Example Example
1) Authentication of user whenever 1) Emails should be sent with a latency of
he/she logs into the system. no greater than 12 hours from such an
2) System shutdown in case of a cyber attack. activity.
3) A Verification email is sent to user 2) The processing of each request should
whenever be done within 10 seconds
he/she registers for the first time on some 3) The site should load in 3 seconds when the
software system. number of simultaneous users are > 10000

P a g e 2 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

P a g e 3 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

What is Requirements Analysis?

Requirements analysis or requirements engineering is a process used to determine the needs and
expectations of a new product. It involves frequent communication with the stakeholders and end-
users of the product to define expectations, resolve conflicts, and document all the key
requirements.

One of the greatest challenges faced by any organization is to share the vision of the final product
with the customers. Hence, a business requirements analysis involves a team effort of all the key
stakeholders, software developers, end-users, and customer managers to achieve a shared
understanding of what the product should do. This is always done in the early phase of
any project to ensure that the final product conforms to all the requirements.

After requirements gathering is complete, the analyst analyses the gathered requirements

to form a clear understanding of the exact customer requirements and to weed out any

problems in the gathered requirements like ambiguity, inconsistency and completeness.

Requirements analysis process

Requirements analysis is a multistage process that involves the following steps.

1. Stakeholders Identification

The first step in the requirements analysis process of a software development project
is stakeholder identification.

Simply put, this is the process of finding out who has a stake in the success of the software being

P a g e 4 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

developed.

P a g e 5 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Stakeholders are not just the customers who commission the software, but a broader group. They
include the end users who will interact with the software on a daily basis and who may have
valuable insight into what features are essential.

It’s important to identify all of these stakeholders early on, because each can provide unique
perspectives and requirements.

2. Elicitation of Requirement

The second step in the requirements analysis process is requirements elicitation.

The team uses a variety of methods to do this. Interviews are common, where team members have
one-on-one conversations with stakeholders to understand their needs. Questionnaires can be
sent out to quickly gather information from a larger group. Workshops or group sessions are also
effective, especially when interactive discussions can lead to deeper insights. Another method
is user observation, where the team observes how potential users interact with existing systems to
identify unspoken needs or problems.

This step is critical because it’s about gathering as much relevant information as possible to ensure
that the software is designed to meet the real needs of its users.

4. Documentation of Requirements

The third step in the requirements analysis process is requirements documentation.

After gathering all the necessary information from stakeholders, it’s time to put it all down on
paper, or more likely, in a digital document.

The goal of this step is to create a clear, detailed record of what the software needs to do and the
constraints within which it must operate. The team typically creates a document called a Software
Requirements Specification (SRS), which serves as a guide for everyone involved in the project.
This document includes everything from the specific features the software must have, to the
performance levels required, to the standards it must meet.

This document is the blueprint for the software project, outlining what needs to be built and how it
should work, and ensuring that everyone is on the same page.

5. Analysis and negotiation

The fourth step in the requirements analysis process is analysis and negotiation.
This stage involves taking a closer look at the documented requirements to make sure they are
realistic and workable.
P a g e 6 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

The team examines each requirement to understand its implications:

· How difficult will it be to implement?
· Does it conflict with any other requirements?
· Is it actually necessary for the software’s success?
This is a bit like solving a puzzle, making sure all the pieces fit together in the right way.
Negotiation comes into play when there are conflicting requirements or limitations in resources
like time or budget.
The goal here is to finalize a set of requirements that is achievable and aligns with the overall
objectives of the project. It’s a balancing act, ensuring that the software will fulfill its intended
purpose while staying within practical limits.

Step 5: Validation and Verification

The final step in the requirements analysis process, which combines both validation and
verification, is critical to ensuring that the project is on the right track.

Validation is about confirming that the requirements actually meet the needs of the
stakeholders and the goals of the project.
It’s like asking, “Are we building the right thing?” Here, the team reviews the requirements with the
stakeholders to make sure they are in line with their expectations and the goals of the project.

Verification, on the other hand, is about making sure that the requirements are documented
correctly and consistently. It’s like proofreading and quality checking the requirements document.
The team reviews the document to ensure that all requirements are clear, unambiguous, and
consistent.
Together, validation and verification serve as a double check to ensure that the software
development process is built on a solid foundation of well-defined, agreed-upon, and accurately
recorded requirements.

P a g e 7 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

It is essential to ensure that the software system being developed meets the needs and
expectations of users. The following are the key benefits of Requirement Analysis.

Understand User Needs

Requirement Analysis helps to identify the actual needs and expectations of the users.

Define System Scope

It helps to clearly define the scope and objectives of the software system to be developed.

Reduce Risks

Requirement Analysis helps in reducing the risk of project failure by identifying potential issues at an
early stage.

Improved Communication

It ensures effective communication between the development team, stakeholders, and clients.

Efficient Planning

Requirements Analysis enables efficient planning and scheduling of the software development process.

P a g e 8 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Requirements gathering
Requirements gathering is the process of identifying your project’s exact requirements from start
to finish.

This process occurs during the project initiation phase but you’ll continue to manage your project
requirements throughout the entire project timeline.

Some questions include:

· How long will our project schedule be?
· Who will be involved in the project?
· What risks may we face in this project?
Requirements gathering shouldn’t be complex, but it’s an important component of the project
initiation process.

The following are some of the well-known requirements gathering techniques –

Questionnaires:

Questionnaires can be beneficial if you need to ask stakeholders the same question across the
enire team. Share the questionnaire with stakeholders in advance, and give them time to answer
questions about project requirements, to ensure no one leaves anything out.

Brainstorming

Brainstorming is used in requirement gathering to get as many ideas as possible from group of people.
Generally used to identify possible solutions to problems, and clarify details of opportunities.

Document Analysis

Reviewing the documentation of an existing system can help when creating AS–IS process document, as well
as driving gap analysis for scoping of migration projects.
In an ideal world, we would even be reviewing the requirements that drove creation of the existing system –
a starting point for documenting current requirements.

Focus Group

A focus group is a gathering of people who are representative of the users or customers of a product to get
feedback.
The feedback can be gathered about needs/opportunities/ problems to identify requirements, or can be
gathered to validate and refine already elicited requirements.
This form of market research is distinct from brainstorming in that it is a managed process with specific
participants.

Prepared By: Ms.Krupa Patel P a g e 9 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Interface analysis

Interfaces for a software product can be human or machine. Integration with external systems and devices is
just another interface.
User centric design approaches are very effective at making sure that we create usable software.
Interface analysis – reviewing the touch points with other external systems is important to make sure we
don’t overlook requirements that aren’t immediately visible to users.

Interview

Interviews of stakeholders and users are critical to creating the great software. Without
understanding the goals and expectations of the users and stakeholders, we are very unlikely to
satisfy them. We also have to recognize the perspective of each interviewee, so that, we can
properly weigh and address their inputs. Listening is the skill that helps a great analyst to get more
value from an interview than an average analyst.

Observation

By observing users, an analyst can identify a process flow, steps, pain points and opportunities for
improvement.
Observations can be passive or active (asking questions while observing). Passive observation is better for
getting feedback on a prototype (to refine requirements), where active observation is more effective at
getting an understanding of an existing business process. Either approach can be used.

Prototyping

Prototyping is a relatively modern technique for gathering requirements. In this approach, you gather
preliminary requirements that you use to build an initial version of the solution - a prototype.
You show this to the client, who then gives you additional requirements. You change the application and
cycle around with the client again. This repetitive process continues until the product meets the critical mass
of business needs or for an agreed number of iterations.

Requirement Workshops

Workshops can be very effective for gathering requirements. More structured than a brainstorming session,
involved parties collaborate to document requirements.
One way to capture the collaboration is with creation of domain-model artifacts (like static diagrams,
activity diagrams). A workshop will be more effective with two analysts than with one.

Reverse Engineering

When a migration project does not have access to sufficient documentation of the existing system, reverse
engineering will identify what the system does.
It will not identify what the system should do, and will not identify when the system does the wrong thing.

Prepared By: Ms.Krupa Patel P a g e 10 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Survey/Questionnaire

When collecting information from many people – too many to interview with budget and time constraints –
a survey or questionnaire can be used.
The survey can force users to select from choices, rate something (“Agree Strongly, agree…”), or have open
ended questions allowing free-form responses. Survey design is hard – questions can bias the respondents.

Prepared By: Ms.Krupa Patel P a g e 11 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Data Flow Diagram :

A DFD is a hierarchical graphical model of a system that shows the different processing activities or functions
that the system performs and the data interchange among those functions.

● Though extremely simple, it is a very powerful tool to tackle the complexity of industry standard
problems.

● A DFD model only represents the data flow aspects and does not show the sequence of execution of the
different functions and the conditions based on which a function may or may not be executed.

● In the DFD terminology, each function is called a process or a bubble. Each function as a processing station
(or process) that consumes some input data and produces some output data.

DFD Components DFD can represent Source, destination, storage and flow of data using the
following set of components –

• Entities - Entities are source and destination of information data. Entities are represented by a rectangles
with their respective names.

• Process - Activities and action taken on the data are represented by Circle or Round-edged rectangles. •
Data Storage - There are two variants of data storage - it can either be represented as a rectangle with
absence of both smaller sides or as an open-sided rectangle with only one side missing.

• Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from the base of
arrow as its source towards head of the arrow as destination.

The designation of DFD visual elements is not strictly regulated. However, there are two commonly used

versions of notation — DeMarco-Yourdon and Gane-Sarson versions. The differences are the following:

Prepared By: Ms.Krupa Patel P a g e 12 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Rule of Data Flow

Levels in Data Flow Diagrams (DFD):

The DFD may be used to perform a system or software at any level of abstraction.
In fact, DFDs may be partitioned into levels that represent increasing information flow and functional
detail.
Levels in DFD are numbered 0, 1, 2 or beyond.
Here, we will see mainly 3 levels in the data flow diagram, which are:
0-level DFD
1-level DFD
2-level DFD
Numbering Convention
· Use a unique reference number for each process symbol.
· Other process numbers are in the hierarchy of:
· (1, 2, 3,...);
· (1.1, 1.2, 1.3, ..., 2.1, 2.2, 2.3,...);
· (1.1.1, 1.1.2, 1.1.3,...).
1. level DFD:
➢ It is also known as a context diagram.
➢ It’s designed to be an abstraction view, showing the system as a single process with its
relationship to external entities.
➢ It represents the entire system as a single bubble with input and output data indicated by
incoming/outgoing arrows.

Prepared By: Ms.Krupa Patel P a g e 13 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

1.level DFD:
➢ In 1-level DFD, the context diagram is decomposed into multiple bubbles/processes.
➢ In this level, we highlight the main functions of the system and breakdown the high-level process of 0-

level DFD into sub processes.

2.level DFD:

➢ 2-level DFD goes one step deeper into parts of 1-level DFD.
➢ It can be used to plan or record the specific/necessary detail about the system’s functioning.

Prepared By: Ms.Krupa Patel P a g e 14 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Food Ordering System:

Prepared By: Ms.Krupa Patel P a g e 15 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Prepared By: Ms.Krupa Patel P a g e 16 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

*https://www.geocities.ws/inf381/chap8/ch8.htm

Prepared By: Ms.Krupa Patel P a g e 17 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Library Management System:

Prepared By: Ms.Krupa Patel P a g e 18 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Advantages of DFD

· It helps us to understand the functioning and the limits of a system.

· It is a graphical representation which is very easy to understand as it helps visualize contents.

· Data Flow Diagram represent detailed and well explained diagram of system components.

· It is used as the part of system documentation file.

· Data Flow Diagrams can be understood by both technical or nontechnical person because they are
very easy to understand.

Disadvantages of DFD

· At times DFD can confuse the programmers regarding the system.

· Data Flow Diagram takes long time to be generated, and many times due to this reasons analysts are
denied permission to work on it.

Prepared By: Ms.Krupa Patel P a g e 19 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Data Dictionary

➢ A data dictionary contains metadata i.e., data about the database.

➢ The data dictionary is very important as it contains information such as what is in the database,
who is allowed to access it, where is the database physically stored etc.
➢ The users of the database normally don't interact with the data dictionary, it is only handled
by the database administrators.

The data dictionary in general contains information about the following −

· Names of all the database tables and their schemas.

· Details about all the tables in the database, such as their owners, their security
constraints, when they were created etc.
· Physical information about the tables such as where they are stored and how.
· Table constraints such as primary key attributes, foreign key information etc.
· Information about the database views that are visible.

This is a data dictionary describing a table that contains employee details.

Field Name Data Type Field Description Example

Size for
display

EmployeeNumber Integer 10 Unique ID of each employee 1645000001

Name Text 20 Name of the employee David Heston

Date of Birth Date/Time 10 DOB of Employee 08/03/1995

Phone Number Integer 10 Phone number of employee 6583648648

The different types of data dictionary are –

Active Data Dictionary

If the structure of the database or its specifications change at any point of time, it should be reflected
in the data dictionary. This is the responsibility of the database management system in which the
data dictionary resides.

Prepared By: Ms.Krupa Patel P a g e 20 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

So, the data dictionary is automatically updated by the database management system when any
changes are made in the database. This is known as an active data dictionary as it is self updating.

Passive Data Dictionary

This is not as useful or easy to handle as an active data dictionary. A passive data dictionary is
maintained separately to the database whose contents are stored in the dictionary. That means
that if the database is modified the database dictionary is not automatically updated as in the case
of Active Data Dictionary.

So, the passive data dictionary has to be manually updated to match the database. This needs
careful handling or else the database and data dictionary are out of sync.

Advantages of Data Dictionary

The advantages of using a data dictionary are:

· It is a valuable reference in any organization because it provides documentation.

· It improves the communication between system analyst and user by establishing consistent
definitions of various items terms and procedures.
· It is a good tool for manage operators and other members of the development team to
understand requirements and design.
· It helps the analyst to simplify the structure for meeting the data requirements of the system.
· It is just like a store of all data elements information that can link all phases of software
development life cycle.
· It is used to remove the redundancy in data definition.
· It is an important step building a database. Most data base management system has a data
dictionary as a standard feature.
· During implementation, it serves as a base against which developers compare their data
description.

Disadvantage of Data Dictionary

There are some disadvantages given below:

➢ It does not provide functional details.
➢ It is not acceptable to many nontechnical users.
➢ It is very time consuming process

Prepared By: Ms.Krupa Patel P a g e 21 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

Process Specification
Process: sequence of step performed to achieve some goal.

Software Process: sequence of steps to perform to produced software with high quality within
budget and schedule.

· DFD model the processes that exist in a system. But they do not allow us to recored
detailed information about these processes.
· To record detailed information about processes (to specify processes) process specification
technique is used.
· Process specification can be used to specify the processing details implies by bubble with in
DFD. In other word, Process Specification is used to describe the inner workings of a process
represented in data flow diagram.

Why are process specifications important?

They provide a clear and concise description of the steps involved in a process, as well as the
inputs and outputs for each step.

Process specifications also help to ensure that all stakeholders involved in a process are aware of
its requirements and can work together to achieve desired results.

Prepared By: Ms.Krupa Patel P a g e 22 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

PSPEC Format:

Prepared By: Ms.Krupa Patel P a g e 23 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

SOFTWARE REQUIREMENT SPECIFICATION

A software requirements specification (SRS) is a document that mentioned a detailed

description of a software system to be developed.

· SRS allow customer to review whether all requirement are fulfilled by software or not.
· A good SRS defines the how Software System will interact with all internal modules, hardware,
communication with other programs.
· A software requirements specification (SRS) is a document that describes what the software will do
and how it will be expected to perform

Purpose:

· It is used to define need and expectation of user

· It serves contract document between client and developer.

SRS Document Structure:

The IEEE standard for requirements documents. The most widely known requirements document standard is
(IEEE, 1998). This IEEE standard suggests the following structure for requirements documents:

1. Introduction
1.1.Purpose of the requirements document
1.2.Scope
1.3.Definitions, acronyms and abbreviations
1.4.References
.5 Overview of the remainder of the document
2. General description
2.1.User Interface
2.2.System Interface
2.3.Software and hardware requirements
2.4.Constraints, Assumptions and dependencies
2.5.User characteristics
3. System Features and Requirements
3.1.Functional Requirements
3.2.User cases, Sequence diagram
3.3.External Interface Requirements
3.4.Logical database diagram
3.5.Nonfunctional Requirements
4. Delivered for approval

Prepared By: Ms.Krupa Patel P a g e 24 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

1. Introduction
1.1.Purpose of this Document
At first, main aim of why this document is necessary and what’s purpose of document is
explained and described.
1.2.Intended Audience
It describes which type of user will use particular application
1.3.Scope of this document
In this, overall working and main objective of document and what value it will provide to
customer is described and explained.
It also includes a description of development cost and time required.
1.4.Definitions
Clearly define all key terms, acronyms, and abbreviations used in the SRS.
This will help eliminate any ambiguity and ensure that all parties can easily understand
the document. i.e. HOD – Head of the department
1.5.References
1.6.Overview – In this, description of product is explained. It’s simply summary or overall
review of product.

2. Overall User Specifications

2.1.User Interface
This section briefly state that every user having different interface
2.2.System Interface
This section describe which type of server used.
2.3.Software and hardware requirement
This section describe which type of software, programming language and hardware used like
keyboard, mouse, monitor etc.
2.4.Constraints, assumptions and dependencies
This section describe that condition that imposed on software. I.e. Student can’t edit marks, use can
enter password 3 times only etc.
If we make any assumption in product or any dependencies, mention in it.
2.5.User Characteristics
This section describe interface of every user. Like teacher can add attendance, add question paper.
3. System Features and Requirement
Prepared By: Ms.Krupa Patel P a g e 25 | 29
 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

3.1.Functional Requirements
It states that what software will do. Which type of features customer want.
3.2.User cases
Various user classes that are expected to use this software are identified and described here.
3.3.External Interface Requirement
External interface requirements are specific types of functional requirements. These are
especially important when working with embedded systems. They outline how your
product will interface with other components.
i.e. When user pay fee that it will redirect external app (gpay)
3.4.Logical Database requirement
It describe which type of database used like my sql , oracle ,sql server etc.
3.5.Nonfunctional requirement
It states that how system will perform? It show quality attributes like security , availability,
performance, portability, reliability etc.
4. Deliver for approval
Customer check if it is satisfied it will send to next designer or development team.

Characteristics of good SRS / Features of SRS

Quality characteristics of a good Software Requirements Specification (SRS) document include:

1. Correct: The SRS is said to be correct if it covers all the requirements that are actually

Prepared By: Ms.Krupa Patel P a g e 26 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

expected from the system.

Prepared By: Ms.Krupa Patel P a g e 27 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

2. Complete: The SRS should include all the requirements for the software system, including
both functional and non-functional requirements.
3. Consistent: The SRS should be consistent in its use of terminology and formatting, and
should be free of contradictions.(No conflict between any set of requirements)
4. Unambiguous: The SRS should be clear and specific, and should avoid using vague or
imprecise language. Don’t use words which have more than one meaning. One word have
only one interpretation.
5. Traceable: The SRS should be traceable to other documents if origin of each requirements
are clear.
6. Verifiable: The SRS should be verifiable, which means that the requirements can be tested
and validated to ensure that they are being met.
7. Modifiable: The SRS should be modifiable, so that it can be updated and changed as the
software development process progresses.
8. Prioritized: The SRS should prioritize requirements, so that the most important
requirements are addressed first.
9. Testable: The SRS should be written in a way that allows the requirements to be tested
and validated.
10. High-level and low-level: The SRS should provide both high-level requirements (such as
overall system objectives) and low-level requirements (such as detailed functional
requirements).
11. Relevant: The SRS should be relevant to the software system that is being developed, and
should not include unnecessary or irrelevant information.
12. Design Independence: The SRS should be provide more than one interface of software
not only one. So customer can choose any one.
13. Understandable by customer: An end user maybe an expert in his/her specific domain but
might not be an expert in computer science. Hence, the use of formal notations and
symbols should be avoided to as much extent as possible. The language should be kept
easy and clear.

Prepared By: Ms.Krupa Patel P a g e 28 | 29

 BHAGWAN MAHAVIR COLLEGE OF COMPUTER APPLICATION

SY BSc (IT) SEM 4 Unit 4 Requirement Analysis

14. Aligned with business goals: The SRS should be aligned with the overall business goals
and objectives of the organization, so that the software system meets the needs of the
business.
By keeping these quality characteristics in mind, developers and stakeholders can ensure that the SRS
document is clear, complete, and accurate, which in turn can help to ensure that the final software
system meets the needs of the business and its users.

Why do we need to write SRS?

· You can get an accurate estimate of the cost, risk and time costs.

· The client will be able to form their vision of the project more clearly.

· The customer and the contractor will have the same idea about the product.

· It will help identify the optimal set of functions.

· It serves as the basis for the formation of other technical documentation.

· The development process will be optimized and time minimized.

· There will be no duplication of tasks.

· Allows you to structure problems to solve them easier and faster.

It has become very evident that a poor specification of software requirements can lead to failed

projects. Hence, this discipline becomes increasingly essential.

Prepared By: Ms.Krupa Patel P a g e 29 | 29