Home
Experiential Requirements
This article was published in the Cutter IT E-Mail Advisor, December 16, 1998.
This month's issue of the Communications of the ACM (Vol. 41, No. 12, December 1998) focuses on the topic of requirements traceability, which is defined as "the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through the whole system's life cycle". The potential benefits of requirements traceability have created a new market of tools and spurred new thinking about software development processes.
Although this all sounds quite powerful, I keep thinking that something critical will be missing at companies that rely too heavily on requirements management. That "something" is the domain knowledge the engineers building the system need to ensure success.
My experience has shown that domain knowledge (knowledge of the rules, procedures, nomenclature, etc.) is more important than technical skills in successful software projects. Without it, how can we be certain the correct problem is being solved? How can we be certain the solution can withstand the forces of change that exist in every domain? Software developers are responsible for making many decisions regarding the implementation of the system. Quite often, there is no choice but to rely on their knowledge to make the right decision.
Requirements experts will challenge me on these assertions. They claim that clearly documented -- and, of course, traceable -- requirements address the problem of building the "right" system more effectively than relying on developer knowledge. Moreover, well-documented requirements identify the forces of change so that developers can be certain they are appropriately addressed. This is an almost impossible point to argue: certainly, well-documented (and therefore traceable) requirements contribute enormously to the success of a software project. The more the better.
But if you're like me, you're ready to discount that argument as too simplistic to be of value. I challenge anyone to name a project whose requirements were so well documented that developers weren't making important decisions using their domain knowledge. (If this were the case, why not just use automatic programming and generate the system from the perfectly defined requirements -- no developers needed? Oh yeah -- it's because we know that automatic programming has failed, too, due to the difficulty in specifying the system....)
What is a manager to do? I call my approach to this problem "experiential requirements," a technique that blends domain knowledge with clearly written requirements. In this approach, developers are asked to perform the work processes of the system they are building. If they are asked to build a new data entry system, they must first do the work of the current data entry operators. This gives them immediate experience in the problem domain they are asked to solve -- experiential requirements. These developers then work with the owners of the requirements document (such as the marketing department or the project manager), codifying and documenting those requirements that are collectively deemed most important. This approach isn't needed for every release and is less useful when developers really are domain experts. Of course, developers cannot experience every system. If you're building a system for diagnosing patients and writing prescriptions developers will never play the role of a doctor! When developers simply cannot engage in experiential requirements they can use shadowing, a related technique in which they closely follow and/or track the user as they perform their normal work tasks.
The benefits to this approach are substantial. Developers gain an appreciation of the business problem they have been asked to solve from the perspective of the user. This allows them to suggest implementation mechanisms that customers may not have considered. More important, it builds a critical empathy between the developers and the users. The owners of the requirements document also benefit. Instead of worrying about communicating every detail of the system or problem domain, they can instead focus on those requirements that really are critical for business success. Although both sides benefit from increased clarity in communication, the ultimate beneficiary is the user, who is more likely to get a system that meets their requirements.