Section 6.5. Introduce Software Requirements Carefully


6.5. Introduce Software Requirements Carefully

There are plenty of books that tell us that poor requirements are the most common cause of software quality problems. Yet many project managers have had difficulty bootstrapping efforts within their own teams to implement better software requirements practices. Software requirements should make intuitive sense: before a team can build software, they need to know what to build. In practice, however, many project managers have found that it is difficult to convince their teams to adopt good software requirements engineering practices. This is especially true for certain kinds of projects:

  • Small projects in which the programmer is confident that he understands all of the requirements already

  • Projects in which "everybody" knows what the software is supposed to do

  • Projects without a user interface (like batch processes or back-end calculation software)

  • Any project considered "technical" one in which one or more of the stakeholders is a programmer

In all these projects, there is an expectation that a programmer can make all of the decisions about the behavior of the software. It seems intuitive (but incorrect) that since the programmer can already decide on the details of the implementation, he should also have a grasp on what is being implemented. The programmer is often the most confident person in the organization about his own ability to do this, which the rest of the team and the stakeholders always find reassuring.

This is a difficult situation for any project manager. It's never a good idea to try to force the team to accept requirements (or any tool, technique, or practice). But when software requirements are the solution to the team's most pressing problems, it's up to the project manager to convince the team to adopt good requirements practices. Chapter 9 gives many examples of the kinds of problems a project manager may face, and suggests strategies to deal with those problems. With requirements, however, there are a few additional points that may make it easier for a project manager to convince the team to adopt good practices.

6.5.1. Sell the Designers and Programmers First

Software architects, designers, and programmers who are used to working with software requirements tend to find them so important that it's difficult to imagine working without them. But if they have never used requirements before, they instead tend to be resistant to working with them. To the uninitiated, working with requirements may sound restrictive and stifling. In organizations where this is the case, the problem is often compounded by senior managers who do not have as solid a grasp on how their software is developed as they should, and who will be very responsive to any complaints from their technical people. A few negative comments from key programmers can be enough to pull the plug on an entire requirements effort. Even worse, when an organization has not really embraced the idea of software requirements, there is a real danger that the programmers will simply say "yes" to any SRS that comes across their desks, only to ignore or change any requirements that they dislike when they actually build the software.

The key to using software requirements effectively is to help everyone in the organization understand how those requirements will help them build better software. A project manager who is looking to implement requirements should work to bring the designers and developers on board. If a designer feels threatened by the changes, the project manager should show him how the requirements define only the behavior of the software, and not the design. A programmer may object that her creativity is being stifled; maybe she can be shown that the requirements will help prevent the kinds of last-minute changes that cost her weeks of work and made a mess of her code on her last project.

It's not hard to communicate the benefits of change control to the engineering team, because the change control process addresses some of the team's most common complaints. Most software engineers who are working in an organization that does not have good requirements practices are always shooting at moving targets. Changing requirements are a daily fact of life, and even small projects feel like they rapidly spiral out of control because of uncontrolled changes. A project manager can offer to control these changes, so that the team can concentrate on building a good product once rather than rebuilding a poor one over and over again. Once the programmers have been convinced of that, it's not hard to show them how software requirements are clearly a means toward that end.

However, it is important that the project manager does not gloss over the fact that when a designer or programmer is working to a set of requirements, it creates a more restrictive environment than he is used to. This should be out in the open: otherwise, he will feel that the project manager is trying to hide the obvious, which can lead to distrust and reduced morale among the team members. Programmers can be convinced of the benefits as well. It's likely that interviewing users is the programmers' least favorite part of the job, and being handed an SRS that contains everything the users want, so that they do not have to spend time talking to them, is often enough of a trade-off to make up for a small reduction in freedom.

In the end, requirements are good for the designers and programmers, and it should not be too difficult for a project manager to help them understand that. Once the engineering team starts to see requirements engineering as a way for them to increase their quality, reduce their rework, and make their projects go much more smoothly, it is much easier to get the management of the organization on board.

6.5.2. Speak the Managers' Language

Building software without requirements is similar to building a house without blueprints. It's possible to start hammering nails into wood, and the builders will probably come up with some sort of structure that will stand on its own and provide shelter. But if those builders start hammering nails before the blueprints are done, it's almost impossible that they will end up building a house that matches the blueprints. But this doesn't stop managers from trying to get the programming team to start building the software before the requirements are complete.

Many managers do not understand why requirements engineering is important. All they see is people sitting around and writing a bunch of documents instead of writing code. It's not immediately obvious to them why the team is "wasting" so much time on this. The code has to be written, and they don't see why the programmers have to wait until they get these documents to begin writing it. It seems to them that the programmers can at least get started on writing something. For a lot of managers, it's very frustrating when programmers are not writing codeevery day they see the team writing requirements is one more day that the programmers didn't get started building the software. When the designers and programmers are not sold on the idea of requirements engineering, there is little chance that anyone else in the organization will accept it.

Many managers don't speak the language of software engineering. When this is the case, any attempt to sell them on software requirements by giving a technical explanation about software behavior and quality attributes will cause their eyes to glaze over. Some managers are good at convincing engineers that they understand technical issues that are really beyond them; a project manager might walk away from this conversation thinking that no other person had agreed that the team should implement requirements engineering on a project. But this is probably the manager's reaction to any technical change suggested by a team member, and he will withdraw his "support" (or claim that he never understood it in the first place and never really agreed) at the first sign of friction between engineers.

The way to sell the managers on requirements engineering is to speak their language. Most senior managers who are in charge of making project decisions are most concerned with getting the product out the door faster, and with getting fewer calls from users who have found that the software does not do what they need it to do. The project manager who is trying to put the software requirements tools in place should show the manager how they can fix these very serious problems that have plagued past projects. The goal is not to drive a wedge between the programmers and the stakeholders and users. Rather, requirements help everyone reach the same goal.

A common complaint among stakeholders and users is that programmers have not taken the time to listen to them before starting in on building the software. If this goes unchecked in an organization for too long, people can start to see the programmers as cocky. A project manager working on selling the idea of requirements can look for examples of this in the organization. There are probably instances in the past when a programmer has assured a stakeholder or user that he understands exactly what she needs, only to go ahead and build something that only does half of what the stakeholder wanted, plus a bunch of stuff that doesn't make any sense at all. There may be a piece of software out in the organization that has a bunch of confusing buttons or menu options; it's possible that the intended users don't even know what they do. There may have been a rollout in the past where the users had to alter the way they did their work in order to accommodate the software. These are all advertisements for adding software requirements engineering activities to the next project, and the project manager can use them as examples of the kinds of problems that software requirements can fix.

Selling the idea of requirements to senior managers and decision-makers usually takes a lot of effort. The project manager will have to repeat herself many times. In many organizations, the managers do not really understand how the software gets builtthey leave those "technical details" to the engineers. Luckily, software requirements engineering activities lend themselves to explanations in simple, layman's language.

It should make intuitive sense to a senior manager that the programmers are not mind-readers. It's likely that they have neither the time nor the inclination to sit down and interview everyone who may have something to add to the project. And the experts do not have time to make themselves available to the programmers for the entire length of the project. The solution is clearly to have someone sit down and talk to the people who need the software built. That person should be a software engineer capable of eliciting software requirements and building a feasible software requirements specification. Most managers should understand this on a "gut" level.



Applied Software Project Management
Applied Software Project Management
ISBN: 0596009488
EAN: 2147483647
Year: 2003
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net