Business Requirements: Managing the Flow of Requests

Business Requirements are a statement of needs. It is a request or demand for change. The list of changes is an “inventory” of needs and “change requests”. 

Identifying, defining and clearly expressing these needs represents the most critical phase in the development of a business application, web site, infrastructure or product.

It is the phase in a project that involves the business communities the most. As such it is their “show” and their responsibility to get this right. It is a phase that represents at least 25% of a projects cost, contributes 70% to its success  and adds 90% to a project or products value.

A project or product can fail for the following reasons:

• IF the requirements are correctly stated and the system is well engineered and built BUT the system grossly misinterprets the requirements then you have a failure.
• IF the system is well engineered and built AND the requirements have been correctly interpreted BUT the requirements itself miss the target then you have a failure.

But gathering and expressing business requirements in a form that technologists can understand, interpret and convert into a “system” requires a skill that few business people have. There are no business courses in college or MBA programs that train or equip the business person with such a skill. 

As a consequence over 50% of software projects end up being classified as “failures”. This is a massive cost to the business community and a clear defeat for the software engineering community.

But there are reasons for this failure. Going from a business “need” to a system that expresses that need requires a series of “transformations”. It is during the transformation process where the "project risks" are greatest. During these transformations the project and the team are most exposed to the risks of introducing errors through misinterpretation and lack of understanding.

There is no such thing as a “Perfect Requirement”

The process of getting and acquiring a perfect set of requirements is messy and prone to constant change

WHY? Because requirements are about intangibles. In gathering and defining needs you are dealing with aspects of life you cant “see, touch, smell or hear”  You are dealing with trying to discover something about an aspect of life that is not immediately available to your sensory apparatus.  Making an "intangible" appear concrete and describing it is never easy 

Requirements are a discovery process. In any project there are many subjects or fields of expertise one needs to know and master. Getting subject matter specialists with deep knowledge of their area is not easy and getting generalists that understands how all the different subjects interrelate is near impossible.

Because these elements are absent 90% of the time requirements becomes a process of discovery for the team as they attempt to probe, understand, uncover and gain insight into the domain in question. So making the wrong discoveries can be an expensive proposition

Embracing Change in Requirements

Good requirements are predicated on the process of discovery and insights. But to discover and gain insight on anything takes time. Discovery and insight is incremental. Each new insight improves and changes the prior state of ones knowledge and each new insight triggers the change.

Technology and science advances by the same principle of discovery and insight and business systems are subject to the same set of rules.

Change is always good and should be embraced when it enables you to evolve and improve something.

Requirements is not a phase but a continuum

Most of the feedback and changes from users comes when a system is already built and in use. Its is also the most expensive stage of a project to make changes.

• It cost $10 to change a feature description in a PowerPoint or Word doc
• It costs $100 to change this feature in a wireframe design
• It costs $500 to Change this feature in a Prototype
• It costs $10,000 to make the same change after the system is built

The above is to illustrate the exponential nature of costs as you move from requirements through design and the final build. Clearly its cheaper to discover and make changes early in the process than later