Category list

Requirements in the Iterative Model

From the requirements management perspective, the iterative approach provides two major advantages.

Better adaptability to requirements change. The model recognizes that requirements change and requirements activities are therefore active throughout the lifecycle. Requirements are not frozen, they are understood early at a certain level of detail, and they are refined successively over time. And since they are revisited at every iteration, new requirements can be considered at each iteration.
Better scope management. If the first iteration is missed by 30 percent, that's an indicator that the project may be badly scoped, and adjustments can be made. Even if scope is not well managed, multiple executable iterations have been developed by the time the deadline is reached, and the last may even be deployable . Even though it lacks some functionality, the release will deliver value to the user if the features have been picked and prioritized carefully , allowing your customer to meet objectives, at least in part, as you continue with further development iterations. And, if the architecture is robust and addresses the key technical issues, your team will have a solid platform on which to base the additional functionality.

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.

Summary

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 before development begins and that they can be fixed or frozen 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 pretend otherwise is, at best, foolish. We must understand that requirements discovery and requirements management are full lifecycle issues. The more we discover, the more we discover, and the better we understand the system to be built. With this context behind us, we can now move on to discovering that which we need to discover about our impending system. And we'll learn how to manage requirements change in a way that will augment, rather than destroy, the foundation for our development work.

Chapter 4. The Software Team

Computer programming is a human activity.

”Gerald Weinberg [1971]

Key Points

Effective requirements management can be accomplished only by an effective software team.
Requirements management touches every team member, albeit in different ways.
Effective requirements management requires mastering six team skills.

Individuals choose software development as their career domain for a variety of reasons. Some read Popular Science and Wired as kids , gravitated to the programming courses available in high school, majored in engineering or computer science in college, and thereby directed their lives down this specific technical path . For others, it was serendipity ; finding themselves at a place in space and time when the need for software was apparent, where they could participate in meeting that need, they gradually evolved into making a full-time commitment in the field.

In any case, it was the allure of technology 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 skipped all the "softer" classes in college ”psychology, drama, or, even worse , English! ”we are generally focused less on the people side of our business and more on the bits and bytes. We tend not to party well, ^[1] and some of us have trouble relating to people outside of work, when there is no common technology substrate on which to base a discussion.

^[1] During an open house, for example, one programmer remained at his desk throughout the party, programming happily, even though his desk was in the middle of the party room. After finishing his work, he simply got up, arranged his desk, and left the building without a word to anyone . What is unusual about this behavior? In our industry? Nothing!

One result of this, which was further compounded by the simple single- user nature of the tools we used and the more limited size of the applications we developed, was the tendency toward software development as an individual activity. The programmer defined, designed, wrote, and, typically, tested his or her own work. Perhaps testers were around to help with the heavy lifting at the end, but the focus clearly was on individual activity. The "programmer as hero" was the common paradigm.

Buy on amazon.com >>

Leffingwell D., Widrig D.

<< Previous page

Table of contents

Next page >>

Flylib.com

Category list

Similar pages

Requirements in the Iterative Model