Business Requirements in the Wild
Business requirements exist in the wilds of organizations around the world. At least, that is our theory. They roam through the hallways and offices, hiding in the minds of business managers and subject matter experts, waiting to spring on the unsuspecting developers or analysts when they can do the most harm. There were times when they were thought to be extinct, in particular just before the "Y2K" scare where they were reduced to the single concept, "Thou shall know thy century". There are also many people who are trying purposely to eradicate the entire concept of business requirements. Yet they survive, often waging war on their close relatives, system requirements (often called by their pseudonym, "Technical Specifications"). It appears to be very difficult for these two entities to coexist. Perhaps they need a mediator to initiate peace talks aimed at allowing both sides to exist in their own separate, albeit connected, little universes. We propose that the role most qualified for this task is the role we refer to as "Business Analyst".
Requirements Captured
Remember that this is just a theory. We do not really know whether business requirements exist at all until we capture them. Only then can we recognize them for what they are. Only then can we work with them, tame them, make them work for us, which is only right and just. It is their purpose in life. Only when they have been tamed can they truly fulfill their destiny, to define the business need of those business managers and subject matter experts in words that the information technology professionals can understand and use to develop a technology solution that meets those needs. But how can we, those responsible for defining business needs, tame these wild beasts? The answer: one step at a time. For starters, you have to capture them.
The key to capturing the business requirement is not to worry about what it looks like (looks can be deceptive) or whether it is a legitimate requirement or not. The process of taming it, when followed rigorously, will ultimately reveal its true nature. The technical name for this stage in the life of the business requirement is "Captured".
Stage: Sentenced!
Once the business requirement has been captured, we can begin to nurse it along, trying to help it achieve its full potential. To that end, we have to state it in a simple, complete, well-structured sentence that:
- states one thing and states it well;
- does not contain conjunctions (and, or, …);
- contains subject, verb, object and appropriate modifiers;
- does not depend on other sources of information; and
- defines a feature, function, fact, or behavior that the future business solution has to enable, execute, enforce, or exhibit.
Only when the business requirement meets these 5 criteria can we definitively state that it has advanced to the stage in its evolution technically referred to as "Sentenced".
Stage: Whatified!
The next stage in the process of taming the business requirement requires that we establish whether it is a legitimate business requirement or a technical specification in disguise. To do this, we need to ensure that it states "what" should be done, not "how" to do it by:
- avoiding preconceived solutions;
- describing business logic (rules) independent of the technology; and
- expressing the what (destination), not the how (journey).
At this time, we can maintain that the young requirement has reached a state in its development that experts refer to as "Whatified".
Stage: Scoped!
Once a business requirement is "Whatified", we need to weed out those business requirements that do not really "fit in". During the hunt, we were being careful not to scare off any potential "real" business requirements. As a result, we now have captured some business requirements that we do not actually need. To test the validity of each business requirement in our herd (official statement: requirements come in herds), we now need to evaluate whether it targets components that are in scope for your project in that:
- it focuses on a desired behavior or feature of one or more components of the business system; and
- you have the authority to implement it without impacting out-of-scope components.
If the business requirement survives this critical step, we maintain that it is now "Scoped".
Stage: Clarified!
Now that our timid, frightened, little business requirement is starting to evolve, we have to make sure that it can survive the threats that the development community poses. Remember, that is not the requirement’s natural habitat, so we have to give it the resources it needs to be able to move into that which is often perceived as hostile terrain. The best protection we can provide the business requirement is to ensure that it is understandable, unambiguous, and clear by proving that:
- it is understandable to "knowledge peers";
- all terms have been revised, defined, and/or clarified; and
- it has a single meaning in the context of the subject area.
To indicate the strengthened state of the business requirement at this stage in its life, we can now claim that it has reached the state of being "Clarified".
Stage: Quantified!
An additional defense mechanism that we can protect the business requirement with to help it survive the development process is to test whether or not it is objectively measurable by:
- clearly stating functional and informational dimensions;
- referring to business rules for specific values; and
- defining performance in measurable terms.
If the business requirement can pass these tests, we can now confer upon it the title of "Quantified".
Stage: Confirmed!
Now that we have trained the young business requirement and given it all of the skills it needs to survive, we are ready to allow it to rejoin others of its kind. A single business requirement does not exist in isolation, it has no value alone. To provide true value, to achieve their full potential, we need to allow — nay, we need to encourage business requirements to form groups within their herd. Only in the herd can the individual bloom. To fit into the society of business requirements that define a coherent business solution that can be supported by technology, the individual business requirement now needs to become one of a consistent, non-redundant, complete set of prioritized statements that:
- neither repeats nor contradicts any other requirements;
- is prioritized to ensure that the most important requirements are delivered first; and
- defines what you need or want and what you don’t need or don’t want.
Then, and only then, can we confer upon the business requirement that we captured, sentenced, whatified, clarified, and quantified the hallowed state of "Confirmed".
Future Stages
We do not want to mislead you, dear reader, there are further stages in the evolution of this thing we call a business requirement. Notably, it will ultimately need to be tracked, probably modified, implemented, verified, and maintained before its effective life span ends. The term voted most-likely-to-define the well-behaved business requirement throughout these final transitions is the exalted state we call "Managed". But the journey from "Confirmed" to "Managed" is an arduous trip that exceeds the scope of today’s tirade. It might, however, just prove to be important enough to be described another day.
