Checklist of functional and non-functional requirements to be considered when writing business requirements.

1. Business Requirements Checklist
Note: This document aligns with the BusinessRequirements.doc template.
Item Topic Considerations Have you
addressed?
1 Revision History When a change other than a correction to spelling or format occurs, the change is to be logged on the history change log below.
2 How to use this document The intent of this requirements document is to identify the system and non-system areas that may be impacted by the introduction of a change to
current processing. It is not mandatory that each area will have content, but it is mandatory that each area is considered.
After consideration, if no changes are required or no impact to the area is needed, do not delete the section as it will serve as an audit trail.
Instead, indicate in the section below the header that no changes are required. You may choose to delete the table but it is recommended you do
not delete the section.
3 Purpose of functionality Describe in a short summary of the requirement. This must answer:
What is the purpose of the change?
Short description of the change
Anticipated advantages of the change
4 Assumptions Add to the list below anything you believe to be true that will impact the delivery of this requirement.
5 Contributors List all individuals who were requested to contribute to the creation and review of this requirements document as well as what business owners
participated in review process.
6 Definitions Review the data dictionary to determine if the term and definition listed; if not, work with Governance team to determine a generally accepted
definition.
7 Requirements List a summarized description of each feature and functional requirement in the table below. Following the table, add individual sections to
document the details of the summarized requirement. In the detail section, include process flows or any other information you feel needed to
adequately describe how the business user anticipates the feature/function to work
8 Regulatory Considerations List any considerations that must be addressed in development of this requirement based on the laws and regulations of the State(s) in which this
requirement will be implemented.
9 Compliance Add any compliance standards that impact the development of this requirement. Compliance items are not governed by a law, but are either
Considerations industry standards or organization policy compliance or operational standards.
10 Messaging Identify any message content and rules that result from this requirement.
11 Standards Describe any standards that must be met with the delivery of this feature or function. Standards may include things such as processing speed,
web layout rules governing font/size/color, etc.
12 Constraints List any constraints that impact the delivery of this project. Constraints often include:
Resources. Identify the equipment, software, staff, and space that are available for the project.
Time. Identify the date by which the application deployment project must be completed, and how the application testing process fits into the
larger deployment project.
Organizational issues. If the project will not involve the entire organization, identify which groups in your organization will be affected by it.
Additionally, determine if a particular group in the organization needs the new operating system sooner than others. If so, you might decide to
perform a staged rollout.
Access to developers. Identify applications that were developed in-house or especially for your organization. Access to the developers of these
applications is critical during the testing and issue resolution phases of the project. Such access also can be an invaluable aid with retail
applications.
13 Reports Include a high level description of the report to be created to support the use of this feature or functionality.
BizReqChecklist1.xls 1 of 2

2. Business Requirements Checklist
Item Topic Considerations Have you
addressed?
14 Testability Most requirements should be testable. If this is not the case, another verification method should be used instead (e.g. analysis, inspection or
review of design). Testable requirements are an important component of validation.
15 Workforce Readiness The introduction of the feature / functionality requires the workforce to be prepared to use it or understand it or, possibility, only know of its
existence. The preparation of the audience is generally determined by the role of the individual and how that role would use or be affected by the
new feature / functionality.
16 Workflows List any work flows that must be created or updated as a result of this requirement.
17 Policies List any new policies needed or existing policies that must be reviewed and possibly modified as a result of this requirement.
18 Procedures List any new procedures needed or any existing procedures that must be modified as a result of this requirement.
19 Forms Identify the forms that must be created or updated as a result of this requirement.
20 Capacity Capacity of the system refers to its ability to process certain volumes of transactions. The subject matter experts must estimate the volumes
anticipated in the processing. As it pertains to the Insert name of requirement feature / functionality, the list the capacity requirements for the first
24 months of operations.
21 Software Identify any required versions needed to support the development. Also consider any necessary amendments to existing software contracts that
may need to be made in order to support the new development or define who “owns” the new functionality.
22 Hardware Identify the new hardware needed to support this requirement or any changes to the existing hardware to support this requirement. Include
evaluation of storage media, telecom, workstations, etc.
23 Portability Portability is the ability of software created for a computing environment can be moved to another computing environments that is different from
the one for which it was originally designed (e.g. different CPU, operating system, or third party library). The term is also used in a general way to
refer to the changing of software/hardware to make them usable in different environments.
24 Scalability In software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing
amounts of work in a graceful manner, or to be readily enlarged.
25 System Availability Document when the system must be available. This may be different for different users.
26 Documentation Identify documentation must be created or updated in support of the construction, testing, deployment of the Insert name of requirement feature /
functionality.
27 Deployment Define how the new feature/functionality will be rolled out as operational.
28 Disaster Recovery Describe how the feature / functionality must include following disaster recovery activities: backup, restore, archive on/off site, etc.
29 Benefits Realization Describe and plan how the project sponsor intends to measure the actual benefits received by this change as compared to the business case's
anticipated results.
30 Vendor Considerations Identify the vendors involved in, or impacted by, the new functionality.
BizReqChecklist1.xls 2 of 2