There must always be an explicit link between business processes and requirements.
It should start at a high level for the coverage perspective, but the requirements must be collected in detail. Asking the five Ws is always a good idea to ensure that enough details are collected.
When solution envisioning is performed, another crucial question, How, is answered.
All the business processes that will be part of the initiative and each of their subprocesses must be considered in order to prepare the requirements list. There should never be a requirement without it being linked to one or many processes; alternatively, there should not be any process/subprocess that does not have any requirements. Any such situation wherein a requirement does not belong to any business process should be validated with the out-of-scope criterion and addressed by the change control board.
We recommend that you follow a hierarchical approach while gathering and documenting requirements. The following diagram represents one such approach and depicts the goal leading to the business process, which, in turn, leads to a subprocess and, ultimately, the requirement:
The hierarchical way of recording requirements is a proven approach to orienting and structuring the requirement-gathering process and ensuring that each requirement has downstream usage. Systematic success warrants the manageability of the project scope and, hence, a hierarchy. The project benefits when the stakeholders can clearly understand the big picture as well as the activity-level details. Empowering team members with scope clarity is a solid foundation for collaboration and achieving goals.
Now that we've laid the foundation using a hierarchical approach, we'll explain the elements that are involved in achieving it.