NOTE: This template is shareware downloaded from www.processimpact.com. All shareware
payments are donated to the Norm Kerth Benefit Fund to help a consultant who is disabled
with a brain injury. Please visit http://www.processimpact.com/norm_kerth.html to make a
shareware payment ($10 suggested). Thank you!
Software Requirements
Specification
for
<Project>
Version 1.0 approved
Prepared by <author>
<organization>
<date created>
eLearning versions of several popular Process Impact training seminars are available at
www.processimpact.com/elearning.shtml, including “In Search of Excellent
Requirements,” “Exploring User Requirements with Use Cases,” “Writing High-Quality
Requirements,” “Software Inspections and Peer Reviews,” and “Project Management
Best Practices”. Single-user and corporate-wide site licenses are both available.
Copyright © 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for <Project>
Page ii
Table of Contents
Table of Contents .......................................................................................................................... ii
Revision History ............................................................................................................................ ii
1. Introduction ..............................................................................................................................1
1.1
1.2
1.3
1.4
1.5
Purpose ............................................................................................................................................ 1
Document Conventions.................................................................................................................... 1
Intended Audience and Reading Suggestions .................................................................................. 1
Project Scope ................................................................................................................................... 2
References........................................................................................................................................ 2
2. Overall Description ..................................................................................................................2
2.1
2.2
2.3
2.4
2.5
2.6
2.7
Product Perspective ......................................................................................................................... 2
Product Features .............................................................................................................................. 2
User Classes and Characteristics ..................................................................................................... 3
Operating Environment.................................................................................................................... 3
Design and Implementation Constraints .......................................................................................... 4
User Documentation ........................................................................................................................ 4
Assumptions and Dependencies ...................................................................................................... 4
3. System Features........................................................................................................................5
3.1 System Feature 1 .............................................................................................................................. 5
3.2 System Feature 2 (and so on) ........................................................................................................... 6
4. Functional Requirements Specification .................................................................................6
4.1 Usecase Diagram ................................................................. Ошибка! Закладка не определена.
4.2 Usecase List ......................................................................... Ошибка! Закладка не определена.
4.3 Usecase Description............................................................. Ошибка! Закладка не определена.
5. Other Nonfunctional Requirements .....................................................................................11
5.1
5.2
5.3
5.4
Performance Requirements ............................................................................................................ 11
Safety Requirements ...................................................................................................................... 11
Security Requirements ................................................................................................................... 11
Software Quality Attributes ........................................................................................................... 11
6. Other Requirements ..............................................................................................................11
Appendix A: Glossary..................................................................................................................11
Appendix B: Analysis Models .....................................................................................................12
Appendix C: Issues List ...............................................................................................................12
Revision History
Name
Date
Reason For Changes
Version
Software Requirements Specification for <Project>
Page 1
1. Introduction
1.1 Purpose
The purpose of a Software Requirements Specification (SRS) is to clearly and
unambiguously document the functional and non-functional requirements of a software system. The
SRS serves as a communication bridge between the project stakeholders and the development team,
providing a shared understanding of what the software system should do, how it should behave, and
what it should not do.
The SRS serves as a basis for the software development process, guiding the design,
development, testing, and maintenance of the software product. It also helps to ensure that the
software system meets the needs of its users and is of high quality, by providing a clear definition of
the software requirements that must be met.
The SRS is an important document for all stakeholders involved in the software
development process, including project sponsors, software developers, testers, and end-users. It
helps to ensure that everyone has a shared understanding of what the software system will do, and
what it will not do, and it serves as a reference throughout the software development lifecycle.
Ultimately, the SRS helps to ensure that the software system is developed on time, on budget, and to
the satisfaction of all stakeholders involved in the project.
1.2 Document Conventions
Fonts and Styles: Times New Roman
Numbering and Labeling
Priority: three-level priority system
1.3 Intended Audience and Reading Suggestions
The Intended Audience section of a Software Requirements Specification include:
1. Project Sponsors: These are the individuals or groups who are funding the software
development project. The SRS should highlight how the software system will meet
their business needs and how it will provide value to the organization.
2. Developers: These are the individuals responsible for designing and implementing
the software system. The SRS should provide clear and detailed requirements that
can be used as a basis for development.
3. Testers: These are the individuals responsible for testing the software system to
ensure that it meets the specified requirements. The SRS should provide detailed
requirements that can be used to design and execute test cases.
4. End-users: These are the individuals who will be using the software system. The SRS
should provide a clear understanding of how the software system will meet their
needs and provide a positive user experience.
5. Project Managers: These are the individuals responsible for overseeing the software
development project. The SRS should provide a clear understanding of the project
scope, timeline, and budget.
Reading Suggestions may also be included in the SRS, providing guidance on how to
approach the document and what information to focus on. These may include:
Software Requirements Specification for <Project>
Page 2
1. Overview: Start by reading the introduction and overview sections of the SRS to gain
an understanding of the software system being developed and its purpose.
2. Requirements: Focus on the requirements section, which outlines the functional and
non-functional requirements of the software system. This section provides the core
information needed to design and develop the software system.
3. Assumptions and Constraints: Pay attention to any assumptions or constraints that
may affect the requirements or development of the software system. These may
include technical, resource, or scheduling constraints.
4. Glossary: Refer to the glossary for definitions of technical terms and acronyms used
throughout the document.
1.4 Project Scope
<Provide a short description of the software being specified and its purpose, including relevant
benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If a
separate vision and scope document is available, refer to it rather than duplicating its contents
here. An SRS that specifies the next release of an evolving product should contain its own scope
statement as a subset of the long-term strategic product vision.>
1.5 References
<List any other documents or Web addresses to which this SRS refers. These may include user
interface style guides, contracts, standards, system requirements specifications, use case
documents, or a vision and scope document. Provide enough information so that the reader could
access a copy of each reference, including title, author, version number, date, and source or
location.>
2. Overall Description
2.1 Product Perspective
The CRM system being specified in this SRS is a new, self-contained product that will be
developed from scratch. It is not part of an existing product family nor is it intended to replace any
existing systems. The system will be a standalone software product that will be integrated with other
business systems and processes.
The CRM system will be a critical component of the company's overall customer
engagement strategy and will provide a central repository for customer data. The system will be
designed to integrate with other systems such as marketing automation, sales forecasting, and
customer support to provide a complete picture of customer interactions and behavior.
As a standalone product, the CRM system will be designed to work with a variety of
hardware and software configurations, as well as integrate with different types of databases and
systems. It will have external interfaces with other systems, including APIs and integration with
social media platforms.
A simple diagram showing the major components of the overall system and their
interconnections can be helpful in illustrating the context and perspective of the CRM system. This
could include components such as the CRM database, marketing automation software, sales
forecasting software, and customer support software, along with any external interfaces and
connections. The diagram would help to provide a visual representation of how the CRM system fits
Software Requirements Specification for <Project>
Page 3
into the larger business ecosystem and the role it plays in managing customer interactions and
relationships.
2.2 Product Features
The CRM system being specified in this SRS will provide the following major features and
functions:
1. Customer Data Management: The system will allow users to enter, store, and manage
customer data, including contact information, demographic data, purchase history, and
communication preferences.
2. Sales Management: The system will provide tools for managing the sales process, including
lead management, opportunity tracking, and sales forecasting.
3. Marketing Automation: The system will provide marketing automation capabilities,
including email campaigns, social media engagement, and lead scoring.
4. Customer Service Management: The system will provide tools for managing customer
service interactions, including case management, ticketing, and escalation.
5. Reporting and Analytics: The system will provide a range of reporting and analytics tools,
including dashboards, data visualizations, and ad hoc reporting.
6. Integration and Customization: The system will be designed to integrate with other business
systems and processes and will provide tools for customization and configuration to meet
specific business needs.
A top-level data flow diagram or class diagram can be helpful in illustrating the major groups of
related requirements and how they relate. This would help to provide a visual representation of the
overall functionality of the CRM system and how the different features and functions are
interconnected.
2.3 User Classes and Characteristics
The following user classes are anticipated to use the CRM system being specified in this SRS:
1. Sales Representatives: These users will be responsible for managing leads, opportunities,
and sales activities. They will be heavy users of the system, accessing it daily to enter and
update data, track progress against sales targets, and generate reports. They will have a high
level of technical expertise and will require a user-friendly interface that allows them to
quickly and easily manage their sales activities.
2. Marketing Professionals: These users will be responsible for creating and executing
marketing campaigns. They will use the system to manage email campaigns, social media
engagement, and lead scoring. They will also use the system to track campaign effectiveness
and generate reports. They will have a moderate level of technical expertise and will require
an interface that allows them to easily create and manage campaigns.
3. Customer Service Representatives: These users will be responsible for managing customer
interactions and resolving customer issues. They will use the system to create and manage
customer cases, track ticket status, and escalate issues as needed. They will also use the
system to generate reports on customer service performance. They will have a moderate
level of technical expertise and will require an interface that allows them to quickly and
easily manage customer interactions.
4. System Administrators: These users will be responsible for configuring and maintaining the
CRM system. They will have full access to all system functions and will be responsible for
managing security, user roles and permissions, and system settings. They will have a high
level of technical expertise and will require an interface that allows them to easily configure
and maintain the system.
Software Requirements Specification for <Project>
Page 4
The favored user classes are Sales Representatives and Marketing Professionals, as they are the
primary users of the system and will be using it heavily. The other user classes are also important,
but may not require as much attention as the primary users.
2.4 Operating Environment
The CRM system will operate in a standard business environment, with the following hardware and
software requirements:
Hardware:
 Desktop or laptop computers with a minimum of 4GB RAM and 2.0 GHz processor speed.
 Mobile devices such as smartphones or tablets with a minimum of 2GB RAM and 1.5 GHz
processor speed.
 Internet connectivity with a minimum bandwidth of 10Mbps.
Software:
 Operating systems: Windows 10, MacOS, iOS, Android.
 Web browsers: Google Chrome, Mozilla Firefox, Microsoft Edge, Safari.
 Database management system: MySQL 8.0 or higher.
 Server technology: Apache Tomcat 9.0 or higher.
The system must peacefully coexist with other software applications used in the organization, such
as email clients, office productivity tools, and other business systems. It is assumed that the system
will be deployed in a secure environment with appropriate firewalls and access controls.
2.5 Design and Implementation Constraints
There are several design and implementation constraints that the development team must take into
consideration when developing the CRM system. These constraints include:
1. Hardware limitations: The system must be designed to operate on the minimum hardware
specifications outlined in the operating environment section. Developers must ensure that
the system's functionality is not compromised by hardware limitations such as memory or
processing power.
2. Technology constraints: The system must be built using Apache Tomcat and MySQL
database management system. Developers must also use Java programming language.
3. Security considerations: The system must be designed with security in mind. This includes
secure login and authentication procedures, access control mechanisms, and encryption of
sensitive data.
4. Regulatory policies: The system must comply with any applicable regulatory policies or
guidelines, such as GDPR and HIPAA.
5. Design conventions and programming standards: The development team must follow design
conventions and programming standards established by the customer's organization. These
standards will ensure that the system is maintainable by the customer's organization after
deployment.
6. Interface with other applications: The system must be designed to interface with other
applications used in the organization, such as email clients and office productivity tools.
The development team must take these constraints into consideration when designing and
implementing the CRM system. Failure to do so may result in an ineffective or non-compliant
system.
2.6 User Documentation
The following user documentation components will be delivered along with the CRM software:
Software Requirements Specification for <Project>
Page 5
1. User manual: A comprehensive user manual will be provided in both electronic and
hardcopy formats. The manual will provide step-by-step instructions on how to use the CRM
software, including how to perform common tasks, how to navigate the user interface, and
how to troubleshoot common issues.
2. Online help: The CRM software will include an online help system accessible from within
the application. The online help system will provide context-sensitive help to users, allowing
them to quickly find information about the task they are performing.
3. Tutorials: The CRM software will include a set of interactive tutorials designed to help users
get started with the application. The tutorials will walk users through common tasks,
allowing them to become familiar with the application's features and functionality.
All user documentation will be delivered in English and will comply with the customer's
organization's documentation standards. The electronic versions of the user manual and online help
system will be provided in HTML format and will be accessible from any web browser.
2.7 Assumptions and Dependencies
Assumptions:
 The users have basic knowledge of computer operation and the software will not provide any
additional training.
 The software will be developed using Java programming language.
 The hardware and software environment will be available for testing and implementation as
specified in the Operating Environment section.
 The software will comply with all relevant laws and regulations.
 The project team will have access to all necessary resources, including hardware, software,
and personnel.
 The user interface design will be approved by the stakeholders before implementation.
Dependencies:
 The software will use a third-party library for data encryption.
 The database schema will be provided by the client and will be used as the basis for the
software's data storage.
 The software will integrate with a third-party authentication service for user login and access
control.
 The software will use a messaging service for communication between users.
3. System Features
<This template illustrates organizing the functional requirements for the product by system
features, the major services provided by the product. You may prefer to organize this section by
use case, mode of operation, user class, object class, functional hierarchy, or combinations of
these, whatever makes the most logical sense for your product.>
3.1 System Feature 1
<Don’t really say “System Feature 1.” State the feature name in just a few words.>
3.1.1
Description and Priority
<Provide a short description of the feature and indicate whether it is of High,
Medium, or Low priority. You could also include specific priority component ratings,
such as benefit, penalty, cost, and risk (each rated on a relative scale from a low of 1
to a high of 9).>
Software Requirements Specification for <Project>
3.1.2
Page 6
Stimulus/Response Sequences
<List the sequences of user actions and system responses that stimulate the
behavior defined for this feature. These will correspond to the dialog elements
associated with use cases.>
3.1.3
Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are
the software capabilities that must be present in order for the user to carry out the
services provided by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, and necessary.
Use “TBD” as a placeholder to indicate when necessary information is not yet
available.>
<Each requirement should be uniquely identified with a sequence number or a
meaningful tag of some kind.>
REQ-1:
REQ-2:
3.2 System Feature 2 (and so on)
4. Functional Requirements Specification
Software Requirements Specification for <Project>
Page 7
4.1 Usecase Diagram
Figure : Usecase Diagram
4.2 Usecase Diagram
<Describe the logical and physical characteristics of each interface between the software product
and the hardware components of the system. This may include the supported device types, the
nature of the data and control interactions between the software and the hardware, and
communication protocols to be used.>
ID
Actor
UC-1
New Customer
UC-2
Register Customer
Name
Use case writer
Register
Register Login
Sussychrist
Assign To
Software Requirements Specification for <Project>
UC-3
Admin
Register Customer,
UC-4
Admin
Admin Login
Page 8
Sussychrist
Logout
Add customer and manager
UC-5
Admin
UC-6
Admin
UC-7
Admin
UC-8
Admin
UC-9
Admin
UC-10
Manager
Add order in system
Sussychrist
UC-11
Manager
Delete order in system
Sussychrist
UC-12
Manager
Edit order in system
Sussychrist
UC-13
Manager
View order in system
Sussychrist
UC-14
Manager
Search order in system
UC-15
Manager
Add product in system
UC-16
Manager
Deletet product in system
UC-17
Manager
Edit product in system
UC-18
Manager
View product in system
UC-19
Manager
Search product in system
account
Delete customer and manager
account
Edit customer and manager
account
View customer and manager
account
Search customer and manager
account
Registed
UC-20
Customer, New
Customer
Search product
Sussychrist
Sussychrist
Sussychrist
Sussychrist
Sussychrist
Software Requirements Specification for <Project>
UC-21
Registed Customer
Display bill
UC-22
Registed Customer
Payment
UC-23
Registed Customer
Add product to cart
4.3 Usecase Description
4.3.1 Login
Use case ID
UC-1
Use case name Register
Created by
Sussychrist
Actor
Register Customer, Admin
This function allows:
Description
Admin to login in the Account’s database
Register Customer to login in the website with phone number
Trigger
N/A
Post
conditions
New Customer have a phone number
Main flows
1. New Customer opens Website, fills in Phone number,
personal information and taps Register in Account.
Normal flow
2. System sends a message with OTP code and move to
confirm screen.
3. New Customer fills in confirm input with OTP code
4. Website will automatically move to Home screen
Alternative
flow
N/A
Priority
High.
Frequency of
use
High.
Page 9
Software Requirements Specification for <Project>
Other inf.
N/A.
Assumptions
N/A.
Page 10
Table :
4.3.2 Login
Use case ID
UC-2
Use case name Login
Created by
Sussychrist
Actor
New Customer
Description
This function allows New Customer to register the website with
phone number
Trigger
N/A
Post
conditions
New Customer have a phone number
Main flows
5. New Customer opens Website, fills in Phone number,
personal information and taps Register in Account.
Normal flow
6. System sends a message with OTP code and move to
confirm screen.
7. New Customer fills in confirm input with OTP code
8. Website will automatically move to Home screen
Alternative
flow
N/A
Priority
High.
Frequency of
use
High.
Other inf.
N/A.
Assumptions
N/A.
Software Requirements Specification for <Project>
Page 11
5. Other Nonfunctional Requirements
5.1 Performance Requirements
<If there are performance requirements for the product under various circumstances, state them
here and explain their rationale, to help the developers understand the intent and make suitable
design choices. Specify the timing relationships for real time systems. Make such requirements as
specific as possible. You may need to state performance requirements for individual functional
requirements or features.>
5.2 Safety Requirements
<Specify those requirements that are concerned with possible loss, damage, or harm that could
result from the use of the product. Define any safeguards or actions that must be taken, as well as
actions that must be prevented. Refer to any external policies or regulations that state safety
issues that affect the product’s design or use. Define any safety certifications that must be
satisfied.>
5.3 Security Requirements
<Specify any requirements regarding security or privacy issues surrounding use of the product or
protection of the data used or created by the product. Define any user identity authentication
requirements. Refer to any external policies or regulations containing security issues that affect the
product. Define any security or privacy certifications that must be satisfied.>
5.4 Software Quality Attributes
<Specify any additional quality characteristics for the product that will be important to either the
customers or the developers. Some to consider are: adaptability, availability, correctness,
flexibility, interoperability, maintainability, portability, reliability, reusability, robustness, testability,
and usability. Write these to be specific, quantitative, and verifiable when possible. At the least,
clarify the relative preferences for various attributes, such as ease of use over ease of learning.>
6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>
Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>
Software Requirements Specification for <Project>
Page 12
Appendix B: Analysis Models
<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>
Appendix C: Issues List
< This is a dynamic list of the open requirements issues that remain to be resolved, including
TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>