When you think “food chain,” you generally think Nature. But within the business analyst community, “food chain” also applies to requirements.
Take a look at the diagram above: that’s your food chain. If you figure out the impact of the requirements for each of the segments or “links,” you get a pretty good idea of how the system works overall.
In the first part, Feasibility and Business Planning, the exploration of business scenarios is all-encompassing: not only the business models and all associated scenarios, but also alternative models that use alternative scenarios for a product or service, as well as the processes and time horizon for that part. In addition, those same techniques and models need to relate to the market feasibility, technical feasibility, financial feasibility as well as the organizational and managerial feasibility analyses and needs for all those areas.
Next, we get into the Business Requirements Discovery part of the food chain, which includes not only the business needs and requirements themselves (the current and future states of a product or service) but also process analysis and identifying bottlenecks, inefficiencies, disconnects and other problem areas.
After discovery comes design; this part of the requirements food chain is about articulating the functional structure of a company in terms of its business services and related information. One of the outcomes is a set of business capability models, a detailed analysis of what the organization actually does.
Internal Design for Requirements deals with the change controls that an organization may have (or want to have), and implementing a system and requirements for those. For a new bank, just as an example, that could mean implementing SARBOX (Sabanes-Oxley Act), which mandates specific internal control for financial reporting. Once controls are implemented, they must be assessed regularly, whether every quarter or annually.
The final part of the requirements food chain is taking all the requirements and information analyzed and gathered in the first four areas and moving them to development, test and finally, deployment. It may very well be that requirements may need to be changed or modified while in development, in order to ensure a smooth testing and deployment process.
As this diagram illustrates, the business analyst is the person who recognizes each specialty and ensures that the intention of the requirement is accurately communicated along the food chain. Organizations are always growing (both in size and geographical complexity) and technology is becoming ever more complex; relying on the “food chain” can help cut through that complexity.