Business requirements are usually used by different parties throughout program’s or project’s lifecycles.
When to use business requirements?
Business requirements are usually used for the following purposes:
- Solution selection,
- Process analysis
- Process design,
- Process reengineering and
- Testing.
How should the process of creating business requirement look like?
A holistic process creating business requirements covers the following phases:
- Define and align business process scope
- Define quality gates and quality criteria
- Define and align create and change process for business requirements
- Select business requirements tool
- Create and manage business requirements
following quality criteria and create and change processes
Best-practice is jump-starting business requirements creation based upon an existing business requirements catalogue, discussing the relevant business requirements, selecting, or deleting them from the catalogue, and adding a couple of industry- or company-specific business requirements.
This clearly leads to
- Increased quality,
- Faster process, and
- Less cost.
How to create business requirements?
A comprehensive business requirement is described in an understandable way. It explains in-depth what e.g., a solution is supposed to provide. It is described using the following information:
- Unique business requirements ID
- Global or local scope
- Functional or non-functional
- Dimension in case of non-functional (e.g., security, compliance, steering, warning, ease of use, user-experience, maintenance, adaption, extension, decision-support, growth)
- Business Scenario
- Business Process
- Required categories to analyze business requirements on a higher level than their description
- Comprehensive and understandable description
- Functionality in Use (yes or no)
- Priority (e.g., must have, should have, nice-to-have)
- Objective (e.g., increase revenue, reduce cost, increase efficiency)
How does an example look like how to do it and not to do it?
The following examples highlight how to and not to do it:
What happens if you do not create business requirements in a comprehensive and understandable way?
Sometimes people belonging to different parties only see the written business requirements at a certain point-in-time, but do not necessarily have the possibility to discuss them with the originating party. This might lead to misunderstandings as different people have different reference points. Even though when discussing business requirements for the first time, there might be different understandings, discussions about certain topics are always beneficial.
Occasionally business requirements are changed over time without using an audit-proof change process, even though the business requirements tool would support it.
Thus, it is essential creating business requirements in a comprehensive and understandable way from the very beginning and taking your time making sure that all parties have a mutual understanding about the contents.
At worst, the following problems might occur resulting from a lack in quality:
- Wrongly selected solution due to misleading results during fit-gap analysis
- Increased effort during testing
- Reduced business fit of the solution
- Reduced business acceptance
- Increased number of bugs in the productive system / “new” business requirements after go-live
Thus, it is clearly effective creating business requirements in a comprehensive and understandable way.
Ready to talk? Please contact us via your preferred channel.
#businessrequirement #businessrequirementcreating #businessrequirementdefinition #solutionselection #softwareselection