seilevel software requirements specification … · web viewthis section should contain org charts...

[Project Title]

Software Requirements Specification

Original Date:2.27.2014 8/21/2012 Document Version 0.1Last Revision Date:February 27, 2014 8/21/2012

Author InformationAuthor: Jane DoeTitle: Senior Business AnalystE-mail: [email protected]: 512-123-4567

Seilevel Software Requirements Specification Template

Table of Contents1 Document Revision History..................................................................................................................................3

2 Approvers & Reviewers........................................................................................................................................3

3 Document Purpose..............................................................................................................................................4

4 Assumptions.........................................................................................................................................................5

5 Constraints...........................................................................................................................................................5

6 Project Stakeholders............................................................................................................................................6

7 Requirements.......................................................................................................................................................7

7.1 Feature 1....................................................................................................................................................7

7.1.1 Feature 1 Models...................................................................................................................................7

7.1.2 Feature 1 Dependencies.........................................................................................................................7

7.1.3 Feature 1 Requirements.........................................................................................................................7

8 Non-Functional Requirements.............................................................................................................................8

9 UI Design............................................................................................................................................................10

9.1 UI Flows....................................................................................................................................................10

9.2 Screen 1....................................................................................................................................................11

9.2.1 Screen 1 Screen Shots..........................................................................................................................11

9.2.2 Screen 1 DAR Models...........................................................................................................................11

Appendix A – Glossary.......................................................................................................................................12

[Project Title] of 15


1 Document Revision HistoryCapture information about every published version in the table below, including a brief description of the changes in each version.

Date Version Section/Page Update Description Contact Name

12/1/2011 0.1 All Initial Draft Jane Doe

2 Approvers & ReviewersThe table below represents a list of all people that are required to review and approve the requirements document.

Name Role Responsibility Approval Date

Jane Doe Approver [Insert Description]



3 Document Purpose

The Software Requirements Specification describes the functional and nonfunctional requirements for software release that follows from a scope and vision document or a business requirements document. This document is intended for those who are implementing the software, as well as for testing and deployment.

Chapter Software Requirements Specification (SRS)

1 – Revision History Y2 – Approvals Y3 – Introduction Y4 – Assumptions Y5 – Constraints Y6 – Stakeholders Y7 – Project Overview M8 – Product Definition N9 – Requirements Y10 – Non-Functional Req Y11 – UI Design YAppendix A – Glossary Y



4 AssumptionsThis section contains the assumptions for a project. An assumption is a statement that is believed to be true in the absence of proof or definitive knowledge.

ID Assumption Assumption Owner

Impact if not True

5 ConstraintsThis section contains constraints on the project. A constraint is a restriction that is imposed on the choices available to the developer for the design and construction of a product.

ID Constraint Constraint Owner



6 Project OverviewThe Project Overview section is intended to describe the goals and objectives of the entire project, as well as to introduce the different product concept. The section should identify the business problems, business objectives, success metrics, and product concepts associated with the project.

6.1 Business Objectives ModelThis section will contain the Business Objectives Models and/or Key Performance Indicator Model. The purpose of the Business Objectives Model is to illustrate the Business Problems and Business Objectives of a project in a manner that can be easily consumed to understand the purpose of the project.

Business Problem 1

Business Problem 2

Business Objective 1

(SM)


(SM)


Business Problem 3

Business Problem 4

Business Problem 5

Business Problem 6



(SM)



Product Concept

High-Level Feature

High-Level Feature

High-Level Feature

Success Metric 2

Success Metric 1

Business Objectives Model Template

© Seilevel



6.2 Feature TreeA feature tree can be provided in the Project Concept discussion in order to provide additional information around the types of features that are associated with the project. These features are typically high-level at this stage.



6.3 High-Level L1 Process FlowThis section should contain a high-level L1 process flow which describes the project at a very high level so that the consumer of the document has a little context around the project.

Sometimes, this L1 is written such that each of the steps will become a Product Concept. In other cases, each Product Concept is a variation of this L1 that represents a different user scenario.

Use

r/U

ser G

roup

Use

r/U

ser G

roup

Incoming Step

Step

Step

Decision Point

Step

yes

Outgoing

Group A

Other process

no

Process Flow/ System Flow Template

© Seilevel

Event



7 Project Stakeholders

This section should contain org charts around various groups of stakeholders surrounding the project. Stakeholders include business stakeholders, product management, IT, and test. The org chart should include individuals involved in elicitation, review, development, and testing. It is also a good idea to identify those business stakeholders involved in UAT within these org charts.

Additional org charts and other models should be created to describe the various users of the product.

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

Team Title

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

NameTitle

Org Chart Template

© Seilevel



8 RequirementsThis section should contain additional context around the various features of a project, as well as the Business Requirements for a project. It is important to remember that a Feature is implementation agnostic. Implementation details should be captured in the Technical Design section.

8.1 Feature 1This section contains the entire context around a feature.

8.1.1 Feature 1 ModelsThe detailed models associated with a feature should be located here. Those models could include L3 process flows.

8.1.2 Feature 1 DependenciesThis section should list all of the dependencies a particular feature has on other features or other projects.

8.1.3 Feature 1 RequirementsThese requirements should be presented in a RMM. Acceptance Criteria and the Business Rules should be captured.

L1 Process Step L2 Process Step L3 Process Step Feature REQID Requirement Business Rule 1 Business Rule 2

Enter policy informationSelect existing submission Enter search criteria Search REQ001

Allow user to search for existing submissions

The exact capitalization or lack thereof used in spelling any and all search terms by the user will be ignored for the purpose of finding a match in the system.

The user can enter search terms using any combination of uppercase and lowercase characters.

Enter policy informationSelect existing submission Review search results Search REQ002 Allow user to sort by one column

Sort submission by priority, status, submission number, submission date, Primary Name Insured, Broker Name, Primary State, and Product.

Enter policy informationSelect existing submission Review search results Search REQ003 Allow user to sort by multiple columns

Sorting by multiple columns can be in any order that the user specifes for the columns selected.

Enter policy informationSelect existing submission Review search results Search REQ004

Allow user to sort ascending or descending for one or more columns

Sorting will first be ascending (a-z, 1-10), except for date, which will be descending.

Default search results to be ordered by creation date in descending order as the first ordered column.

Enter policy informationSelect existing submission Review search results Search REQ005

Allow user to further filter out search results using initial criteria options



9 Non-Functional RequirementsThis section will contain all non-functional requirements. Usually, non-functional requirements are established for the project as a whole, and not an individual feature. If the non-functional requirements are defined on a feature bases, they can be moved to the previous section. Types of Non-Functional Requirements to consider:

Availability - Desired “up time” during which the system and data are available for use. [The system shall be available between the hours of 6AM and 10PM ship time, inclusive, every day of the week.]

Documentation - Descriptions of any expected supplemental information, including its purpose, desired contents, level of detail, and formatting. [The system shall provide context sensitive help that takes the user to a help topic specific to the screen in focus which describes how to use each control and data field on the screen.]

Emotional - Describe the user’s feelings about the experience with the system, including where and when the emotions should be felt, and how they vary over time. [The system shall elicit a fun feeling for the passenger when they view the physical outputs from the system.]

Flexibility - How much effort is needed to add or change capabilities within the product. [The system shall allow for the addition of new fields of interest with no more than 2 hours of effort.]

Hardware Interfaces - Characteristics of each interface between the software system and the hardware components supported by the system. [The system shall be able to upload digital photographs directly from a digital camera to attach to the passenger profile.]

Legal - System constraints that are required by law. [The system shall not display any information the passenger marked as confidential on the passenger profile.]

Logical Databases - Any information that is required to be placed into a database, including data relationships, field types, frequency of use, integrity constraints and accessing capabilities. [The system shall maintain a history of passenger suggestions.]

Memory Constraints- Constraints on the system based on memory usage. [The client shall run on a system with 500 KB of memory, utilizing no more than 30% of the available system memory resources at anytime.]

Operations - System behaviors necessary for the support and operations of the system. [The system shall notify the administrator users by email and pager if the database server becomes unavailable.]

Performance - The speed with which the system accomplishes specific actions under specified conditions. [The system shall regenerate and display one passenger’s updated suggestions within 5 seconds of receiving the update request.]

Portability - Ability to migrate from one platform to another or one machine to another. [The system shall be designed such that the client runs in Windows XP now and in Windows Vista without code changes when the cruise ship upgrades its systems.]

Reliability - Specified period of time and conditions for which the software must execute without a failure. [The system shall operate without critical failure for a consecutive 72 hour period with



20 users simultaneously performing their common tasks. (See test plan for definitions of “critical failure” and “common tasks.”)]

Reusability - How easily a component of the system can be used by another system. [The system’s components to update the passenger profile shall be usable in the next release of the Passenger Tracking system.]

Robustness - Expected behavior when there is invalid data, defects, or unexpected errors. [The system shall inform the user of the issue and allow the user to continue working offline if the primary database server becomes unavailable.]

Security - Behaviors necessary to protect the software from accidental or malicious access, use, modification, destruction, or disclosure. [The system shall store all passwords using 128 bit encryption.]

Site Adaptation - Behaviors necessary to support customization of the product specific to where it will be installed or used, including details of the customizations, globalization, and localization. [The system shall display all time stamps in the cruise ship’s local time.]

Software Interfaces - Characteristics of each interface between the software system and other software components of the system or other systems. [The system shall support using the Event Schedule system’s data to match passenger interests to available programs.]

Testability - Behaviors of the system necessary to support testing the system. [All user interface components must react to scripted input from the testing tool exactly as if the user input the scripted data or command.]

Usability - Defines the ease with which end user classes can perform specific tasks with the software. [The user interface shall allow users to regenerate the passenger suggestions from within two clicks after updating their profile information.]



10 UI DesignOften, a separate design team is used to product the official screen shots or mockups for a product. Those design teams rely on business requirements in order to produce their deliverables. The UI requirements therefore often need to be presented in separate documentation, but can be captured here instead.

10.1 UI FlowsThe UI Flows are used to document how the screens flow from a user perspective.

Redirect userback to

prior screen

Home

About FAQ

Register

Logon

Take Quiz

Finished

Logged on? No

Success

Yes

Admin

Users

My Created Quizzes

Create

Edit Users

Edit Quizzes

Questions

My Account

View All Eligible Quizzes

Taken?NoPublished? No

Yes

Publish

OpenQuiz

View Taken Quizzes

View All Quizzes

ChooseQuiz Yes

Contact

Logged On

Admin

Creator

ChooseQuiz

UI Flow Example

© Seilevel



10.2 Screen 1This section contains the screen shots and DAR models for a particular screen.

10.2.1 Screen 1 Screen ShotsThis section contains the shots for a particular screen.

10.2.2 Screen 1 DAR ModelsThis section contains the DAR models for a particular screen. DAR models can often be presented better in a power point; in that case, link to the models from this location.

UI Element: Navigation Bar UI Element Description ID ELMT_0045 Description Navigation bar with links to various pieces of user information and functions UI Element Displays Precondition Display Always Company Logo

“About Us” link “How to Design” link “Sponsors” link “Suggestions” link “Welcome “ <user’s name> “My Account” link “My Quizzes” link “History” link “Log on” or “Log off” link

<User.role> is administrative

Add “Admin” link to the left of the “Log off” link

<User.role> is creator “Create Quiz” link to the right of “My Quizzes” link

UI Element Behaviors Precondition Action Response Always Select any link User taken to corresponding page



Appendix A – GlossaryThe key business terms and their definitions that are used in this document are documented here.

Term Definition


seilevel software requirements specification … · web viewthis section should contain org charts...

Documents