Requirements in the Iterative Model
From the requirements management perspective, the iterative approach provides two major advantages.
With this software process model in mind, we can move forward to the requirements activities that are pertinent to each phase in the lifecycle. Yet we also recognize that the point in the lifecycle in which an activity occurs is not fixed or predetermined, and indeed, the requirements activities can be revisited as necessary over time as our understanding of the system evolves.
On the surface, this discussion of software process models may seem to be off-topic in a requirements text. Assuredly, it is not. In the move from a waterfall model to the iterative model, we can finally dispense with the notion that requirements are fully discoverable and can be fully documented
development begins and that they can be fixed or
thereafter. It was an interesting theory, and it appeared to make life for developers more straightforward as they imagined their work could be built on an unchanging foundation. Unfortunately, it simply did not work. Requirements change, and to
Chapter 4. The Software Team
Individuals choose software development as their career domain for a variety of reasons. Some read
In any case, it was the allure of
that kept the flame burning: We love the bits and bytes, the operating systems, the databases, the development tools, the keyboard shortcuts, the languages. Who else but software developers could have developed the UNIX operating system? We are focused on technology, and that is our driving motivation. Perhaps because of an innate genetic tendency or perhaps because we
One result of this, which was further compounded by the simple single-