Software Requirements Specification

Release Information

Internal Release Number: X.Y.Z
Attached worksheets:
Related Documents:
Process impact: The SRS precisely defines the software product that will be built. Decisions made while writing the SRS are based on information in the project proposal and user needs documents. The SRS sets requirements that must be satisfied by the system design. The SRS will be validated through activities outlined in the QA plan.
TODO: Read the following questions and answers while considering how they apply to your product. Select the best answer to each question and adjust it to fit your project, or write your own answer. Add or delete questions as needed. Working through the SRS can help the team raise relevant questions, expose incomplete understandings, and guide team discussions. This process takes time, however it generally saves much more time during design, implementation, and testing.


What business problem is being addressed? How will this product address it?
For this information, see the project proposal, target audience and benefits, and user needs.
How is this Software Requirements Specification organized?
This main page provides an overview of the system's use cases, functional, non-functional, and environmental requirements. Attached worksheets deal with specific aspects of the overall system requirements, such as use cases and feature specifications.
What are the most important facts that any project stakeholder should know about this SRS?
The core of the SRS is the use case suite and feature set. Project stakeholders should read through the non-functional and environmental requirements, then focus on understanding the use cases, features, and how they relate to each other.
There are a few key rules to follow whenever we update the SRS:
  • The SRS is our answer to user needs. Update user needs before updating the SRS.
  • The use cases and feature specs are two complementary perspectives on the same information. If you have good idea while working in one perspective, update the other perspective to check yourself.
  • Whenever possible, write requirements with precise facts, formulas, rules, or tables rather that prose.
This product started off very similar to LEGACY-SYSTEM, but we are gradually moving toward NEW-DIRECTION.

Use Cases

What are the main themes of the use cases?
We have imposed a maximum of two user actions on the e-commerce engine high frequency use cases that are most important to our business success. E.g., adding a product to the shopping cart takes one click, and reordering a product also takes just one click plus confirmation.
We have derived the use cases from the user stories. The user stories from the customer are driving the use case writing process.
We are developing a reusable component rather than an end-user application, so we are documenting how short sequences of calls can help an application program accomplish a user goal.
This is a server component that does not have a user interface, so we are documenting steps for the administrator to change the configuration file or command-line options and see the results.
Who are the users of the system?
Actors are described in the user needs document.
What are the use cases of this system?
The use case suite lists all use cases in an organized way.

Functional Requirements

What are the main themes of the product features?
Since this product is in a mature market with many competitors, our feature set focuses on covering competitive requirements, while at the same time simplifying administration of the product.
FEATURE-AREA is the most important part of the entire feature set. Note that we have decided not to have ANTI-FEATURE or ANTI-FEATURE because they are out of the scope of this product.
We have focused the feature specifications on the precise syntax of valid user input. That focus should give good guidance for design and a head start on achieving our security goals.
We have focused the feature specifications on state-based behavior and logical invariants because they help us avoid some potential dangerous failures.
What are the features of this system?
The feature set lists all features in an organized way.

Non-Functional Requirements

TODO: Describe the non-functional requirements for this release. Consider how the reusable sample text relates to your project or prompts you to think of new ideas. Add, edit or delete text as needed.
What are the usability requirements?

Our main usability requirement is minimizing the difficulty of performing each high-frequency use case. Difficulty depends on the number of steps, the knowledge that a user must have at each step, the decisions that a user must make at each step, and the mechanics of each step (e.g., typing a book title exactly is hard, whereas selecting a title from a list is easy).

The user interface should be as familiar as possible to users who have used other web applications and Windows desktop applications. E.g., we will follow the UI guidelines for naming menus, buttons, and dialog boxes whenever possible.

The type of user most sensitive to first-time usability is the consumer. Business consumer users are more concerned about UI efficiency. Our product must also provide highly usable administrative features that help visualize traffic and sales information to support decision-making by department managers.


  • Government customers will demand section508 compliance
  • We shall support learnability by following principles of Instructive Interaction
  • The product shall provide extensive on-line help including a concept index, function index, error index, and context-sensitive descriptions of each UI field.
  • The e-commerce engine UI shall include specific support for the business consumer reordering task.
  • All screens requiring user action shall include a textual prompt explaining that action.
  • The checkout process shall reduce the percentage of abandoned shopping carts by 10% compared to LEGACY-SYSTEM.
  • The system shall score above THRESHOLD on METRIC.
  • The system shall pass a usability review by CONSULTANT.
What are the reliability and up-time requirements?

Our main requirements for reliability are that the system should continue normal operations for as long as possible without exhausting server resources (e.g., a memory leak or runaway process) or requiring routine administrator maintenance, and that the system should limit the impact of any errors and continue processing new requests.

It must be possible to operate the system over long periods of time with minimal scheduled down-time. System backups must be done without halting the system. System software upgrades must be possible with less than one hour of downtime.

The software product must support automatic fail-over among identical machines within the local server cluster. Local fail-over must occur without loss of any completed transactions. Local fail-over must be safely testable.

The software product must support operator-initiated catastrophic fail-over from one server cluster to a completely independent cluster of similar machines at a remote location. Catastrophe recovery must not take more than four hours and must not lose more than 30 minutes worth of completed transactions.


  • The system shall be demonstrated to process more than seven days worth of transactions without significant leaking of temporary system resources.
  • A correct and consistent backup of the system's data must be possible at any time without halting or delaying any transaction beyond its normal timeout.
  • The system shall interoperate with our application monitoring server. E.g., the monitoring server may safely perform a test transaction once every minute.
  • The system shall need less than two hours per month of routine administrator maintenance, e.g., reviewing log files and testing backups. This maintenance shall not require any downtime.
  • The system (when hosted by our operations team) shall achieve 99% uptime. That means: less than 8 hours of downtime each month.
  • The system (when hosted by our operations team) shall achieve 99.9% uptime. That means: less than 43 minutes of downtime each month.
  • The system shall score above THRESHOLD on METRIC.
What are the security requirements?

The main security requirements are user authentication and authorization, encryption of communications, and rejection of malicious input.

The system must prevent hackers or malicious users from abusing the system from the outside, and provide a few key limits on access to sensitive information by insiders.


  • Access shall be controlled with usernames and passwords.
  • Passwords shall be checked for quality.
  • Only administrator users shall be authorized to access administrative functions, average users will not.
  • This website shall use encrypted communications (SSL).
  • The system shall check all user-supplied input for malicious content (e.g., escape characters, inappropriate markup, and buffer overflow attacks).
  • The system (when hosted by our operations team) shall be able to have a security patch installed within four hours of its availability and approval.
  • The system shall score above THRESHOLD on METRIC.
  • The system shall pass a security audit by CONSULTANT.
What are the performance and scalability requirements?

Our main performance requirement is that the system maintain interactive response times. In no case should users perceive that the server is slow or hung, and they should never see a server timeout message.

Our main scalability requirements are the ability to host the server software on a cluster of machines that can be upgraded over time, and the ability to add new auxiliary software components without substantially slowing the main functions of the server.


  • When not under any load, the server shall begin sending a response to any page request within one second.
  • The system shall produce REPORT-NAME in less than one second for each 5,000 records selected.
  • Under normal load, the system shall begin sending a response to each request within two seconds on average and ten seconds in the worst case.
  • The system shall allow up to four web servers in the cluster.
  • The system shall allow a second application server to be added to the cluster.
  • The system shall allow up to 100 event listeners to monitor EVENT-TYPE events without significant slowdown.
  • The system shall maintain an average throughput of 50 pages per second in our production environment.
  • The capacity of the system shall scale up to 1,000,000 RECORD-TYPE records and 1,000 RECORD-TYPE records.
  • The system shall score above THRESHOLD on METRIC.
  • The system architecture shall pass a review by the operations department manager.
What are the maintainability and upgradeability requirements?

Maintainability is our ability to make changes to the product over time. We need strong maintainability in order to retain our early customers. We will address this by anticipating several types of change, and by carefully documenting our design and implementation.

Upgradeability is our ability to cost-effectively deploy new versions of the product to customers with minimal downtime or disruption. A key feature supporting this goal is automatic download of patches and upgrade of the end-user's machine. Also, we shall use data file formats that include enough meta-data to allow us to reliably transform existing customer data during an upgrade.


  • Instances of the product deployed in the field shall periodically check for available upgrades, automatically download them, and install them.
  • Each data file shall be marked with the exact version number of the file format.
  • The system shall be able to read and write previous file formats.
  • The product shall include API documentation, a plug-in mechanism, developer FAQ, and other support for third-party developers.
  • A new developer shall reasonably be able to understand all internal logic of COMPONENT-NAME within three days.
  • The system shall score above THRESHOLD on METRIC.
What are the integration, customization, and internationalization requirements?

Our main integration requirement is to allow a third-party systems integration firm to perform an integration that covers four areas:

  • Data integration: see import/export requirements below.
  • Control flow integration: see API requirements below.
  • UI integration: see UI requirements above.
  • Business process integration: see life-cycle requirements below.

Our main customization requirement is to allow a systems integration firm or customer system administrator to customize the appearance and behavior of the system through extensive configuration files.

Our main internationalization requirement is to allow a third-party system integration firm or reseller to localize the product to a new market without any changes to the core product engine.


  • All user-visible strings shall be factored out of program source code and kept in simple text files, identified by locale code letters.
  • The system's user interface shall be customizable by replacing CSS files, images, HTML fragments, and other data.
  • Aspects of the design shall pass a review by LOCALIZATION-PARTNER.
What are the supportability requirements?

Supportability is our ability to provide cost effective technical support. Our goal is to limit our support costs to only 12% of annual licensing fees. The product's automatic upgrade feature will help us easily deploy defect fixes to end-users. The user guide and product website will include a troubleshooting guide and checklist of information to gather before contacting technical support.


  • The product shall include a FAQ and troubleshooting guide aimed at answering questions and resolving problems without technical support calls.
  • All screens shall have a unique title. All error messages shall have a unique ID number. All error dialogs shall allow copying of text to the operating system clipboard. These features will help users precisely identify the problem that they are reporting to a technical support engineer.
  • The number of support calls shall be reduced 10% as compared to LEGACY-PRODUCT.
  • The system shall score above THRESHOLD on METRIC.
  • The system use cases, feature specs, and UI design shall pass a review by the technical support department manager.
What are the business life-cycle requirements?

The business life-cycle of a product includes everything that happens to that product over a period of several years, from initial purchase decision and deployment, through important but infrequent use cases, until product retirement. Key life-cycle requirements are listed below.


  • Customers shall be able to run an evaluation copy of the product.
  • Customers shall be able to manage the number of licenses that they have and make informed decisions to purchase more licenses when needed.
  • The product shall support both daily operations and a year-end audit.
  • The product shall not have y2k-type limitations that prevent its continued use.
  • The customer data shall be stored in a format that is still accessible even after the application has been retired.
  • The system shall have 10% lower total cost of ownership than LEGACY-PRODUCT.
  • The system shall score above THRESHOLD on METRIC.

Environmental Requirements

TODO: Describe the environmental requirements for this release. Environmental requirements describe the larger system of hardware, software, and data that this product must work within. Some reusable sample text is provided below.
What are the system hardware requirements?

Our minimum hardware requirement is a low-end server machine.



System Processor:800MHz PROCESSOR-TYPE
System Memory:256MB
Free Disk Space:10MB
Operating System: Windows 2000, Windows XP, Mac OS X, Linux (kernel 2.4)
Networking:Internet access
What are the pre-installed software requirements?

We expect the software environment to include specific software on the server-side and client-side.


  • Server-side
    • Standard Java serlvet container
  • Client-side
    • Standard e-mail client
    • Popular web browser (IE6, NN7)
    • Custom application client
What application program interfaces (APIs) must be provided?

Our main API requirement is to implement STANDARD-API-NAME. We will also interoperate over PROTOCOL-NAME.

It is important for us to provide a plug-in API for third-party developers building add-ons to our product.


What are the data import and export requirements?

Our main data compatibility requirements are to work with past versions of our own product, export to STANDARD-FORMAT, and import from COMPETING-PRODUCT.


  • The system shall store all data in a standard SQL database, where it can be accessed by other programs.
  • The system shall store all data in an XML file, using a standard DTD.
  • The system shall read and write valid .XYZ files used by COMPETING-PRODUCT
  • The system shall read and write data saved in formats used by previous versions of our product.
TODO: Check for words of wisdom for additional advice on this template.
Company Proprietary
Copyright © 2003-2004 Method Labs. All rights reserved. License terms. Retain this copyright statement whenever this file is used as a template.