There must always be an explicit link between business processes and the 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, gets answered.
All the business processes that will be part of the initiative and each of their subprocesses must be considered for preparing the requirements list. There should never be a requirement without 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 accordingly addressed by the change control board.
We recommend that you follow a hierarchical approach while gathering and documenting requirements. The following visual represents one such approach and depicts the goal leading to the business process, that, in turn, leads to a subprocess and, ultimately, the requirement:
The hierarchical way of recording requirements is a proven approach to orient and structure requirement gathering process and ensure the each requirements downstream usage. Systematic success warrants 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 achievement of goals.
Laying the foundation using a hierarchical approach, we'll now explain the elements involved in achieving it.