“Ready-fire-aim” is a humorous expression for what happens when groups act before they plan, building something before they find out what was really needed. Groups instead are told to develop requirements, which are supposed to allow them to "aim" a product or solution to fit the true needs of a customer. However, requirements frequently don't work that way.
The problem is that requirements often form the basis for contractual agreements between adversarial parties. To stay on the safe side, the authors may simply describe in technical terms exactly what needs to be built. Such documents are actually specifications and not really requirements. Rather than analyzing what is needed and targeting technology to fulfill those needs, this “safer” way defines a solution before the problem is fully articulated.
In such adversarial situations, the object of the contractor is to find “wiggle room” and loopholes, whereas the object of the purchasing group is to minimize the chance of non-compliance.
Central to a contract is what is called “a meeting of the minds.” It’s an agreement. One party is supposed to do what the other party asks, for “consideration” (which means compensation). Requirements should operate in the same way: you reach an understanding of what you require with your contractor, and the contractor delivers something that satisfies that need.
Technical specifications might work for ordering components, such as a replacement motor for an appliance. However, above the component level, technology interacts within a context that involves people. Those people have an expectation about how the technology will perform within that context (i.e., how the technology will provide value). Requirements should capture that expectation, and form the basis for evaluating whether the deployed system meets those expectations.
Requirements should define the needs principally based on what the technology must do (the expectations) to enable or facilitate the workflow and associated tasks. So an ATM machine is defined in terms of reading an authentication token (e.g., credit card), challenging (e.g., requesting a PIN), and providing a service (e.g., dispensing cash). How the ATM machine maker accomplishes this is not important to most users. They assume that factors such as security and reliability are covered under prevailing standards and practices that every ATM machine manufacturer must follow.
At APConnsulting, LLC, we believe that you cannot build a technological product or solution without first understanding stakeholder needs and issues, hammering out differences, and formulating requirements that capture the needs of the group, including variations that must be supported for different communities of users.
We have defined an approach called a “business solution workflow review” to gather just such requirements. After the goals and drivers and key business principles and models are captured and agreed upon, the participants give careful consideration to usage scenarios. By analyzing workflows, principal roles, and critical tasks, the group discovers important requirements for a successful solution. They also review system quality attributes, which impact the success of any technological solution.
The usage-centered requirements form the bridge to the technology. Once the participants know the ways in which the technology will be used, and what the critical operations are, technologists can then fabricate technical architectures and designs that fully capture the stakeholder needs. The as-built technology is thus specified and built based on real business fit rather than a focus on lists of functions and features.