Category Software Documents writing

Business Requirement Specification

Business Retirement Specification Template

 

<enter project name>

Business Requirements Document

 

Document Instructions

<This document template contains directions for use or sample entries. These directions are enclosed in brackets  and are italicized. They are included to help you fill out the form. As you complete the form, delete these instructions.

Please follow this document naming convention to facilitate document search and retrieval:

 <project code (if appropriate)>  <project name (abbreviated)>  <document name (abbreviated)>  <version (if appropriate)>

 All documents should be posted to the appropriate project folder in SharePoint. >

Document History

<The document history is a log of changes that are made to the document, who made the changes, and when.  For example, the initial creation of the document may contain the following:  Version 0.1, Date 1/1/2004, Author Charlie Brown, Status Initial creation.  Subsequent updates to the document will be Version 0.2, 0.3, etc.  The first published version of the document should be Version 1.0.>

Version Date Author Status Section Revision Description
0.1 Initial Draft
1 First Published

Approvals

 <The required approvals for this document are outlined in the project Change Management Plan. SharePoint workflow approvals may be used In lieu of this Approval section. If utilizing SharePoint, attach this document to the Change Request list item. If utilizing the document, distribute the document and request electronic signatures to indicate approval.

Copy additional signature line and details as needed>

 Your signature below indicates that this document meets its objectives and is acceptable.

Signature Signature
<Name> <Name>
<Date> <Date>
<Title> <Title>
<Role> <Role>

 

Table of Contents

1.Purpose

2 .Glossary and Acronyms

3. Executive Summary

3.1. Background

3.2.Objectives

3.3.In Scope

3.4. Out of Scope

4 . Requirements Elicitation and Gathering

4.1. Approach Overview

4.2. References/Inputs

5. Business Model

5.1. Organizational Profile

5.2. High Level ‘As-Is’ Process Flow

5.3. High Level ‘To-Be’ Process Flow

5.4. Process Mapping

5.5. Gap Analysis.

6. Requirements Definition

7. Appendix

———————————-****************___________________

Now I am going to discuss about each paragraph in detail.

1.Purpose

The purpose of the Business Requirements Document (BRD) is to lay the foundation for the design and development of a technical solution through definition of the business’ needs and achieve the goals and objectives of the <enter project name> project. The BRD describes the high-level business process and outlines the business needs that will be fulfilled by the successful completion of the project. In combination with the Requirements Traceability Matrix (RTM), it identifies actual technical or system requirements for the solution.

The foundation for a successful project is built upon the quality and thoroughness of requirements gathering. The BRD establishes key requirements, objectives, and goals that drive all other subsequent lifecycle phases. The RTM describes the business problem to be solved in terms of verifiable and traceable characteristics and constraints. In addition to key program level requirements, the requirements capture operational concepts and program level interfaces. The RTM should be continuously referenced during the project lifecycle phases to ensure that the deliverables from the project meet the approved requirements.

Signoff requirements of the BRD, inclusive of the RTM, are defined in the project’s Change Management Plan. Approval by the project sponsor ensures the requirements will support achieving the project’s goals and objectives.

2. Glossary and Acronyms

<A general list of common terms and acronyms are listed. Provide any project-specific terms or acronyms that may be used within this document; remove any that do not apply.>

Table: Terms and Acronyms Used in This Document

ALS Ambulance Licensure Service
BIIT Bureau of Informatics & Information Technology
BEMS Bureau of Emergency Medical Services
BRD Business Requirements Document – Details the business solution for a project including the documentation of customer needs and expectations.

<If a project charter does not exist, this section is intended to provide a brief, one-page summary describing the purpose, background, objectives, and scope for the overall project. Sign-off of the document provides a foundation for the project team and base criteria for decision-making, prioritization, and issue resolution.

3. Executive Summary

 Delete this section if the project has an approved charter.>

[Enter the Executive Summary text here]

3.1. Background

<Provide high-level description of the problem/opportunity which originated the project.>

[Add text here].

3.2 .Objectives

<List top 3-5 objectives, including success criteria/measurements>

[Add text here].

3.3. In Scope

<List top processes, features, and/or functions addressed by the project>

[Add text here].

3.4. Out of Scope

<List top processes, features, and/or functions NOT addressed by the project>

[Add text here].

4. Requirements Elicitation and Gathering

4.1. Approach Overview

< In this section, provide a summary describing the approach, methods, and documentation of the business requirements, including: project drivers, key project stakeholders, main functions that will be performed by the system, and a general requirements documentation timeline.>

[Add text here].

4.2.References/Inputs

<Identify the sources of information/reference materials that were used to develop the Requirements Plan, such as:

  1. Author name, title, and publication date.2. Author name, title, and publication date.>

[Add text here].

5.Business Model

<Describe the current environment in detail to help identify and support the needs and goals described in the previous section.  Consider the following list of questions to help define the current environment

  • What are the current problems faced (without the system) today?
  • What problems should this system solve?
  • Do you have to do things manually that you would like to automate?
  • Do you have performance problems that need to change?
  • Do you have functional limitations that you would like to change?
  • Are you using packages that force you to constrain your business functionality to the boundaries of the package?>

[Add text here].

5.1. Organizational Profile

<Describe the organizational entities (program area, bureau, etc.) that are involved in or will be affected by the system being developed or modified. At a minimum, answer these questions: Who (including titles and roles) will be using the system? What are their levels of expertise?>

[Add text here].

 5.2 . High Level ‘As-Is’ Process Flow

<A high level process flow depicts pictorially the business function information.  It can be a valuable tool when explaining to others the business functions of a system. A process flow can illustrate the following elements: What elements are in place when the process is initiated? Who is responsible for initiating/performing the process? What are the inputs and outputs of the process? Who (or what) is the recipient of the process outputs? What procedural steps are completed during the process? What are the exit criteria of the process (i.e., what must be satisfied before the process ends?  This information can be developed in Visio using a basic flow, use case or swim lane diagram. >

[Add text or process flow diagram here].

 5.3.High Level ‘To-Be’ Process Flow

<This section should include an introduction describing the major functional areas of the system from users’ perspectives.  If the new system has been segmented into subsystems, the functional requirements are defined by subsystems.  The project team defines, by subsystems, those functions which the new system must perform in order to achieve the objectives and realize the benefits >

 <A high level process flow depicts pictorially the business function information.  It can be a valuable tool when explaining to others the business functions of a system. A process flow can illustrate the following elements: What elements are in place when the process is initiated? Who is responsible for initiating/performing the process? What are the inputs and outputs of the process? Who (or what) is the recipient of the process outputs? What procedural steps are completed during the process? What are the exit criteria of the process (i.e., what must be satisfied before the process ends?  This information can be developed in Visio using a basic flow, use case or swim lane diagram. >

[Add text or process flow graphic here.

 5.4      Process Mapping

<Processing Mapping allows the reader to quickly see how the current functions will be addressed by the proposed solution.  This can be done in narrative form or can be depicted in a table format.  This method is especially useful if there are multiple system modules or multiple systems within a solution.

[Add text or table here]

5.5. Gap Analysis

<A gap analysis compares the ‘as-is’ and ‘to-be’ processes and identifies which functional areas may not be fully addressed by the solution.  Recommended mitigating strategies and/or business process redesign should also be included.>

[Add text here]

6. Requirements Definition

To ensure traceability throughout the project lifecycle and adherence to the change management process, each detailed requirement for the project is defined within the RTM.

Requirements usually reflect a need from the business/program area and is a condition or capability that must be met or possessed by a system, product, service, result, or component to satisfy a contract, standard, specification, or other formally imposed document. Requirements include the quantified and documented needs, wants, and expectations of the sponsor, customer or other stakeholder. A requirement may include technical components if there is a specific business need associated with a technology platform, approach, or solution.

<Please refer to the PMM templates to access the RTM tool.  Please delete the descriptive text and insert a link to the RTM or embed the document here.>

7 . Appendix

<In this section add any additional information relevant to this document’s subject matter. >

[Enter text here]

 

What is Software Requirement Specification?

Software Requirement Specification

SRS describe entire system flow, overall functionality of the system, how the data will flow within the system. It describes each module functionality.

SRS also include use cases that explain user interaction with the system or software. It also describe non- functional requirements like security, availability etc.

 

Software Requirement Specification Template

 

Software Requirement Specification

For

<Project Name>

Version <X.X>

 

Prepared By
Name Designation email
Xxxxx xxxxxx Business Analyst [email protected]
Yyyyy yyyyy Project Manager [email protected]

 

Revision History
Name/Author Date Reason For changes Version
       

 

Contents

  1. Introduction. 2

1.1.       Purpose. 2

1.2.       Scope. 3

1.3.       Assumption and Dependencies. 3

1.4.       Overview.. 3

  1. General Description. 3

2.1.       Product Perspective. 3

2.2.       Product Functions. 3

2.3.       User characteristics. 3

2.4.       General Constraints. 4

2.5.       3.0. Specific Requirements. 4

 

1.     Introduction

Under the subsections of this section, an overview of the SRS is provided which can be deemed as an executive summery.

1.1. Purpose

Under this subsection the following aspect of SRS developed are mentioned in a brief manner.

  • The overall purpose of document.
  • The reason of its creation
  • Identity of the stakeholders for whom it is addressed.

1.2. Scope

Under this subsection, the following aspects of the overall software to be developed are mentioned in a briefs manner

  • Main Functions
  • What it will do?
  • What it will not do?
  • How it will be used?
  • Benefits
  • Objectives
  • Goal

1.3. Assumption and Dependencies.

Under this subsection, the factors influencing the requirements under the SRS are explained.

  • List of Factors
  • A brief description of each factor

1.4. Overview

Under this subsection, the structure of SRS document is described with reference to

  • The topic covered.

2. General Description

Under the subsections of this section, the general factors which affect the proposed software to be developed, and its requirements are mentioned.

2.1. Product Perspective

Under this subsection, nature of the software product to be developed is mentioned.

  • Nature of product
  • Functions(If a component or subsystem)
  • Identified Interconnection(if a component or subsystem)
  • Block diagram of product and its relationship with the external and internal environment.

2.2. Product Functions

Under this subsection, function of the software product are described in terms of

  • List of function performed.
  • Summary description of each function
  • An explanatory block diagrams of the function with their interrelationship.

2.3. User characteristics

Under this subsection, the characteristics of the user of product which affects requirements are mentioned in terms of

  • Classes of users.
  • Characteristic of each user class in terms of experience and technical expertise.

2.4. General Constraints

Under this subsection, the various constraints which influences the design and development of the proposed software product are mentioned i.e,

  • Regulatory Policies
  • Hardware Limitation
  • Interface to other application
  • Safety and security consideration.

3. Specific Requirements

Under the subsection of this section, the details of the requirements are elaborated to facilitate the developer to create the software design documents before commencing the coding activity. Attention is focused on following in this context

  • Individual requirements are defined keeping in mind quality characteristics.
  • Source of each requirement is defined and referenced properly.
  • All requirements are organized in a structured and logical manner.

3.1. Functional requirement

Under this subsection, all functional requirements which need to be implemented in relation to the product are specified.

3.1.1. Purpose

Under this, the rationale and intent of including the functional requirement is clarified.

3.1.2. Input

Under this input values which will be accepted by the product as input in context of the functional requirement are elaborated in terms of the source, valid range, timings, Operator requirements, and special interfaces required.

3.1.3. Operations

Under this the operations which will be performed by the product to transform the input in context of the functional requirement are elaborated in terms of the validity checks, response to abnormal conditions and type of processing required.

3.1.4. Outputs

Under this the output which will be generated by the product after processing the input, in context of the functional requirement are elaborated in terms of the destination, valid range, timing, handling of illegal values, error messages and special interface required.

3.2.External Interface requirements

Under this subsection, all the interfaces to the external entities which need to be implemented by designer specified in relation to the software product as under.

3.2.1.  User Interface

Under this the characteristic of the interface for the human interaction with the software product are specified in terms of screen format, layout, menus, relative timing for input  and outputs, programmable function keys, a list do’s and don’ts on how the system will appear to the user.

3.2.2. Hardware Interface

Under this, the logical characteristics of the interface between the software product and various hardware components are specified in terms of which device will supported, how they will be supported, block diagrams depicting the relationship between the hardware components and the software functions.

3.2.3.  Software Interface

Under this, the logical characteristics of the interface between the software product and various other eternally required software products are specified in terms of the technical name, version number, manner of communication in terms of message content and format.

3.2.4. Communication Interface

Under this, the various interfaces between the software product and various communication and network protocols are specified in terms of local network protocol.

3.3. Performance Requirement

Under this subsection, the details of the performance related requirement placed on the software product or the human interaction with the software product.

  • Static numerical requirements such as number of terminals, simultaneous users, files and records, size of tables and files.
  • Dynamic numerical requirements such as number of transactional task and amount of data to be processed within the time limits under normal and peak workload conditions.

3.4. Design Constraints

Under this subsection, the details of requirement placed on the software product as constraints which need to be taken in the account.

3.4.1. Standard compliance

Under this, the requirement related to existing standard and regulations which need to be compiled with the software product such as report formats, data naming convention etc..

3.4.2. Hardware Limitation

Under this, the requirement related to various hardware constraints and operating environment  which need to compiled with by the software product are specified.

3.5. Quality Characteristic

Under this subsection, quality requirement places on the software product as constraint.Relevent quality characteristic are selected from generic one such as correctness, efficiency, flexibility, security, maintainability, portability, reliability and usability.

3.6. Other Requirements

3.6.1.   Database
Under this the specific requirements of any database which need to be developed as a part of the software product are specified such as
  • Type of information to be used
  • Frequency of use
  • Accessing capabilities
  • Data elements and file description
  • Relationship between data elements, records and files.
3.6.2. Site Adaption Requirement

Under this the specific requirements related to any specific installation site environment which need to be supported by the software product are specified such as

  • Data or installation sequence specific to any site, mission or operational modes e.g safety mode.
  • Any customized software product features modification required for a specific site.

4. Supporting Information

Under the subsection of this section, all supporting information is included to ensure the completeness of the SRS such as

4.1. Definition, acronyms and abbreviation

Under this subsection, the meaning and definition of all keywords and short form used in the SRS document are given to facilitate proper interpretation with reference to appendix or other documents.

4.2.  References

Under this subsection, the list of documents reference in the SRS along with the title, reference id, date, author, document resources and web resources are given including the traceability table.

Find Below link to download SRS template.

SRS Template

Guidance for Use Case Document

 

Use Case Document

for

<Project Name>

 

Prepared by <author>

<organization>

<date created>

Revision History

Name Date Reason For Changes Version

 Guidance for Use Case Template

Document each use case using the template shown in the Appendix. This section provides a description of each section in the use case template.

1. Use Case Identification

1.1.Use Case ID

Give each use case a unique numeric identifier, in hierarchical form:  X.Y. Related use cases can be grouped in the hierarchy. Functional requirements can be traced back to a labeled use case.

1.2. Use Case Name

State a concise, results-oriented name for the use case. These reflect the tasks the user needs to be able to accomplish using the system. Include an action verb and a noun. Some examples:

  • View part number information.
  • Manually mark hypertext source and establish link to target.
  • Place an order for a CD with the updated software version.

1.3. Use Case History

1.3.1 Created By

Supply the name of the person who initially documented this use case.

1.3.2  Date Created

Enter the date on which the use case was initially documented.

1.3.3 Last Updated By

Supply the name of the person who performed the most recent update to the use case description.

1.3.4  Date Last Updated

Enter the date on which the use case was most recently updated.

2. Use Case Definition

2.1. Actor

An actor is a person or other entity external to the software system being specified who interacts with the system and performs use cases to accomplish tasks. Different actors often correspond to different user classes, or roles, identified from the customer community that will use the product. Name the actor(s) that will be performing this use case.

2.2. Description

Provide a brief description of the reason for and outcome of this use case, or a high-level description of the sequence of actions and the outcome of executing the use case.

2.3. Preconditions

List any activities that must take place, or any conditions that must be true, before the use case can be started. Number each precondition. Examples:

  1. User’s identity has been authenticated.
  2. User’s computer has sufficient free memory available to launch task.

2.4. Postconditions

Describe the state of the system at the conclusion of the use case execution. Number each postcondition. Examples:

  1. Document contains only valid SGML tags.
  2. Price of item in database has been updated with new value.

2.5. Priority

Indicate the relative priority of implementing the functionality required to allow this use case to be executed. The priority scheme used must be the same as that used in the software requirements specification.

2.6. Frequency of Use

Estimate the number of times this use case will be performed by the actors per some appropriate unit of time.

2.7.  Normal Course of Events

Provide a detailed description of the user actions and system responses that will take place during execution of the use case under normal, expected conditions. This dialog sequence will ultimately lead to accomplishing the goal stated in the use case name and description. This description may be written as an answer to the hypothetical question, “How do I <accomplish the task stated in the use case name>?” This is best done as a numbered list of actions performed by the actor, alternating with responses provided by the system.

2.8. Alternative Courses

Document other, legitimate usage scenarios that can take place within this use case separately in this section. State the alternative course, and describe any differences in the sequence of steps that take place. Number each alternative course using the Use Case ID as a prefix, followed by “AC” to indicate “Alternative Course”. Example:  X.Y.AC.1.

2.9. Exceptions

Describe any anticipated error conditions that could occur during execution of the use case, and define how the system is to respond to those conditions. Also, describe how the system is to respond if the use case execution fails for some unanticipated reason. Number each exception using the Use Case ID as a prefix, followed by “EX” to indicate “Exception”. Example:  X.Y.EX.1.

2.10. Includes

List any other use cases that are included (“called”) by this use case. Common functionality that appears in multiple use cases can be split out into a separate use case that is included by the ones that need that common functionality.

2.11. Special Requirements

Identify any additional requirements, such as nonfunctional requirements, for the use case that may need to be addressed during design or implementation. These may include performance requirements or other quality attributes.

2.12. Assumptions

List any assumptions that were made in the analysis that led to accepting this use case into the product description and writing the use case description.

2.13. Notes and Issues

List any additional comments about this use case or any remaining open issues or TBDs (To Be Determineds) that must be resolved. Identify who will resolve each issue, the due date, and what the resolution ultimately is.

 

Use Case document Template

Use Case Template:

Use Case ID:  
Use Case Name:  
Created By:   Last Updated By:  
Date Created:   Date Last Updated:  

 

Actor:  
Description:  
Preconditions:  
Postconditions:  
Priority:  
Frequency of Use:  
Normal Course of Events:  
Alternative Courses:  
Exceptions:  
Includes:  
Special Requirements:  
Assumptions:  
Notes and Issues: