Download pdf - BUSINESS REQUIREMENT SPECIFICATION Requirements... · BUSINESS REQUIREMENT SPECIFICATION REVISION LIST Ver. No. Date Author Description 1.0

Advanced Data Management

BUSINESS REQUIREMENT SPECIFICATION

Version. No.: 1.0

Authorized By: <Name> Date: <Mmm dd, yy>

Business Requirements Specification

Page i Advanced Data Management / ADM Proprietary and Confidential

BUSINESS REQUIREMENT SPECIFICATION REVISION LIST

Ver. No. Date Author Description

1.0 <Baselined Date>

<Name of the person>

<Baseline>

<Ver No.> <Changes approved Date>

<Name of the person>

<Changes made to the document from previous version>


Page ii Advanced Data Management / ADM Proprietary and Confidential

TABLE OF CONTENTS

1. INTRODUCTION ................................................................................................................ 1

2. GLOSSARY OF TERMS .................................................................................................... 1

3. BUSINESS ENVIRONMENT.............................................................................................. 2

3.1 Business Profile........................................................................................................................... 2

3.2 Business Functions ...................................................................................................................... 2

3.3 Current System Description ........................................................................................................ 2

3.4 Business Strategies and Plans ..................................................................................................... 2

4. GENERAL BUSINESS REQUIREMENTS ......................................................................... 2

4.1 Constraints .................................................................................................................................. 2

4.2 Assumptions ................................................................................................................................ 3

4.3 References ................................................................................................................................... 3

4.4 Need for the Application ............................................................................................................. 3

4.5 Application Objectives................................................................................................................ 3

4.6 Users and Other Stakeholders ..................................................................................................... 3

4.7 User Characteristics .................................................................................................................... 4

4.8 Work Context and Application Boundary .................................................................................. 4

4.9 Work Partitioning ........................................................................................................................ 4

5. FUNCTIONAL REQUIREMENTS ...................................................................................... 4

5.1 << Enter a concise title, to be used as a common reference to the requirement - Enter a unique Requirement ID>> .................................................................................................................... 4

5.2 << Enter a concise title, to be used as a common reference to the requirement Enter a unique Requirement ID 2>> ............................................................................................................................. 6

6. DATA REQUIREMENTS .................................................................................................... 6

6.1 Business Objects Model .............................................................................................................. 6


Page iii Advanced Data Management / ADM Proprietary and Confidential

6.2 Data Model.................................................................................................................................. 6

7. NON-FUNCTIONAL REQUIREMENTS ............................................................................. 7

7.1 Look and Feel Requirements ...................................................................................................... 7

7.2 Usability Requirements ............................................................................................................... 7

7.3 Performance and Capacity Requirements ................................................................................... 7

7.4 Operational Environment Requirements .................................................................................... 7

7.5 External Interface Requirements ................................................................................................ 8

7.6 Maintainability and Portability Requirements ............................................................................ 8

7.7 Security Requirements ................................................................................................................ 8

7.8 Legal Requirements .................................................................................................................... 8

7.9 Implementation Requirements .................................................................................................... 8

7.10 Special Requirements ............................................................................................................. 9

7.11 Development Requirements .................................................................................................... 9

8 PROJECT ISSUES ............................................................................................................ 9

9 PROJECT DESCRIPTION IMPACT .................................................................................. 9

10 APPENDICES .............................................................................................................. 10

10.1 Prioritized Business Requirements List ................................................................................ 10

10.2 Current System Context Diagram ......................................................................................... 10

10.3 Proposed System Context Diagram ...................................................................................... 10

10.4 Proposed System Data Model ............................................................................................... 10

10.5 Business Workflows.............................................................................................................. 10

10.6 Analysis and Design Phase Tools ......................................................................................... 10

10.7 Project Plan ........................................................................................................................... 10


Ver.No. 1.0 Advance Data Management / ADM Proprietary and Confidential Page 1

1. INTRODUCTION

Requirements specification is the basis for and drives all the technical activities of the project to build the application conforming to the requirements of the customer. It shall be used and referred to throughout the implementation of the application and shall be updated to reflect the actual requirements of the customer.

<< INSTRUCTIONS

Instructions appear in Italics in this template to help in preparation of the requirement specification and should not appear in the final document.

All sections in this template are mandatory and shall appear in the requirement specification. Wherever some section is not applicable, it may be indicated as “NOT APPLICABLE”. Do not delete any sections, however additional sections can be added as per the needs of the project. >>

This document or an abstract of it is used by or referred to by the Offshore project team (PM, PL, TM’s), SQA, Internal Quality System Auditors and Onsite project team / Customer.

<< Add any other intended users of this document>>

2. GLOSSARY OF TERMS

<< Describe the meaning of the acronyms and systems terminology used in the requirements specification. >>

Acronym/Definition Description



3. BUSINESS ENVIRONMENT

3.1 Business Profile

<<Provide a high level summary description of the business sufficient to provide a contextual background for understanding the business requirements. Some questions to be addressed may include: What is the business? What products/services are delivered? Who are the customers? Where are the customers located? What is the nature of the business environment (Is it highly competitive? Are there a large number of providers and small number of customers, or vice-versa?) What are the marketplace factors influencing a Customers' purchase decision and/or business‟s ability to deliver product/services? What are the major trends affecting the business - economic, quality of customer service, speed of delivery?>>

3.2 Business Functions

<<List of Business Functions>>

3.3 Current System Description

<<Provide a high level, summary description of the current system supporting the business requirements and functions; includes identification of automated and manual systems, list of functions supported by the automated systems, locations/sites, hardware and software. Include any limitations and weaknesses noted by the end- user. Include a context diagram of the current system in the appendices.>>

3.4 Business Strategies and Plans

<<Based on review of the business plans, summarize the major business strategies, directions and goals. Include both short and long range plans. Consider impact on User Community Definition; i.e. expansion/contraction in the number of personnel, expansion of the number of sites. Include specific business targets if they have been identified; e.g. Achieve a 20% increase in Customer base over the next two years, or Reduce operating costs by X% within the next Y time frame.>>

4. GENERAL BUSINESS REQUIREMENTS

4.1 Constraints

4.1.1 Requirements Constraints



<< Describe the constraints that have an effect on the requirements and the design of the application. Solution constraints specify the way that the problem must be solved and the application developed.

Development constraints specify the methodology, tools, standards, and reusable code components that need to be adopted.

Implementation environment constraints describe the constraints pertaining to the technological and physical environment in which the application would be deployed.

Collaboration constraints describe the adjacent systems and partner applications with which the application should interface and work collaboratively. Also the use of commercial (of- the- shelf) software may impose design constraints.

Workplace environment constraints describe any characteristics of the physical workplace that could have an effect on the design of the application. >>

4.1.2 Project Constraints

<< Describe constraints that have an impact on the application development project. Budget and resources constraints describe the amount of money and resources allocated for the application. Schedule constraints describe any known deadlines for delivery and time line. >>

4.2 Assumptions

<< Briefly describe any assumptions being made with respect to the requirements and development of the software application. >>

4.3 References

<< Provide any cross references to other documents, contracts, systems or interfaces as needed.>>

4.4 Need for the Application

<< Briefly describe the need for the proposed development work. It should also describe the work that the customer wants to get done with the developed application. >>

4.5 Application Objectives

<< The reason for the development of the software application. The objectives being described shall be clearly stated, easily understandable, measurable and verifiable. >>

4.6 Users and Other Stakeholders

<< Users are end-users of the application. Identify and provide a typical list of users.



Other stakeholders are people and organizations who are affected by the application or whose inputs are needed in order to build the application. Identify and provide a typical list of stakeholders. >>

4.7 User Characteristics

<< Describe the characteristics of the target users. Some of the user characteristics are:

Category of user (Clerk, Manager, Engineer, Workmen, Student, etc) Priority assigned to user category (Key user, secondary user, unimportant user, etc.) User work tasks (responsibilities of the user) User's subject knowledge and experience level - novice, professional, expert User's experience level with relevant technology - novice, professional, expert Other user characteristics (physical abilities / disabilities, intellectual abilities / disabilities,

attitude to job, education, linguistic skills, age group, etc.)

The user characteristic's information would be useful for defining usability requirements and ensuring that the application fits in the users‟ way of working and meets his requirements. >>

4.8 Work Context and Application Boundary

<< Describe the work that needs to be investigated in order to build the application. Describe the work context by means of a context diagram that shows the application as a single activity. It would also show the external entities and their interfaces and interaction with the application, any collaborating application systems and their interfaces with the application. >>

4.9 Work Partitioning

<< Describe briefly the sub-systems, activities, operations and business events that the application system consists off. Describe the critical inputs and outputs that are relevant to each business event. Work partitioning in this manner helps in identifying logical chunks of work for discovering detailed requirements. >>

5. FUNCTIONAL REQUIREMENTS

<< Record explicit as well as implied functional requirements of the application. Each functional requirement and data requirement should have a unique identification number to provide for traceability. Also specify the acceptance criterion for each requirement that makes it possible to verify and validate whether the requirement has been met. Make appropriate entries for each functional requirement in Traceability Matrix. >>

5.1 << Enter a concise title, to be used as a common reference to the requirement - Enter a

unique Requirement ID>>



5.1.1 Requirement Description

<<Describe the requirement. Answers the question: What does the Customer want? This should be expressed in the Customer's terms.>>

5.1.2 Requirement Purpose

<<Explain the objective/purpose of the requirement from the Customer's perspective. This should answer the question: Why does the Customer want the requirement? The reasons should be in the Customer's terms and, where there is more than one reason, in the sequence presented by the Customer. Reasons may be based on customer service, image, marketplace positioning, economics, performance, etc.>>

5.1.3 Functional Specification

<<Explain how the requirement will be implemented at a functional level. This is the summary explanation of how the function will work and is supported in detail by the „Use Case‟.>>

5.1.4 Requirement Priority

<<Identify the importance of the requirement to the Customer using the following scale to categorize the requirement :>>

Essential The product must satisfy the requirement to be accepted by the Customer

Important Key factor in Customer's decision to buy product

Useful Value-added feature influencing the Customer's decision

Nice-to-have Cosmetic feature, makes product more appealing

Do not want it Feature or function that the Customer does NOT want

Other/Do not care

Feature or function that the Customer would like to have, but which could be eliminated or postponed if needed to reduce development costs or satisfy a delivery date.

5.1.5 Use Case

<< A functional requirement is the description of an action that the application must take in order to provide a needed service to the user.

Prepare a use case description for each functional requirement. Also indicate to which iteration (software release) of the application a specific requirement has been allocated for development.

The use case description should specify the following:



1. Goal of the requirement 2. Author of the use case 3. Assumptions 4. Open issues (if any) 5. Pre-conditions for execution 6. Post-conditions of execution 7. Normal flow (Input, Output, System action) 8. Alternative or exception flows (Input, Output, System action) 9. Constraints of the functional requirement (if any) 10. Acceptance criterion

Use case descriptions may be included as an Appendix to this document.

For each functional requirement (Use case) prepare a use case model. >>

5.1.6 References

<<Provide any cross references to other documents, contracts, systems or interfaces as needed.>>

5.2 << Enter a concise title, to be used as a common reference to the requirement Enter a unique

Requirement ID 2>>

<<Repeat items 5.1.1 to 5.1.6 under 5.1>>

Note: Based on the number of requirements, for every Requirement ID, items 5.1.1 to 5.1.6 are repeated.

6. DATA REQUIREMENTS

6.1 Business Objects Model

<< The application entities as business objects should be modeled in the form of a high-level object model to provide insight in to the associations between various objects, their dependencies, roles and responsibilities.>>

6.2 Data Model

<<Data requirements describe the essential entities of the application, their associations and constraints. Application entities should be modeled by means of a data model showing the entities and their relationships and constraints, to provide a basis for the data requirements.>>



7. NON-FUNCTIONAL REQUIREMENTS

7.1 Look and Feel Requirements

<< The look and feel requirements specify the customer's vision of the applications appearance. It is not the detailed design of an interface. Look and feel requirements specify the GUI standards, and other qualitative features pertaining to the appearance and creative aspects of the application such as clarity of communication, consistency, etc. >>

7.2 Usability Requirements

<< Usability requirements describe the ease of use and ease of learning of the application for the intended users. Ease of use specifies how easy it should be for the users of the application to work with it.

Ease of learning specifies how easy it should be to learn to use the application and how much time would be required to learn its usage. Context sensitive help and guidance requirements also should be specified. Specific standards for error messages should be specified.

The applications usability requirements should be derived from the abilities of the expected users and complexity of the functionality. >>

7.3 Performance and Capacity Requirements

<< Performance requirements specify the speed requirements, precision requirements, reliability and availability requirements, capacity requirements and safety requirements of the application.

Speed requirements specify the response time and the time available for completing a specific task. Also specify the known/likely concurrent processing requirements.

Reliability requirement specifies the allowable failure rate or allowable time between failures.

Availability requirements specify the duration and time period during which the application should be available.

Capacity requirements specify the throughput of processing, communication requirements and loads, and the volume of data to be stored by the application such as peak loads and seasonal requirements. >>

7.4 Operational Environment Requirements

<< Operational requirements specify the expected technological environment, and external interface requirements (with partner applications).

Technological environment specifies the hardware, other devices, network and communication equipment, system software, and third party software that constitute the environment in which the



application is deployed and operates. Also specify the location and distribution of hardware, devices and equipment. Specify the development environment if it is different from deployment environment.>>

7.5 External Interface Requirements

<<External interface requirements specify the partner applications and the interface required to be built for integration of the applications. >>

7.6 Maintainability and Portability Requirements

<< Maintainability requirements specify the expected areas of the application that are likely to undergo change in near future and the flexibility to be provided in the application for maintenance.

Portability requirements specify the platforms or environments into which the application must be installed. Portability requirements should be stated in conjunction with technological environment requirements (operating environment requirements). >>

7.7 Security Requirements

<< Security requirements specify the privacy and confidentiality requirements, data integrity requirements and audit requirements.

Privacy and confidentiality requirements specify authorization and access control to the application functionality, and the privacy and confidentiality of the data that needs to be maintained.

Data integrity requirements specify the integrity requirements of the data that is communicated, copied, stored and shared by the application and partner applications. Requirements with regard to retention of data, backup and restore of data, replication and removal of data are to be specified. Disaster recovery requirements should be specified.

Audit requirements specify the required audit checks to detect improper usage, and integrity of the application and the audit trails that need to be maintained in the application.>>

7.8 Legal Requirements

<< Legal requirements specify the statutory and regulatory laws, rules and public standards that need to be complied with by the application. >>

7.9 Implementation Requirements

<< Implementation requirements include documentation, training, and transition requirements.

Documentation requirements specify the system and user documentation that needs to be provided for the application.



Training requirement specify the nature and type of training that needs to be provided to users and other stakeholders intending to use the application.

Transition requirements specify the deployment needs method of implementation, changes to be made to the existing data, master file creation, and procedures prior to the usage of the application.

Specify the support requirements during installation / deployment period and warranty period.>>

7.10 Special Requirements

<< Special requirements specify the sociological, political and cultural aspects that affect the application and its usage. Specify any multi-lingual, multi-currency, and internationalization requirements.

Safety requirements specify the perceived risk of possible damage to people, property, and environment during the usage of the application. >>

7.11 Development Requirements

<< Specify the expectations of the development project, such as, acquisition of new technology skills, piloting a new methodology, tool or technique, etc.>>

8 PROJECT ISSUES

<<Identify open issues which would affect analysis and design, and must be addressed. For each issue, the information presented includes a short description of the issue, the owner of the issue, and the potential impact to the Project if the issue, and the date by which the issue must be resolved to avoid the impact. Issues identified here would be logged in the Issue tracking system. Issues may be presented in table form as illustrated below.>>

Issue Impact Target Date for

Resolution

Owner

9 PROJECT DESCRIPTION IMPACT

<<If the findings of the Requirements Phase impact/change the proposed system objectives, scope, deliverables, flexibility matrix or risks, this section would provide a description of the impact and



changes. Updated Project Objectives Statement, Flexibility Matrix, Major Project Deliverables Description and/or Risk Management Plan Matrix must be included either as part of this section or as appendices to ensure the impact is fully understood and documented, and to ensure they are available for the management review.>>

10 APPENDICES

10.1 Prioritized Business Requirements List

<<Prioritized list of business requirements as identified under Functional Requirements (and Non-Functional Requirements where application architecture and design must directly support the requirement - e.g. document retention policies directly affect how documents are shown to be deleted) . The list should contain at a minimum, the Requirement Title and Unique ID. This list should form the basis of the work and iteration planning process, and requirements through acceptance traceability matrix. >>

10.2 Current System Context Diagram

10.3 Proposed System Context Diagram

10.4 Proposed System Data Model

<<The high level data model developed for the proposed system; ERD with associated Entity Type, Relationship Type and Attribute Type descriptions.>>

10.5 Business Workflows

<<Include the business work flow diagrams developed as result of the work flow definition and analysis.>>

10.6 Analysis and Design Phase Tools

<<Summary of Analysis tools selected and Design tools recommended; includes tool name, purpose, vendor, cost.>>

10.7 Project Plan

<<The Project Plan, updated for the Analysis Phase.>>