7.2. Guideline: Should We Analyze These Thoroughly During Inception?
No. The UP is an iterative and evolutionary method, which means that production-quality programming and testing should happen very early, long before most requirements have been fully analyzed or recorded. Feedback from early programming and tests evolve the requirements.However, research shows that is useful to have a high-level "top ten" list of coarse-grained requirements near the start. It is also useful to spend non-trivial early time understanding the non-functional requirements (such as performance or reliability), as these have a significant impact on architectural choices.
Reliable Specifications: An Oxymoron?
The following written requirement examples could promote the illusion that the real requirements are understood and well-defined, and can (early on) be used to reliably estimate and plan the project. This illusion is more strong for non-software developers; programmers know from painful experience how unreliable it is. As mentioned, case studies (for example, [Thomas01] and [Larman03]) now show it is a misunderstanding to believe that early detailed requirements are useful or reliable on software projects. In fact, quite the opposite, as almost 50% of early waterfall-specified features are never used in a system.What really matters is quickly building software that passes the acceptance tests defined by the users, and that meets their true goalswhich are often not discovered until users are evaluating or working with the software.Writing a Vision and Supplementary Specification is worthwhile as an exercise in clarifying a first approximation of what is wanted, the motivation for the product, and as a repository for the big ideas. But they are notnor is any requirements artifacta reliable specification. Only writing code, testing it, getting feedback, ongoing close collaboration with users and customers, and adapting, truly hit the mark.This is not a call to abandon analysis and thinking, and just rush to code, but a suggestion to treat written requirements lightly, start programming early, and continuallyideally, dailyengage users and tests for feedback.