Software Requirements by Karl E Wiegers & Joy Beatty

Author:Karl E Wiegers & Joy Beatty
Language: eng
Format: epub
Tags: COMPUTERS / Software Development & Engineering / General
ISBN: 9780735679610
Publisher: Microsoft Press
Published: 2013-08-11T16:00:00+00:00

Games people play with priorities

The knee-jerk response to a request for customers to set priorities sometimes is, “I need all these features. Just make it happen.” They feel that every requirement should be ranked as high priority, and they might not recognize that prioritization will help to ensure the project’s success. Start by explaining that all things cannot be done simultaneously, so you want to make sure you work on the right things first. It can be difficult to persuade customers to discuss priorities if they know that low-priority requirements might never be implemented. One developer told me that it wasn’t politically acceptable in his company to say that a requirement had low priority. Therefore, the priority categories they adopted were “high,” “super-high,” and “incredibly high.” Another developer who was filling the BA role claimed that priorities weren’t necessary: if he wrote something in the SRS, he intended to build it. That doesn’t address the issue of when each piece of functionality gets built, though.

I recently visited one company that had great difficulty getting their projects done on time. Although management claimed that there would be multiple releases of applications so lower-priority requirements could wait, in reality each project delivered just a single release. Consequently, the stakeholders all knew that they only had one shot to get all the functionality they needed. Every requirement, therefore, became high priority, overloading the team’s capacity to deliver.

In reality, some system capabilities are more essential than others from the perspective of satisfying business objectives. This becomes apparent during the all-too-common “rapid descoping phase” late in the project, when nonessential features are jettisoned to ensure that the critical capabilities ship on schedule. At that point, people are clearly making priority decisions, but in a panicked state. Setting priorities early in the project and reassessing them in response to changing customer preferences, market conditions, and business events lets the team spend time wisely on high-value activities. Implementing most of a feature before you conclude that it isn’t necessary is wasteful and frustrating.

If left to their own devices, customers will establish perhaps 85 percent of the requirements as high priority, 10 percent as medium, and 5 percent as low. This doesn’t give the project manager much flexibility. If all requirements truly are of top priority, your project has a high risk of not being fully successful. Scrub the requirements to eliminate any that aren’t essential and to simplify those that are unnecessarily complex. One study found that nearly two-thirds of the features developed in software systems are rarely or never used ([ref225]). To encourage customers to acknowledge that some requirements have lower priority, the analyst can ask questions such as the following:

Is there some other way to satisfy the need that this requirement addresses?

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.