Checklist Description: This checklist captures common elements that should be present in any business requirements definition document. It is presented during the Analysis review process to stimulate thought, guide brainstorming, and to ensure the business-defined features and functionality being outlined contains all proper requirements considerations. To ensure that the system you are preparing to build fully addresses the necessary user and technical needs, features and functionality, and assess the requirements considerations that apply to your subject matter expertise and business needs.
Project Name: / Review Date:
Assessment and Recommendations:
Approved without revision
Approved with revisions (see Notes)
Not Approved / Notes:
Reviewer: / Signature:
Artifacts Reviewed:
Prioritized Requirements Matrix
Business Requirements Document / Requirements Traceability Matrix
Is each requirement numbered or uniquely identifiable from other requirements (document uses numbered outline codes, etc.)?
Is each requirement written in clear, concise, unambiguous language?
Is something described as a “standard” without citing the specific source?
Is any necessary information missing from a requirement? If so, is it identified as TBD and how it will be accounted for during design?
Are there any of the following “weasel words” e.g. various, mostly, suitable, integrate, maybe, consistent, robust, modular, user-friendly, superb, good?
Are there different possible interpretations of the requirements?
Are use cases or other process flow mapping used to increase readability?
Are there screen print mockups to aid in defining the requirements?
Are the terms that can have more than one meaning qualified so that the desired meaning is readily apparent?
Are the performance criteria quantified such that they are testable?
Is each requirement free from content and grammatical errors?
Is the implementation priority of each requirement included?
Are all requirements actually requirements, not design or implementation solutions?
Are the requirements an adequate baseline for design?
Requirements Completeness / Comments
Have the following areas been addressed:
Administrative Requirements
Legal and Regulatory Requirements
Information Security and Access Requirements
Application and User Interface Requirements
Data Requirements with Field Definitions
Data Storage and Retention Requirements
Error Management
Quality Assurance Requirements
Migration/Conversion Requirements
Reporting and Management Information Requirements
Business Continuity and Recover Requirements
User Help and Application Documentation Requirements
Client Acceptance Requirements
Requirements Content / Comments
Are performance objectives properly specified from the user's point of view (expected response time, processing time, data transfer, and system throughput, etc.)?
Does the Business Requirements Document include all of the known customer or system needs?
Are the requirements clearly stated as to what is needed at the requirements level rather than suggest how it might be implemented?
Have reliability, serviceability, maintainability and performance objectives been identified?
Is each major requirement in scope for the project as defined in the Charter and Business Case?
Can all of the requirements be implemented within known constraints?
Are al the external and internal interfaces properly identified and documented?
Were appropriate steps taken to validate the requirements and operational concept?
Are all inter-dependencies identified?
Have business rules (calculations, timesheets, etc.) intrinsic to the functional requirements been defined?
Is the expected behavior documented for all anticipated error conditions?
Are all time-critical functions identified, and timing criteria specified for them?
Are the customer profiles and expected user groups clearly defined?
Are all the tasks the user wants to perform specified?
Does each task specify the data used in the task and data resulting from the task?
Is the level of security specified?
Is the reliability specified, including the consequences of software failure? Is vital information protected via error detection and recovery?
Are acceptable tradeoffs between competing attributes specified, such as between robustness and correctness?
Do the requirements reflect the business value expectations of the project (new revenue, reduced costs, efficient use of resources, new business processes, etc.).
Requirements Quality / Comments
Are the requirements written in user language? Do the users think so?
Do all requirements avoid any conflicts with other requirements?
Are the requirements expressed independently of design specifications?
Are all requirements specified at a consistent level of detail?
Are the requirements clear enough to be turned over to an independent group for implementation and still be understood?
Is each requirement relevant to the problem and its solution? Can each be traced to its origin in the problem environment?
Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?
Are all requirements feasible to implement given the defined project timeframe, scope, structure and budget?
Are probable changes to the requirements, including the likelihood of each change, specified?
Do users understand how change control will be used to modify the requirements going forward?
Do users understand that these requirements will define the solution being delivered – nothing more and nothing less?
© 2012 Regents of the University of Minnesota. All rights reserved. Revised November 3, 2018Page 1