Five Things IT Managers Should Know About Software Requirements

1 2 Page 2
Page 2 of 2

Beware, however, of requirements documents with multiple purposes. It’s easy for these to become corporate documents rather than product specifications—which may have conflicting roles. Typically, a contract with outside software providers has customers sign off on software requirements before implementation begins. As one consultant pointed out, because the stakeholders (among them the CIO) need this to happen as soon as possible, the signed requirements are written to be suitable for customers and contracts, not for developers and testers. According to the consultant from Latvia, later in the process, developers and testers find the requirements unspecific and ambiguous, and they don’t reflect deep knowledge of the business. The developers discover that the requirements aren’t technically achievable and are barely testable. Sometimes, once the developers are under way, they’ll learn the requirements are simply wrong. And, he says, "While that’s the signed document (and the requirements phase is marked as 100 percent complete in a master schedule), it is not going to be changed anymore, no matter how poor it is."

One developer I met online, Malcolm, cynically observed that, "What happens is that the specification looks superficially complete, but in fact contains hidden inconsistencies, glossing over, omissions or impossible conditions. The document, if it is binding, then becomes an impediment to the project, plus a source of irritation."

One solution may be to rely more on business goals than exacting technical details. Gottesdiener recommends that companies break out of the "system shall ..." paradigm for specifying requirements. She says, "We’ve got to stop relying on long, tedious textual requirements documents. Insist on smarter documentation." Instead, rely on models built in collaboration with business folks, such as requirements workshops. According to Gottesdiener, "Customers ’playing around’ with their needs with cheap, fast and low-fidelity prototypes facilitates the meta-pattern underlying requirements development: evolution. Evolution is chaos, with feedback."

One developer suspects the preference for more-or-less detail may depend on the nature of the environment. "If you’re in a situation where there is a high level of trust, a loose expression of requirements allows the team (including the customer or nearest surrogate) to zero in on the real requirements through some amount of iteration." In his view, the need for excruciating detail is characteristic of an environment in which the best political defense was to show that the code did what the requirements said—even if the best commercial value was otherwise. "To do that, the requirements must be explicitly definitive." If you’re unsure if your development department has achieved that measure of trust, this agile developer suggests that "requirements should begin with some kind of preamble giving intention. Sometimes, two different implementations might completely satisfy the raw requirements, but one might be ever so much more idiomatic to the underlying business motivation and thus more maintainable and extensible."

So, how do you know how much detail is "enough" for a software specification? There probably isn’t a single right answer. The savvy manager will recognize or create an appropriate corporate culture—which may mean asking developers and testers, during job interviews, "How detailed do you prefer application requirements to be?" Because if a CIO thinks the requirements documentation should be one way and the development team wants it another way, friction is inevitable.

It’s bad enough to deal with developers who can be counted on to quibble over the amount of detail put into the software requirements. But now we get to their major concern: the perception that CIOs are poor at dealing with changing requirements.

4. Working from Ignorance: Recognize that Requirements Change

While developers disagree vehemently about the optimum granularity of software requirements documentation, they are in complete agreement about another aspect of the process: The requirements will change. According to developers, however, managers and CIOs apparently prefer to imagine that the software will adhere to the requirements document even when it’s wrong or misleading. The clueful CIO will understand this key fact, as well as the importance of building a change management process into the development lifecycle so that changes can be controlled and dealt with.

The first issue in changing requirements is the notion of estimating project effort. Brian Marick, an independent consultant on agile methods, points out that every project starts from ignorance; you have the least amount of data available with which to make sane decisions. "If you knew now what you’ll know tomorrow, the decision would be better," Marick points out. This isn’t an excuse for procrastination, per se, but a philosophy of waiting where appropriate. That often means removing detail, such as deciding only on the broad product direction, and specifying details one piece at a time. However, he cautions, "This approach requires careful attention to feedback from the real world, so that you in fact take into account tomorrow’s information when making tomorrow’s decision, and constantly improving your ability to react to change and recover from mistakes. It does no good to know what the right decision is tomorrow when you do not have the resources to implement it."

Scott Ambler, Practice Leader Agile Development within the IBM Methods group, agrees that getting a "solid" estimate up front is a naïve desire. "That one decision motivates a whole bunch of really bad practices, such as big requirements up front (BRUF), big design up front (BDUF), and judging the project team on whether they meet the budget instead of whether they achieved great ROI."

Poor or underspecified requirements aren’t necessarily a sign of incompetence. An experienced software architect and lead developer at a CMMI Level 5 company suggests that requirements are inadequate for conveying everything necessary up front. "It’s partly because the users are not always able to express all their actual needs; partly because requirements do not describe current work practices, but rather describe expectations for the future system; and partly because requirements have to address many business-related aspects, such as vendor selection, cost estimation and contractual obligations," he says.

But whether it’s a contractual requirement to dot all I’s and cross all T’s, or simply the way you learned to scope out every project, your programming staff wants you to recognize that change is the norm rather than the exception. Agile developer Dave Nicolette says, "We need to turn away from the traditional approach of trying to nail down all the detailed requirements up front, and then imposing so-called ’change control’ processes designed not to control change, but to discourage it. Instead, CIOs should actively and firmly support methods that embrace change and deal with it gracefully, as agile and lean methods are meant to do."

Since requirements change over time, Hazen points out, the process needs to be managed appropriately. There will be reviews and sign-offs again. The project time line must be revisited to determine if deadlines remain realistic. At some point, you do have to freeze the changes and move forward. Says Hazen, "Scope creep is a killer for projects, especially ones that are time constrained, which the vast majority are."

There is no cutoff point where requirements stop changing, believes developer Stefan Steurs, but many CIOs assume a point exists when everything is perfect and coding may commence. When developers, testers and users get involved in reviews, development, testing, prototyping, piloting and other activities, they feed the discovery process with new elements, some of which can be very disruptive. Adds Steurs, "This means you need decent change management. You want to know throughout the development of the product if the change to the requirements is converging or whether it remains disruptive. ... The CIO has to know what is going on, and it’s time for the next [management] level down to start being honest instead of saying that the clothes of the emperor are very, very nice."

Developers passionately wish that CIOs and other managers would build change management into the development process and make it safe. Otherwise, you put more than the project at risk. Instead, some managers whitewash the situation or software methodologies. Luiz, who works at the Brazil office of one of the biggest consulting companies in the world, says that his firm uses waterfall techniques but casts it in more modern-sounding terms. "We estimate the size of the system using [function point analysis] at the very beginning of each project and use this estimate to sign the contract. So usually in the first two weeks we know exactly how much this system is going to cost and how long it will take to develop it. Of course, we are wrong most of the time and usually we are on the wrong side of ’wrong,’ which means we underestimated the complexity of the system, and it’s going to cost more and take longer to develop than we initially thought. To protect us, we assume that every requirement change is a potential way to grab more of the customer’s money by charging extra and overestimated ’code-monkey hours’ for even trivial changes. Sometimes this works, meaning that we could profit a lot and the customer hates us just a little bit after all this. Many more times, the customer just hates us, we hate our jobs, and our bosses hate us for [their] not being able to go to Aspen this year."

You can be part of the problem, too. Geoffrey Slinker, a software developer for more than 20 years, says he is most irked by the tendency for a software feature mentioned or proposed by the CIO, or any CXO, to instantly become a required feature. "The problem doesn’t lie in the proposed feature," he says. "Often, the feature is a good idea. The problem lies in the disruption that is caused. The proposed feature becomes a high priority just because a CXO made the proposal. ... Even if the statement is an off-the-cuff comment during a demonstration towards the end of the development cycle, the statement can be interpreted as an action item and cause a chain reaction of meetings, changes and re-prioritizations." Remember that your voice carries, Slinker cautions; don’t let your position disrupt the prioritization of software requirements.

Getting the software requirements right is only the first step, though. After the developers and testers have started work, it’s the CIO’s job to ensure that the project stays on track, and that the result adheres to the original promise. And oh boy, does that open up a whole new set of developer foot-stomping

5. Carpet Yanking: Pay Attention to the People on the Front Line

Most developers aren’t asking you to know all the details of a given project. Some believe if a CIO is worrying about specific line items in a software requirements spec, she’s micromanaging, and she isn’t paying attention to the right tasks. But the developers do want the CIO to pay attention to what they’re doing, what they’re telling you, and—perhaps most importantly—what isn’t being said.

Get out of the office. Talk to people. Manage by walking around. Find out whether the software requirements are being instantiated in the real world. Steurs wants his CIO to ask questions and listen carefully. Says Steurs, "The CIO has to realize that if there is no bad news, there is something very wrong. Smiling people nodding ’Yes’ in meetings is not a sign of great intelligence at work."

But don’t pretend to listen if you aren’t going to take action. Richardson says, "Don’t ignore our feedback if you ask for it. That’s not empowering. It’s pretending to include us before yanking the carpet out from under our feet."

Your testing organization is also an early-warning system. According to Pensyl, development staff may propagate positive reports during R&D, but if the test group is vocal at this point in the project, complaining of incomplete, missing and ambiguous requirements, you should take it as a clue that the team is working with a poor foundation. Pensyl says, "Project truths transition from being based upon factual evidence at the beginning of the project, to truths and decisions being based upon perceptions and reaction as the project progresses. The only untruth at the beginning of the project is and was the marketing promise date. All else at the beginning was truth based upon fact at that point. A promise date should never be issued without proper estimating. All project teams should be given equal credibility for their estimates."

If you want the software requirements process to improve, says Pulley, attach a reward to doing so. He suggests that CIOs find a way to tie a very large bonus percentage to the quality of the delivered application, six months after the release. "People are dollar motivated," he points out. "If you incent people to deliver by a given date, with few penalties for quality, then the application shall be delivered by that date. Make the pool substantially large. Place a small percentage of the bonus pool on the delivery date. Allow product support to draw from the bonus pool. If the project meets the date, but delivers a poor quality product, then the bonus pool will disappear. If, on the other hand, the application date slips, but the resulting delivery is rock solid and requires only a small amount of support beyond training, then the bonus pool should reward greatly."

Perhaps you can’t achieve telepathy with your development staff. That may be beyond our current level of technology. But if you put these five techniques into practice, your developers may be fooled into believing that you can, indeed, read their minds.

Related:

Copyright © 2007 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Get the best of CIO ... delivered. Sign up for our FREE email newsletters!