Just-in-time requirements analysis (JITRA) is the shiny object of the day when thinking about running projects with an agile (iterative) process.
Howard Deiner explains the concept well. In a nutshell, it is the process of discovering requirements as you go—Mr. Deiner uses the analogy of course-correction aptly.
The challenge, as with most shiny objects, is that the devil is in the details. It is too common that people will start running full speed ahead without understanding the details or properly exploring the first principles behind the concept.
One of the good ideas embraced by agile teams is to defer decisions until the “last responsible moment”—proposed by Mary and Tom Poppendieck in Lean Software Development and contrasted with the old Boy Scout motto of “be prepared” in this commentary by Jeff Atwood.
The first principle tells us that the later we make a decision, the more information we have by which to make that decision—and therefore we will have a better decision. We also know that delaying decisions comes with a cost—the burden of living with uncertainty and the risk of waiting until it is too late to act on the decision.
“Responsible” is the key word here. You don’t wait until the last possible moment. You merely wait until additional delays would incur greater additional costs than additional benefits.
You can debate the premise that things “can be known in advance” at all, as Frederick Brooks does in The Design of Design. My conclusion—it almost doesn’t matter.
All requirements are built on hypothesis (or conjecture, if you’re cynical). “If you do [x], then [y] will result. Therefore, since I require [y], you must do [x].” You can form hypotheses before a project starts or any time before the work on [x] is completed. You can form hypotheses in advance. You can improve them over time, as more information becomes available to you. And they will change over time, as the available information changes. The “right” answer, in my opinion, is to do a mix of both.
JITRA embodies the idea that you form your hypothesis as late as responsible, not as late as possible—because you minimize the risk of waste that comes with defining hypotheses early, because of the risk of error.
One of the challenges is that most people don’t realize which part of the hypothesis is the requirement. It is not—as commonly believed—“If you do [x] then [y] will result” or “you must do [x].” Neither statement is a requirement. The first is a hypothesis, and the last is an instruction. The requirement is “I require [y].”
You can identify requirements before a project starts. There will be mistakes in your work. In parallel with the ongoing development work, you can use the time to improve your requirements. You can also use the work-in-progress as an additional elicitation tool to clarify your understanding and improve your requirements. That is where you should focus—not on achieving the “JITRA merit badge.”
