A Requirement by Any Other Name

The response I received to a recent article on the importance of trust in gathering requirements prompted me to ask myself exactly what was a business requirement. Because there were no comments on the trust aspect and a variety of views on the definition of a business requirement, I had to ask myself this question: If the definition of a business requirement varies from person to person, is it still the same thing? To paraphrase, is it true that a requirement is a requirement is a requirement? After all, a requirement by any other name…

So what is a requirement? Many years ago I worked for a national retailer in an IT group which developed two specifications for developing software. The first was a business requirements document (BRD), which we called a “bird.” The second was a technical requirements document (TRD), which we didn’t bother to pronounce. We never agonized over which requirements belonged in each category. We put those that came from the business in the BRD. Generally speaking these dealt with the capabilities of the software, such as the way people would use the system and the data that needed to be entered or displayed. Those relating to how we were going to implement the software were documented in the TRD.

But as with many things in life, the more I have learned, the less I know. Not only has the distinction between business and technical requirements become blurred, but even the definition of a business requirement has evolved.

We used to say that business requirements described the “what” and technical requirements described the “how.” But the lines between these two are not clearly drawn. For example, is a business process a “what” or a “how?” Next we divided requirements into functional and non-functional and disagreed about whether or not non-functional requirements were considered technical.

Definition of a Business Requirement.

A requirement seems easy enough to define, since the IEE’s definition has been pretty well-accepted: -“a condition or capability needed by a stakeholder to solve a problem or achieve an objective.” One difficulty with this definition, however, is that requirements no longer apply to software only and business analysts work on a variety of efforts. Business analysis applies to the completion of feasibility studies, new business processes, recommendations on staffing, to name just a few. We are left to ponder whether completing business analysis work always results in requirements as defined above.

Another difficulty is that while there is general agreement that requirements can be classified and that one of the classifications is “business requirement,” there is no agreement on what those classifications should be. It would be wonderful to refer to a body of knowledge to help us out. Indeed, one of the truly great things about having a body of knowledge is that we practitioners can use language that is generally accepted and understood by all. We no longer have to waste time discussing the definition of a requirement, of business analysis, of a business requirement. Or do we?

The BABOK® Guide 2.0 describes its classification scheme to include business requirements (goals and objectives) stakeholder requirements (those coming from the business domain perspective), solution requirements (functional and non-functional) and those temporary requirements that help the organization transition from the current to the future state.

The PMBOK® Guide – 4^th Edition, on the other hand, classifies requirements as project and product (so far so good). But project requirements are classified as “business, project management, delivery, etc.” Product requirements are “technical requirements, security requirements, performance requirements, etc.” There are many ways to interpret these categories. Perhaps technical requirements equate to functional requirements, perhaps not. Perhaps delivery requirements refer to the target date, perhaps not. The point is that if we are going to rely on bodies of knowledge to help us speak a common language, it would be wonderful if they were aligned.

So what is a business requirement, anyhow? Being the old dog that I am, I still like thinking of business requirements as the umbrella term for those requirements approved by the business domain, regardless of the level of detail. However, I do believe I can learn a new trick or two, and can certainly see the rationale for defining the business requirements as the highest level goals and objectives. (BABOK® Guide). And if anyone knows what a delivery requirement is, I’d sure appreciate your letting me know.

Don’t forget to post your comments below.

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected].