–
Project Name
Software Requirements Specification
(SRS)
<Date>
Prepared By <Author Name>
Software Requirements Specification
Table of Contents
– 1
Introduction 4
Project Identification 4
Software Application/System Proposed Solution and Scope 4
Software Application/System Overview 4
Software Application/System Perspective 4
Software Application/System Functions 4
User Classes and Characteristics 5
Operational Requirements Summary 5
Design and Implementation Constraints 5
Assumptions and Dependencies 6
External Interface Requirements 7
User Interfaces (Inputs/Outputs) 7
Reports 7
Hardware Interfaces 8
Software Interfaces 8
Communication Interfaces 8
Data Requirements 10
Data Requirements 10
Functional Requirements 11
Primary Edit Specifications 11
Summary Edit Specifications 12
Load Specifications 13
Data Submission Document 14
Data Entry Portal Requirements 15
Other Functional Requirements 17
Non-Functional Requirements 17
Performance Requirements 18
Security Requirements 18
Software Quality Attributes 19
Business Rules 19
Documentation and Training Requirements 20
Other Requirements 20
Acceptance Criteria 21
Acceptance Criteria 21
Appendix A: Glossary 22
Glossary 22
Appendix B: Analysis Models 24
Analysis Models 24
Appendix C: To-Be-Determined List 25
To-Be-Determined List 25
temp_srs_el.doc Page 2 of 26
Ohio Board of Regents / SOFTWARE REQUIREMENTS SPECIFICATIONPurpose: The purpose of the Software Requirements Specification (SRS) is to document software requirements for the software application/system being considered for development. The SRS should be used in conjunction with the business requirements documented in the Project Initiation Document, technology requirements defined in the Technical Evaluation Document, requirements management provided by the Traceability Matrix, and the support requirements captured in the Support Expectations Document.
Introduction
The Introduction section of the SRS provides Project Identification information and an overview of the SRS to help the reader understand how the SRS is organized and how it should be read and interpreted.
Project Identification
Project Name / Project Number / Date CreatedProgram Manager / Project Manager
Completed by
Software Application/System Proposed Solution and Scope
Summarized Scope and Benefits Statement< Provide a short description of software application/system being specified, purpose, and benefits. Provide a context diagram to help understand the proposed software application/system. Reference business requirements (scope, vision, high-level requirements) contained in the Project Initiation Document (Proposed Solution and Project Scope statements). >
Software Application/System Overview
The Overview section of the SRS provides a high-level summary of the software application/system being specified, the environment in which it will be used, the anticipated users, and any known constraints, assumptions, and dependencies.
Software Application/System Perspective
Architectural Alignment< Explain how the software application/system relates to the enterprise architecture, current software applications/systems and other releases. Include any interfaces to other systems. >
Software Application/System Functions
Major Functions< Summarize the major functions the software application/system must perform. Provide a high-level summary in this area, which may include major groups or categories of requirements. A graphical representation of the major groups may be used to help the reader understand the requirements. Graphical representations may be included such as functional decomposition diagrams, top-level (conceptual) data flow diagrams, and or class diagrams. >
User Classes and Characteristics
User Classes / Characteristics<Identify all user classes. User classes include different types of users, as well as other systems that may interface (use) the software application/system being specified. > / <Describe the user classes, how they will use the software application/system, frequency of use, experience level, and anticipated number. Reference the Project Initiation Document for primary users. >
<Note: Identification and documentation of the user classes ensures that functional requirements are defined to meet the needs of all the different types of users. User classes help to identify the necessary use cases, which are elaborated into functional requirements. >
<Other User Class> / <Other User Class Characteristics>
<Other User Class> / <Other User Class Characteristics>
Web Changes and Additions
Web Page Definition<Indicate if the project/application requires new or changes to existing web pages. Determine if the web pages are inside or outside HEI’s domain. Evaluate how many web pages will be required and whether the pages are primary, secondary, or affiliated pages. Only select “Primary” if you are requesting a change to the main Regents home page or the top level page of one of the seven Regents portal pages (i.e., Students & Families). Only select affiliated if the web pages are being created (or changed) in conjunction with an outside agency or organization (i.e., OCAN, TRIO). All other web pages fall into the “Secondary” type. / New Web Pages Required
Yes No
Changes to Existing Web Pages Required
Yes No
Domain
Regents HEI N/A
Web Page(s) Type (check all that apply):
Primary Secondary
Affiliated
<Indicate ongoing support and maintenance requirements to support the project/application. > / Specific Maintenance Requirements
Yes No
Web Manager/Webmaster Communications
Contact HEI Web Manager for additions and changes within HEI’s domain. Contact the Regents’ Webmaster for additions and changes outside of HEI’s domain. / Contacted HEI’s Web Manager
Yes No N/A
Contacted Regents’ Webmaster
Yes No N/A
Operational Requirements Summary
Data Center<Indicate if the project/application requires a new server. Evaluate how much disk space will be required and estimate memory size needed. Determine if additional data center floor space is required and monitoring specifications if any. > / New Server Required
Yes No
Additional Center Space Required
Yes No
<Indicate ongoing support and service level requirements from Computer Operations to support the project/application. > / Specific Monitoring Requirements
Yes No
Network Communications (LAN/WAN)
<Identify any additional data or voice infrastructure requirements> / New Data or Voice Infrastructure
Yes No
Workstation
<Describe any additional workstation configuration needed. Indicate security requirements to support the application. > / New Workstation Configuration
Yes No
Security Requirements
Yes No
Disaster Recovery
<Indicate the backup requirements over a 12-month period. This could be Daily, Monthly, Weekly, As Requested, or Independent. Determine the escalation timeline in case of hardware or software failure. Critical ranges could be less than 4, 8, or 12 hours and semi-critical ranges could be less than 24, 36, or 72 hours. Identify primary and secondary departmental contacts. > / Backup Requirements
Yes No
Design and Implementation Constraints
Issues Identification and Description< Describe any specific design or implementation constraints associated with the software application/system being specified. Consider constraints such as technology, infrastructure, and enterprise architecture limitations, development standards, corporate, governmental and industry policies, and hardware and timing constraints. >
Assumptions and Dependencies
Assumptions and Dependencies Affecting Stated Requirements< List any assumptions that were used in developing the SRS. For example, if commercial components will be used in development of the software application/system, include these assumptions in this area. >
<List any dependencies the requirements have on external factors. For example, some components may be developed as part of another project, which will address requirements defined in the SRS. >
<Note: Assumptions and dependencies provided in this section of the document should include entries not listed in the Project Initiation Document>
temp_srs_el.doc Page 6 of 26
Ohio Board of Regents / SOFTWARE REQUIREMENTS SPECIFICATIONExternal Interface Requirements
The External Interfaces Requirements section of the SRS provides information on the external interfaces of the software application/system to ensure that the specified product will connect properly to external components.
User Interfaces (Inputs/Outputs)
/User Interface Identification / Source of Requirement / User Interface Characteristics /
< Identify and list the software components that require user interfaces. User interfaces include menu structures, screen/window designs, report layouts and other interfaces to users. > / < List the source organization and contact, if available, for the requirement. > / <For each user interface define logical characteristics. Include characteristics such as GUI standards, style guides, screen layout or resolution constraints, standard buttons and navigation links, shortcut keys, and error message displays. >
<Note: Prototypes, screen shots, and mockups may be used to help elicit requirements.
Detailed user interface information is developed during the Design phase and documented in technical design documents. >
<Other User Interface> / < Source > / <Other User Interface characteristics>
<Other User Interface> / < Source > / <Other User Interface characteristics>
Reports
/Report Identification / Source of Requirement / Report Characteristics /
< Identify and list the reports that are required as output of the software application/system. > / < List the source organization and contact, if available, for the requirement. > / <Reports should include a complete narrative of the appearance of the output and its purpose. It does not describe the actual logic of generating the report. (See Functional Requirements.) A mockup of the report with sample output may be provided, giving an example of what the user should see or what is returned to the user.
<Other Report> / < Source > / <Other Report characteristics>
<Other Report> / < Source > / <Other Report characteristics>
Hardware Interfaces
/Hardware Interface Identification / Source of Requirement / Hardware Interface Characteristics /
< Identify and list the interfaces between software components and hardware components of the system. > / < List the source organization and contact, if available, for the requirement. > / <For each hardware interface define logical characteristics. This may include components such as supported device types, data and control interactions, and communication protocols. >
<Other Hardware Interface> / < Source > / <Other Hardware Interface characteristics>
<Other Hardware Interface> / < Source > / <Other Hardware Interface characteristics>
Software Interfaces
/Software Interface Identification / Source of Requirement / Software Interface Characteristics /
< Identify and list the interfaces between the specified software application/system and any other software components. > / < List the source organization and contact, if available, for the requirement. > / <For each software interface define the connections. This may include interfaces with databases, operating systems, tools, libraries, and other commercial components. Identify and describe the data or messages exchanged or shared among software components. >
<Other Software Interface> / < Source > / <Other Software Interface characteristics>
<Other Software Interface> / < Source > / <Other Software Interface characteristics>
Communication Interfaces
/Communication Interface Identification / Source of Requirement / Communication Interface Characteristics /
< Identify and list the communication interfaces. For example, e-mail, Web browser, log files, network communications standards or protocols. > / < List the source organization and contact, if available, for the requirement. > / <For each communication interface define pertinent message formatting. Specify any security and encryption issues, data transfer rates, and synchronization mechanisms. >
<Other Communication Interface> / < Source > / <Other Communication Interface characteristics>
<Other Communication Interface> / < Source > / <Other Communication Interface characteristics>
temp_srs_el.doc Page 13 of 26
Ohio Board of Regents / SOFTWARE REQUIREMENTS SPECIFICATIONData Requirements
The Data Requirements section of the SRS provides information on the data used by the software application/system. This is limited to creating tables and referencing existing tables relative to the storage of data. Data requirements may also be modeled with data flow diagrams, entity-relationship diagrams, and other data analysis techniques and are included in Appendix B.
Data Requirements
Explanation of Field Categories/Groups:Field Category/Group / Logical Field Name / Field Type Comment / Field Length / Field Description / Source of Requirement / Required for all Records? / Unique Identifier?
< Field Category/Group> / < Field name> / <Enter the type of field; e.g. name, number, date, dollar, code / <No. of char> / <Describe each data element (entity) including characteristics (attributes), how the data is used, relationship (associations) with other data types. Use appropriate data models, entity relationship diagrams, and other data analysis models to document the data requirements. Include (or attach) all analysis models in Appendix B of the SRS.> / < List the source organization and contact, if available, for the requirement. > / Yes
No / Yes
No
< Field Category/Group> / < Field name> / <Field type> / <No. of char> / <Description> / < List the source organization> / Yes
No / Yes
No
< Field Category/Group> / < Field name> / <Field type> / <No. of char> / <Description> / < List the source organization> / Yes
No / Yes
No
< Field Category/Group> / < Field name> / <Field type> / <No. of char> / <Description> / < List the source organization> / Yes
No / Yes
No
< Field Category/Group> / < Field name> / <Field type> / <No. of char> / <Description> / < List the source organization> / Yes
No / Yes
No
Functional Requirements
The Functional Requirements section of the SRS provides information on the functions that the software application/system must include. This section should describe the business logic or steps used to extract and manipulate data. It describes how to generate a report. (For report formatting, see Reports.) The author of the SRS should organize the functional requirements by major feature, functional hierarchy component (IEEE 1998), use case, object class, or scenario depending on the characteristics of the software application/system being specified.
Primary Edit Specifications
<File Name 1Edit Number / Error Code / Pseudo CodeProgramming Logic / Business Logic / Edit Message Text / Display Value
E1-1 / XXX / <Write the pseudo code that is used by the programmer> / <Type in the logical reason behind this error for web display> / <From edit messages table> / <From edit messages table>
E1-2
E1-3
E1-4
E1-5
Summary Edit Specifications
S1-1
S1-2
Load Specifications
The load specifications are written for each new file created in HEI.
<File Name>
L1-1
<Load Instructions>
L1-2
<Load Instructions>
L1-3
<Load Instructions>
temp_srs_el.doc Page 13 of 26
Ohio Board of Regents / SOFTWARE REQUIREMENTS SPECIFICATION