- Capabilities — Each feature needs to be broken-down into one or more system capabilities (i.e., read, store, receive, calculate, transmit) and are of interest to solution developers since they reflect the inner system workings or regulatory, business, and user needs. Simplify the capabilities by eliminating all conjunctions (and/or). These capabilities are called functional requirements and can be written as user stories, declarative statements, or use cases. Each capability needs to be stated positively (avoid the negative) and in the active voice using verbs such as:
- must/shall (mandatory)
- should/may (optional)
- will (provided by an existing or future system)
- Conditions — Each feature can consist of one or more system conditions and are of interest to the infrastructure developers since they reflect the characteristics of the overall system support. These conditions are called nonfunctional requirements and are documented as declarative statements. Note nonfunctional requirements are equally vital to document as are functional requirements. Nonfunctional examples are:
- Performance – what data needs to be on-line and at what access response time
- Capacity – how many users / transactions need to be accommodated
- Scalability – what is the growth forecast of the system (i.e., data, users, transactions)
- Availability – when does the system need to be accessible
- Security – who needs access (create, read, update, delete) to the data
- Usability – what characteristics are needed to ensure a quality user experience
- Data retention – what data needs to be retained and for what period
- Backup and recovery – what data needs to be copied and at what frequency
- Disaster Recovery – if services are interrupted for a prolonged period, what contingency plans are needed for the system
- Training – what training is needed for users
- Documentation – what documentation is needed for maintaining the system
- Business Rules - Do solution requirements refer to one or more business rules as needed? Is each rule independently defined and numbered? Rational: Business rules are obligations that constrain solution requirements and are of interest to the solution testers since they reflect the input criteria for testing. To allow business rules to change independent of solution requirements, they need to be uniquely identified for reference purposes. Rule examples are:
- Definition – The meaning of a unique term, word or phrase (i.e., glossary or data dictionary)
- Relationship – The link between two or more terms (i.e., entity relationship diagram)
- Calculation – Formula used to derive information
- State – Data qualification that is caused by an event (i.e., state diagram)
- Range – Valid values for a defined term
- Authorization – Permissions needed to access or perform action on data
- Condition – Circumstance under which a business rule may apply (i.e., decision table, decision model)
- Trigger – Causes an activity or a message if a certain condition becomes true
This checklist provides questions to verify that the “function” of the documented requirements follow best practices. Once “function” has been assured, “form” can be addressed as a second step of the verification. Note that requirements verification needs be followed by a stakeholder validation and a system analysis feasibility review.
- Verifying answers the question, “is the product or service being built correctly—per best practices.”
- Validation involves stakeholders confirming “that the correct product or service is being built—per business needs.”
- Feasibility is evaluating “that technology exists to implement the requirements—within project constraints.”
The above three steps needs to be accomplished prior to obtaining the project sponsor’s approval to proceed with development. A similar verification with technical specifications and validation with requirements is done later on during solution testing. As stated at the beginning of this article, this assumes that a BRD is developed using the waterfall approach. Note the agile software development approach does not produce a BRD. Verification and validation under the agile approach is conducted during testing at the end of each iteration (2).
At this point, I thought I would try to read some reader’s minds. “Gee, the above checklist implies a lot of effort.” Yes, it does. Perhaps that is why it is called “work.” Keep in mind that 40-60 percent of the errors in testing can be traced back to a poorly documented BRD (3). We use best practices to reduce the risk of that happening. Therefore, the amount of documentation effort needs to be based on risk. To almost quote Shakespeare’s “Hamlet” – to document or not to document, that is a risk question.
Don't forget to leave your comments below.
- Spariosu, Nada and Rueffer, Patti (2011), “Dazzle ‘em With Your Documentation Style!” www.batimes.com
- Monteleone, Mark (2011), “A Proposal for an Agile Development Testing V-Model,” www.modernanalyst.com
- The Standish Group, The Chaos Chronicles, www.standishgroup.com
Mark Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is the President of Monteleone Consulting, LLC.