The previous article in this series discussed ensuring that high-level requirements (HLRs), within the context of an IT-based project, were properly high level. The remainder of articles in the series will look at detail requirements and the need for them to be sufficiently detailed. The objective of this article is to demonstrate how a data dictionary (DD) can be used as a tool for capturing the appropriate level of detail representing data-specific business needs.

The purpose of the Trips-R-You Flight Booking Case Study is to provide an integrated, end-to-end set of requirement examples. In IIBA® BABOK® V3 terminology, end-to-end means from Business Requirements to Stakeholder Requirements to Solution and Transition Requirements. This case study, and associated artefacts, use the more traditional business terms Goals, High-level Requirements (HLRs), and Detail Requirements. Only functional requirements are addressed, and only within the context of a project chartered to deliver an IT-based solution.

Let us look at it from a different angle now and derive the requirements out of the customer journeys.  It is impossible to introduce a change... if the change is big and you try to implement it in one go.  This is the reason we tend to break any solution into smaller components. Each solution component should be small and independent enough to be changed individually in a controlled manner. So that eventually we will compose a new experience out of them. Pretty much like using a set of Lego blocks.

The question of how essential domain expertise is to a business analyst is a recurring debate in the BA community. One school of thought maintains that domain knowledge is not critical. A skilled BA, the thinking goes, can walk into nearly any project situation and do an effective job of exploring requirements, relying on previous experience and a rich tool kit of requirements techniques. The counterargument avers that an analyst who has deep subject matter knowledge can be far more effective than a more general practitioner.

I have experienced both situations, from inside a company as a regular employee and from the outside as a consultant. This article offers some thoughts about when domain knowledge is valuable, when it’s essential, when it’s not necessary, and when it can actually pose a risk.