Software Requirements Specification <Project Name>
<Project Name>Software Requirements Specification
Version: 1.0
Date: ______
Prepared by: ______
Page 15
Software Requirements Specification <Project Name>
Document Instructions
The project name is entered on the header where indicated by “<Project Name>”.
Areas where information is to be entered appear in darker gray shaded fields; these fields may be blank or may contain text instructions or samples. To enter information, click the gray field and begin typing; any instructional or sample text will be deleted when you begin typing.
Document Usage
This document is not a checklist and does not provide guidance on how to properly identify, gather, analyze, validate and verify requirements, and must not be used as such. It is solely for documenting the final outcome of the activities performed during the appropriate phase of the project.
Revision History
Date / Version / Author / Section / Change Summary /1.0 / Initial draft
Table of Contents
1. Introduction 4
1.1 Purpose 4
1.2 Scope 4
1.3 Definitions, Acronyms and Abbreviations 4
1.4 References 4
2. Functional Requirements 5
3. Business Rules 6
4. Data Definitions (Business Objects) 7
5. Use Cases 8
5.1 UC-1: <Use Case Name> 8
6. Non-Functional (System) Requirements 10
6.1 Availability 10
6.2 Efficiency (Performance) 10
6.3 Flexibility 10
6.4 Integrity (Security) 10
6.5 Interoperability 10
6.6 Reliability 11
6.7 Robustness (Fault Tolerance) 11
6.8 Usability 11
6.9 Maintainability 11
6.10 Portability 11
6.11 Reusability 12
6.12 Testability 12
6.13 External Interfaces 12
6.13.1 User Interfaces 12
6.13.2 Hardware Interfaces 12
6.13.3 Software Interfaces 12
6.13.4 Communications Interfaces 12
6.14 Design Constraints 13
6.15 Miscellaneous Requirements 13
6.15.1 Documentation Requirements 13
6.15.2 Purchased Components 13
6.15.3 Safety Requirements 13
6.15.4 Licensing and Security Requirements 13
6.15.5 Legal, Copyright and Other Notices 14
6.15.6 Applicable Standards 14
6.15.7 Internationalization and Localization 14
6.15.8 Physical Deliverables 14
6.15.9 Installation and Deployment 14
6.16 Supporting Information 14
6.16.1 Appendices 14
1. Introduction
1.1 Purpose
State the purpose of the document (to collect all functional requirements not expressed in the process model, as well as non-functional requirements and design constraints). Specify the intended audience for the document.
1.2 Scope
Identify the product(s) to be produced by name. Explain what the software product will and will not do. Describe the application of the software being specified, including relevant benefits, objectives, and goals.
Current System
Describe the current business system. Include a description of manual and automated processes. State why the system is being enhanced/replaced.
Desired System
Describe the desired system. Include a high-level description of any solution option(s) that may be known at this time.
1.3 Definitions, Acronyms and Abbreviations
· Provide the definitions of all terms, acronyms and abbreviations required to properly interpret the SRS. This information may be provided by reference to one or more appendices in the SRS or by reference to other documents.
1.4 References
· Provide a complete list of all documents referenced elsewhere in the SRS. Identify each document by title, report number (if applicable), date and publishing organization. Specify the sources from which the reference can be obtained.
2. Functional Requirements
¨ Describe the functional requirements of the system for those requirements that are expressed in the natural language style or are otherwise not included in any models. Requirements may be organized by any means that makes sense to project stakeholders.
¨
¨
¨
¨
¨
¨
¨
¨
¨
¨
¨
3. Business Rules
¨ Describe the business rules of the system. Business rules may be organized by any means that makes sense to the project stakeholders.
¨
¨
¨
¨
¨
¨
¨
4. Data Definitions (Business Objects)
Repeat this definition for as many objects as are defined in the project scope.
Object Name Name the business object in singular and without regard to its implementation.
Description Briefly describe the business object, or re-use the definition from the glossary section.
Function(s)
· List the CRUD functions to be performed on or with this data.
·
Data
· List the data elements, attributes or characteristics of the object.
·
Rules
· List the business rules (formulas, values, ranges, etc) and relational business rules associated with the object or its data elements.
·
5. Use Cases
Repeat this section for as many use cases as are contained within the project’s scope.
5.1 UC-1: <Use Case Name>
Scope: Indicate the scope of the use case.
Level: Indicate the level (summary, user goal, sub-function, etc.) of the use case.
Primary Actor: Indicate the actor that initiates the use case.
Stakeholders and Interests:
Indicate all stakeholders and their interests.
Preconditions:
List the preconditions (the state of the system prior to beginning the use case) of the use case.
Minimal Guarantees:
Indicate the minimal guarantee (the state of the system even if the use case is not successful).
Success Guarantees:
Indicate the success guarantees (the state of the system after successful completion of the use case; added to the minimal guarantee).
Trigger
Indicate the business event, performed by the primary actor, that begins the use case. (Optional: could be the first step of the use case narrative.)
UC-1: <Use Case Name> (continued)
Main Success Scenario:
Describe, via numbered steps, the perfect-world, best-case scenario of the use case.
Extension Scenarios:
Describe any alternative and/or exception scenarios of the use case (using whatever numbering scheme makes sense to the project stakeholders).
Technology and Data Variations:
Describe any variations of the use case that may result from variations of technology and/or data used in the process.
6. Non-Functional Requirements
Requirements that express some of the “attributes of the system,” or “attributes of the system environment.” They are not necessarily related to a specific business function or functional requirement, but instead, the behavior of the system as a whole.
6.1 Availability
State when the system should be available to its users. Indicate the business case for anything that seems "extreme" (i.e. 24/7/365). Include scheduled maintenance periods. Indicate how much down time would be tolererable by users.
6.2 Efficiency (Performance)
State the performance characteristics of the system, expressed quantitatively where possible and related to a specific business process where applicable.
6.3 Flexibility
Specify the need to extend, augment, or expand the system, especially if the system is to be developed in phases.
6.4 Integrity (Security)
Indicate requirements for blocking unauthorized access to system functions, preventing information loss, ensuring that the software is protected from virus, and protecting the privacy and safety of data entered into the system.
6.5 Interoperability
Indicate requirements to exchange data with other systems. List which other applications users will employ in conjunction with this one and what data they plan to exchange.
6.6 Reliability
Specify how long the software should execute without failure. Assess the impact of system failure and list requirements for minimizing and/or recovering from such failure.
6.7 Robustness (Fault Tolerance)
Indicate requirements that specify how the system should behave when confronted with invalid input, defects in connected software/hardware components, or unexpected operating conditions. Indicate, in general, how error conditions should be handled.
6.8 Usability
List requirements associated with "user-friendliness"; consider individual users and user classes, their capabilities and knowledge.
6.9 Maintainability
Describe requireuremts associated with correction of defects or modifications to the software. Critical for systems that undergo frequent update.
6.10 Portability
Specify the need to migrate the software to another platform or operating environment, now or in the future.
6.11 Reusability
Indicate the need to re-use components of the software within this system or in another system.
6.12 Testability
Specify requirements for verifying and/or testing the software. May be expressed as cyclomatic complexity, the measure of the number of logic branches in the source code (more branches and loops makes the module harder to test).
6.13 External Interfaces
6.13.1 User Interfaces
The logical characteristics of each interface between the software and its users, e.g. screen formats, page/window layouts, content of any reports, menus or queries, programmable function keys, etc.) necessary to accomplish the requirements.
6.13.2 Hardware Interfaces
Specify the logical characteristics of each interface between the software and the hardware components of the system, including configuration characteristics. List the devices to be supported, how they will be supported, and protocols.
6.13.3 Software Interfaces
Specify the use of other required software products and interfaces with other application systems. Include the name, mnemonic, specification and/or version number and source of the other software.
6.13.4 Communications Interfaces
Specify the various interfaces to communications such as local area network protocols, etc.
6.14 Design Constraints
Restrictions on the design of a system, or the process by which a system is developed, that do not affect the external behavior of the system but that must be fulfilled to meet technical, business, or contractual obligations.
6.15 Miscellaneous Requirements
6.15.1 Documentation Requirements
Requirements for user, administrator and/or system documentation.
6.15.2 Purchased Components
List the purchased components used with the system, licensing or usage restrictions, and compatibility/interoperability requirements.
6.15.3 Safety Requirements
Specify requirements that are concerned with possible loss, damage, or harm that could result from the use of the product. Define safeguards or action to be taken. Identify certifications, policies or regulations to which the product must conform.
6.15.4 Licensing and Security Requirements
Describe the licensing and usage enforcement requirements or other restrictions for usage, security and accessibility.
3.15 Miscellaneous Requirements (continued)
6.15.5 Legal, Copyright and Other Notices
State any required legal disclaimers, warranties, copyright notices, patent notices, trademarks or logo compliance issues.
6.15.6 Applicable Standards
Reference any applicable standards and the specific sections of any such standards that apply.
6.15.7 Internationalization and Localization
State any requirements for support and application of different user languages, dialects, character sets, time zones, work days, hours, holidays, etc.
6.15.8 Physical Deliverables
Define any specific deliverable artifacts required by the user or the customer.
6.15.9 Installation and Deployment
Describe any specific configuration or target system preparation required to support installation and/or deployment of the system.
6.16 Supporting Information
6.16.1 Appendices
The appendices are not always considered part of an actual SRS and are not always necessary.
Page 15