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.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- requirements analysis rutgers university
- business requirements document nyu
- gathering business requirements watermark learning
- the critical steps to business analysis project
- business functional requirements template epri
- sample international institute of business analysis
- ufit business analysis plan university of florida
- business requirements spec business analyst guru
Related searches
- crm business requirements example
- crm requirements gathering template
- business requirements document template
- template for gathering business requirements
- business requirements document sample
- it requirements gathering template
- requirements gathering template excel
- examples of business requirements statements
- business requirements document template free
- business requirements document in agile
- business requirements document template excel
- business requirements checklist