Gathering Business Requirements - Watermark Learning



Business Requirements Template

Related Documents

The requirements package is the principal set of documents delivered at the end of the Business Requirements Definition phase. It is comprised of information provided by the business clients and which needs to be approved by them.

There are other project documents that are different from but closely related to the requirements package. One is the document created by and used by the project manager to ensure that the project is managed by planning, executing and controlling the project. This set of documents is the Project Plan and includes the project baselines of scope, schedule and budget, as well as several management plans.

Another related document is the Test Plan, which is really a series of documents, ensuring that the project is thoroughly tested before being implemented and that all the identified requirements work as designed.

A third is the Training Plan, which includes training plans and strategies, detailing

who will be trained and by whom, what materials will be used and when the training

will occur.

Business Requirements Package

Purpose

The Business Requirements Package is the end deliverable of the Business Requirements Definition phase. It serves as a communications vehicle for everyone affected by the project. It summarizes the analysis that has been completed to date, but is a living document that changes as new information is added and as approved changes in functionality and scope occur. Its audience is everyone who is affected by the development effort. Its purpose is to:

• Provide detailed view of the project.

• Build partnerships with other areas of the organization.

• Improve quality by catching and correcting errors, invalid assumptions, etc. early in project development.

• Provide impacts to other areas.

• Provide building blocks for completing specifications and the development of the product.

Audience

The requirements package will no doubt have a variety of different audiences, ranging from executives who want very little detail to technicians who want a great deal of it. As with similar documents, it is important to gear the information to the audience. Since communication objectives are different for the various readers, it is necessary to provide all things, but to do so in a way that those who want detail get it and those who don’t can get a summary. Using a series of attachments helps the audience focus on the sections most important to them.

Developing a requirements package

The format of the requirements package can vary, but the key is to make it interesting and easy-to-read, with white space and bullets, as opposed to dense text.

One or several project stakeholders should assist in developing the requirements package; it is essential to get client input. Ideally, getting the client to actually develop parts of the document is very helpful.

As the project progresses and more details become known, the requirements package gets updated with that information. It is not necessary to re-send the entire document with the added details to those who are not interested, but it is advisable to ensure that your technical partners receive it.

Reviewing and Approving

Every key stakeholder needs to review the requirements package, which should not contain any surprises to any of them. A large group meeting should be scheduled when there is general agreement in principle to the information in the document. However, a good tip in developing the requirements package is to first meet in small groups to get stakeholders’ input and buy-in. Have a non-stakeholder and non-project team member read the final proof to check grammar, spelling and overall readability.

The requirements package needs formal approval, which includes obtaining signatures from at least the executive project sponsor and other key stakeholders. This document becomes the baseline for the scope of the requirements, against which the product scope will be measured, making signoff on the document essential.

Project Introduction

The project documentation links the requirements document to the project documentation, specifically the Scope Statement. This section is, then, a summary of the project Scope Statement.

BUSINESS PROBLEM(s)

Detail why this project is necessary and the limitations of the current situation--what about the existing processes and systems causes the need for change. A clear statement of the problem, as well as the kinds of headaches caused by the problem, becomes the foundation of the business case for doing the project.

PURPOSE AND OBJECTIVES

Indicate the reason the project is needed, tying into the above current system limitations. Objectives describe business strategies and are best stated in business terms.

LINK TO BUSINESS OBJECTIVES (can refer to traceability matrix)

SCOPE AND DELIVERABLES

Describe the features, functions and deliverables both included in and excluded from this project

APPROACH

Describe the project strategies, such as:

• Project methodology to be used (Traditional. RAD, Packaged Software, etc.)

• Testing strategies

• Implementation strategies

• Knowledge transfer

• Conversion strategy - if applicable

• Rollout method

• Verification, backout, recovery

• Business recovery (disaster recovery)

• Project management strategies, as appropriate

Document support strategies, such as:

1. A strategy to address problems, errors or response issues as a result of the new application, including a process to determine if problems exist.

2. Listing of escalation procedures on who to call and when to call them when problems develop. This procedure should describe how the areas below will address issues:

1. Help Desk and/or client champions for calls

2. Network services for client/server applications

3. Operations and database for performance

4. Training for updates on issues

ASSUMPTIONS AND CONSTRAINTS

• Business, technical and project assumptions

• Business, technical and project constraints

ALTERNATIVES

Describe approaches and strategies that were not selected.

ROLES AND RESPONSIBILITIES

Detail who will be involved in the development process and their required deliverables. Include internal and external clients.

COSTS AND BENEFITS

Include benefits, which are directly linked to the limitations of the current system. As with objectives, these are best stated in business terms by business clients and should be quantifiable where possible. Include as many costs as possible that can be determined at this point in the project.

Body of the requirements package

Business Requirements Overview

Business Requirements are the features and functions of the system expanded to describe such things as:

• Purpose of each feature and function. Think in terms of describing each requirement related to data, process, user interface and interaction.

• Description of each feature and function

• How the clients will use each function

• Policies and strategies related to the function

• Explanation of terms, as needed

Requirements List

Business Rules

Business Rules are processing rules stated in the clients’ terms. Business Rules include but are not limited to:

• Edit rules that are supported across business processes and systems. For example, there might be intelligence in a key that needs to be edited throughout many programs and systems.

• Referential integrity conditions. Referential integrity is the ability to maintain the same information on multiple tables. It addresses the update of one of these data values that is stored in more than one place. The analyst can choose whether or not a change in one table will cascade to other stored occurrences of the same data or whether to restrict such changes. This is accomplished through the use of primary and foreign keys, the foreign key indicating a dependency on a parent table containing a unique row or primary key. The analyst must consider such things as:

o If a primary key is deleted, what happens to the related foreign keys?

o What restrictions must be placed on changing a foreign key?

o What validations must be performed when a new row is added that contains a foreign key?

• Data modeling rules of optionality and cardinality.

• Domain rules for what business information and ranges are embedded in attributes and fields.

• Data integrity conditions. Defining tight input edits which do not allow any erroneous data to enter a system is the best way to ensure data integrity. If modifying an existing program, it is necessary to decide whether or not to tackle new input edits.

• Rules which ensure cross-platform integrity. Business rules need to apply across platforms. For example, if a region must exist to have a store, then that rule needs to apply whether being processed on a mainframe or PC.

Supplemental (Non-Functional) Requirements

Include all appropriate, but not limited to:

Service Level Agreements

Service level agreements describe a commitment to have no impact on clients and other IT areas once a new system or change is installed into production. On-line systems should maintain or improve response time; reports should be delivered or available on-line no later than currently. Describe how service level agreements will be met for:

3. On-line

5. Response time requirements

6. System availability

4. Background

7. Screen/window availability (including notification to clients that background process is complete)

5. Batch

8. Processing windows/deadlines

9. Special requirements

6. Reports

10. Report availability (including on-line reports)

7. Other Systems

11. Impact on other system/application Service level agreements (batch and on-line)

12. Impact on critical path

8. System Availability

13. 7 days by 24 hours availability

Reconciliation strategy

Rules for balancing need to be detailed. Also needing consideration are business rules for reasonability checks. For example, if a bank expects to process $10 million in deposits each day and there are only $5 million, should there be a warning? Who should get notified? What action should they take?

Data retention criteria

How long data will be kept and on what media needs to be defined, with input from business clients, as well as from IT partners.

Purge criteria

Define when data will be deleted from all storage media and when.

Attachments

Traceability Matrix

Process Flows

Include as appropriate:

• Process Maps

• Data Flow Diagrams (optional)

• Hierarchy Charts

• Dependency Diagrams

Data Requirements

The following should be included in this section:

• A diagram of all entities (classes), attributes and their relationship to each other (ERD or class diagram).

• A description or definition of the above

Definitions

Defining business data (entities) ensures that everyone is using the terms correctly and consistently, regardless of whether they are from the business line, technical team, vendors, etc. As an example, it may seem painfully obvious what a bank customer is. However, is a customer someone who has had an account in the last six months, even if there are no active accounts?

Use Cases

Include as appropriate:

• Use Case diagrams

• Flows of events

User Interfaces

All organizational standards and guidelines for GUI and web pages should be followed when designing user interfaces. The following should be included in this section:

1. Copy of interface

2. Clients using the interface

3. Function of interface

4. Business processing performed

5. Edits performed (see below)

6. Inputs to the interface

7. Outputs

8. Called routines

9. Field definitions

10. Definition of push buttons and/or function keys used (see below)

11. Application program tables that could affect design decisions due to volume, content, access, etc.

12. Documentation on all mouse clicks, fast keys, function keys and mnemonics

13. Where the interfaces flow with each possible action. This documentation, although complex, is necessary.

Decisions on whether or not to use keyboard, mouse or both. These decisions rest on such issues as:

14. Performance (keyboard is faster for expert users)

15. Ease-of-use (mouse is generally easier to learn)

16. Whether or not the system is operational or decision support, repetitive or requiring more unique operations

17. Whether the clients tend to be expert users (little turnover) or new (higher turnover)

Edits And Their Corresponding Messages

Categorize into three types:

18. Informational: These edits provide feedback to the person entering the data.

Example: Order successfully updated

19. Warning: These edits usually appear when attempting to delete a business object, such as a customer or an order.

Example: Are you sure you want to delete this customer?

20. Restrictive: These edits prevent incorrect data from entering a system or enforces a business rule.

Example: Orders must contain at least one order item

Reports

For each standard on-line or hard-copy report, document the following:

9. Copy of report

10. Receiving Client

11. Purpose of report

12. Processing performed

13. Edits/calculations performed

14. On-line reporting, paper or both

15. Frequency of report

16. Report Service Level Agreement

17. Print or on-line location/paper size/special forms

18. Inputs

19. Outputs

20. Application program tables that could affect design decisions due to volume, content, access, etc.

21. Called routines

22. Field definitions (optional)

23. Client reprint features/procedures

For Decision Support systems and reports include:

24. Data warehouse implications

25. Whether this report is part of a larger decision support system

26. Where new information resides in the operational system

27. Extract information required

28. Drill-down paths

29. Summarized information required

30. Standard reports

31. Ad hoc capabilities

Glossary

The following should be included in this section:

32. Definition of Terms - Clients/IT/Vendor acronyms

33. Calculations

34. Terms that are unique to this project

System Support Information

Hardware/Software Requirements

The following should be included in this section:

35. A Hardware Impact Statement, which includes new hardware requirements. This statement should be tied to an approved funding request.

36. Any packaged software requirements and needed changes.

37. Capacity Planning

14. Projected peak volumes of transactions

15. Projected database requirements

16. Projected system growth rate

Impact Statements/Considerations

Include impact statements for all areas affected by this new or changed system. Be sure to include any expected deliverables.

38. Clients - Identify any changes that must be made such as new equipment needed, changes in procedures, staffing adjustments, etc.

39. Telecommunications - Identify the following:

17. Location and types of terminals

18. New or modified desktop configurations

19. Transmission rates

20. Estimated line loadings

21. Recovery and fallback requirements

40. Data Base Administration - Identify requirements to set up or modify tables/databases.

41. End User Computing - Identify action required for hardware/software changes in the client environments

42. Help Desk - Identify the types of calls and training needed by the help desk to support this system

43. Production Control - Identify the number of jobs that will be impacted and any scheduling revisions needed

44. Technical Services - Identify any system software changes needed to support the new application

45. Application Support - Identify any requirements or impacts that this system will have on application support:

22. System supportability from remote location

23. Identify any vendor software and related support issues

Data Security Plan

The following should be included in this section:

46. Organization's policy on confidentiality

47. System security design should adhere to the organization's security guidelines

48. How security will be implemented on the system. This will include things such as the number of clients and the levels of security needed on the system (i.e. application, screen/window or field)

49. Any unique security requirements of the system

Disaster Recovery Plan

The following should be included in this section:

50. Organization's business and system strategies used for recovering of application in the event of a disaster

51. Corporate data that is being used by the application, but is the responsibility of another area to back up and recover

Also include system recovery considerations, such as:

52. Time or date dependencies

53. Can processing be delayed? How long? Client impact? System impact?

54. Can the processing cycle be bypassed? Client impact? System impact?

55. Critical system interdependencies

Related Documentation

The following may be included in the requirements package or may be documented in related project documentation:

Test Strategy and Plans

It is a good idea to define test objectives and a testing approach for all testing phases as early in the process as possible. By the end of design, these should be complete:

• Test objectives for unit, system and acceptance tests

• Testing steps that can be completed to reduce project risk

• Test cases and scenarios with expected results for functional tests

• Problem reporting (Anomaly Log)

• Testing roles and responsibilities

Test plans, including tasks, dates, roles and responsibilities should be completed. In addition, as tests are completed, actual results should be documented and compared to expected results.

Acceptance tests should encompass client acceptance and IT acceptance. An example of IT acceptance is having performance analysis completed.

Acceptance Criteria

Client Acceptance Criteria. All requirements which must be met for the clients to accept this system into production.

IT Acceptance Criteria. All requirements for the vendor which must be met for IT to accept this system into production (e.g., system test results, parallel test results, scheduling, data integrity requirements).

System Constraints

The following should be included in this section:

• A narrative outlining your high level strategy for addressing system constraints, such as removing intelligence from primary keys or for removing date limitations

• A list of programs, jobs, and files/databases which will be modified to eliminate system constraints

• A list of bridge programs and utilities which will be implemented to accommodate interfaces between converted and non-converted systems. Describe when, how, and why to remove bridges

• A description of any rework which will be needed when the interfacing systems are upgraded. Describe the nature of the rework

Client Training Plan and Documentation

The following should be included in this section:

Training

• The number of clients using the application initially and long-term

• The strategy that will be followed to train the new clients

• Who will train clients on new business processes

• Who will train the Support team

Documentation

• Who will document the system

• Who will document updates

• Who will document new business processes

• What format will be used (ex. on-line Help)

Project Plan

After the requirements package has been developed and approved, it may be necessary to review and update the project plan and the baselines therein, including the scope, the schedule and the budget. Other Management Plans (e.g. Risk and Quality) may need updating as well.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download