True Requirements
Traditional or even enlightened requirements-gathering processes are difficult because:
- Having enough time and involvement from the right people is difficult.
- Extracting requirements is mostly verbal.
- Business people know what they want in general, but not specifically in the level of detail that one needs to document requirements completely.
- Documenting requirements is tedious.
- Reading and approving written requirements documentation can be confusing and generally doesn't engage business people.
- Most likely, true requirements surface in final testing or training or once stakeholders and end-users see the final application.
If requirements gathering is poor, why do we do it?
We have historically had no choice, because:
- Early in the history of software development, applications developers learned that when simply building what they think business wants, the application never matches what business needs.
- Applications developers lamented that "if we'd just understood what you wanted, we would have built it."
- Experienced applications developers know (after experiencing this dilemma personally) that if you build an application to one set of needs and then must change it to a different set of needs, the project schedule and budget is at risk.
- We concluded that we must figure out in advance what we need to develop.
- Consequently, our industry has spent enormous effort over several decades on methods to gather, correctly capture, and document requirements. In fact, leading systems integration companies market as their special competency proprietary requirements methodologies.
In spite of the logic and effort, as an industry we have seldom figured out how to determine true requirements in advance of building an application.
What are true requirements?
True requirements define the application that the business describes as, "this is exactly what we want now." In our experience, true requirements emerge only after business people finally:
- Use an application on real data either in production or in a UseCase production simulation.
- Gain experience and comfort with the application and its behavior.
- Use the application on variations of their business transactions.
- Offer improvement suggestions and ideas.
- Try out implemented suggestions. (In fact, the Try-it; Improve-it loop often repeats multiple times.
Extraordinary Speed makes discovering true requirements possible
TenFold's founders set out to build a technology that would enable applications developers to build an application so quickly that requirements gathering could be done in real-time with business end-users.
TenFold technology lets an applications developer build an application extraordinarily quickly. Once built, a business person can use it, verify that it addresses the business problem, criticize it, offer improvement suggestions, see what they really need, et cetera. TenFold technology makes it easy to repeat this process many times.
True requirements are a discovery for all involved
With rapid building, an applications developer, who may be a business person or who may be working with a business person, can quickly change the emerging application to react to true requirements until the business person affirms, "this is exactly what I really want now."