Software Requirements Specification Template · Web viewDocument for Version 1.0 approved Prepared by Approvals

Business Requirements

Document

for

<Project>

Version 1.0 approved

Prepared by <author>

<organization>

<date created>

Approvals<Indicate the status of the document following submission for approval. List the names and positions of the individuals who must approve the document, particularly the project sponsor. You may wish to add some descriptive text to make sure all of these individuals agree on what their signature of approval means. For example, approving the document could mean that the signatory agrees with the content as presented here, agrees to use this document as a basis for the project, and agrees to keep the information in the document current and relevant.>

Approval Decision:

Approved, development of detailed project plan is authorized Approved, project execution is authorized Approved, but project is on hold until future notice Revise document and resubmit for approval Document and project proposal are rejected

Role or Title Name and Signature Date

Revision HistoryName Date Reason For Changes Version

Business Requirements Document for <Project> Page v

Table of ContentsApprovals.................................................................................................................................. iiiRevision History........................................................................................................................ ivTable of Contents....................................................................................................................... v1. Introduction.......................................................................................................................... 1

1.1 Purpose..................................................................................................................................11.2 References..............................................................................................................................1

2. Overall Description.............................................................................................................. 22.1 Product Perspective................................................................................................................22.2 Product Features.....................................................................................................................22.3 User Classes and Characteristics.............................................................................................22.4 Design and Implementation Constraints..................................................................................22.5 Assumptions and Dependencies..............................................................................................2

3. Functional Requirements..................................................................................................... 33.1 Solution Context Diagram......................................................................................................33.2 Actor Descriptions..................................................................................................................43.3 Master Events List..................................................................................................................63.4 Event Name 1.........................................................................................................................83.5 Event Name n.......................................................................................................................10

4. Data Requirements............................................................................................................. 115. Non-functional Requirements...........................................................................................12

5.1 Performance Requirements...................................................................................................125.2 Safety Requirements.............................................................................................................125.3 Security Requirements..........................................................................................................125.4 Software Quality Attributes..................................................................................................125.5 User Documentation.............................................................................................................125.6 Operating Environment.........................................................................................................12

6. Transition Requirements................................................................................................... 137. Change Management......................................................................................................... 14Appendix A: Glossary.............................................................................................................. 15Appendix B: Traceability Matrix............................................................................................ 15Appendix C: Issues List............................................................................................................. 15

Business Requirements Document for <Project> Page vi

Business Requirements Document for <Project> Page 1

1. Introduction

1.1 Purpose

<Identify the product whose software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this BRD, particularly if this BRD describes only part of the system or a single subsystem.>

1.2 References

<List any other documents or Web addresses to which this BRD 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

<Describe the context and origin of the product being specified in this BRD. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the BRD defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful.>

2.2 Product Features

<Summarize the major features the product contains or the significant functions that it performs or lets the user perform. Details will be provided in Section 3, so only a high level summary is needed here. Organize the functions to make them understandable to any reader of the BRD. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or a class diagram, is often effective.>

2.3 User Classes and Characteristics

<Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the favored user classes from those who are less important to satisfy.>

2.4 Design and Implementation Constraints

<Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).>

2.5 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated in the BRD. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).>


3. Functional Requirements<This template illustrates organizing the functional requirements for the product by system function based on event, the major services provided by the product..>

3.1 Solution Context Diagram

<This first page of the Functional Requirements Section should show a context diagram for the entire system showing all Actors and Use Cases. If there are too many Use Cases (>10) leave them out and show Actors only An example is provided.>

Use CaseActor


3.2 Actor Descriptions

<Complete this Actor Description page for each Actor on the Context Diagram>

Actor Name A name that describes the role the actor plays in relation to the system (one or two words).

Description A brief description of who or what the actor is.

User and Shareholder Mapping

Map this actor to stakeholders and uses of the system by listing the job functions corresponding to these actors. For each user and stakeholder type, identify the number of users.

Type Number Type Number

Goals and Relationships with the System

Describe what the actor expects from the system. If the use case is successful, what will be the result for this actor? What will the result if the use case is unsuccessful?

Frequency of Use How often this actor will use the system (once weekly? 20 times per day? For every transaction?)

Physical EnvironmentDescribe the physical environment in which the actor will be using the system. Also include other applications used by this actor, operating systems, and so on.

General Characteristics Include level of expertise at job task, computer literacy, language, age, and so on.


<Repeat the Actor Description for each Actor on the Context Diagram>


3.3 Master Events List

Event Name Process Name

<Insert the names of all the events> <Insert the names of the corresponding Process>



3.4 Event Name 1

<Don’t really say “Event Name 1.” Take the first event name from the Master Events List.>

Process Name 1

<This is the name of the process that is executed when the Event occurs.>

Process Description

<Describe the Process in a short paragraph.>

Use Case Diagram

<Insert a Use Case Diagram showing the Process Name and all Actors involved with this Process Remember, all these Actors must be on the Context Diagram at the beginning of the Functional Requirements Section and described in the Actor Descriptions.>


Use Case Scenarios

<Include all Use Case Scenarios for this Event/Process. There will be 1 Main Scenario and many Secondary (Alternate and Exception) Scenarios. Use any standard format.>

Interfaces

<Any prototypes that were developed for the interfaces should be included here.>

Workflow

<Insert details of the internal process. This may include workflow models, a swimlane diagram, decision tables and text.>

Non-Functional Requirements

<In this section you should include any non-functional requirements that are for this Use Case only.>


3.5 Event Name n

<Repeat the event details section for each event.>


4. Data Requirements<In this section, insert a Logical Data Model detailing the Entities, Attributes and Relationships of the data required to support the processed detailed in the previous section. An simple example is provided to get you started.>

is bought bybuys

CUSTOMERCustomer NumberCustomer NameCustomer Address

PRODUCTProduct Number

Product Description

Product PriceQuantity on Hand


5. Non-functional Requirements<These are only some of the possible Non-Functional Requirements. Use categories to separate them into logical sections>

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.>

5.5 User Documentation

<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.>

5.6 Operating Environment

<Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.>


6. Transition Requirements

<Transition Requirements deal with constraints to the project during the transition from the AS-IS to the TO-BE. At the end of the project, all transition requirements should have been satisfied and are no longer relevant.>

<Transition Requirements can be either Functional or Non-functional. Follow the format from the previous sections accordingly.>


7. Change Management

<Every document, whether signed or not, is subject to change. In this section, detail the method by which this particular document can be changed. This will include forms to be filled out, presentations to be made, a list of who decided whether changes are acceptable or not, etc. Include a flowchart if you feel it will provide clarity. If this process is standard for the organization then it is sufficient to reference it here>


Appendix A: Glossary<Define all the terms necessary to properly interpret the BRD, 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 BRD.>

Appendix B: Traceability Matrix<Optionally, include a Traceability Matrix to show that no features in the Project Charter or Vision and Scope document have been missed and no requirements have been added without due consideration >

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.>

Documents

Software Requirements Specification Template · Web viewDocument for Version 1.0 approved Prepared by Approvals