Software requirements development: FAQ

What kind of mistakes? Giving up on requirements development before application features are fully specified. Defining unnecessary features that aren't tied to business goals. Failing to keep business members of the team engaged long enough to sign off on the final specification. "Processes that require human input are never a walk in the park," noted requirements expert Mary Gorman, an associate with EGB Consulting, in Sudbury. Mass.

This FAQ explains the challenges of requirements definition, and provides practical advice to help business analysts, project managers, developers and testers build better requirements -- resulting in better software that serves business needs effectively.

What is the difference between "requirements elicitation" and "requirements gathering"?

These terms mean essentially the same thing. But requirements elicitation is preferred because it more accurately describes the challenging, back-and-forth conversation that must take place among stakeholders to specify an application's needs effectively. By contrast, requirements gathering suggests that requirements are fully formed and ready to be discovered, which, of course, is not the case. The idea that software requirements development is a simple, linear process is part of an outdated mindset, where "you ask people what they want and then build an application with the requested features," noted James Hulgan, who works for requirements consultancy Seilevel in Austin, Texas. Even though software requirements professionals are transitioning from a requirements-gathering mindset to a requirements-elicitation approach, Hulgan still encounters business analysts who were "treated like and trained to be secretaries -- they ask project managers what the app needs to do, write it down and hope it sticks."

What are some techniques for developing fully formed requirements?

If the feature doesn't correlate with a business goal, it's not worth developing.

Two useful techniques, said Nancy Nee, are to "dig deeper" and to "make sure you understand the application stakeholder's definition of success." Both sound deceptively simple, which leads some software pros to believe they have successfully applied these techniques by asking a question or two. But too often that's not the case, said Nee, who is vice president of global product strategy for ESI International, an Arlington Va. consultancy. Requirements typically are not specific enough, she said. In "Writing requirements: Common sense measures for success," she shares advice on avoiding vague requirements. For instance, when business stakeholders explain what they want an application to do, Nee says, the trick is to keep asking questions. "It's common for them to say, 'Honestly, all we need is access to these reports so we can generate our own status report.'" That's the beginning of the requirements conversation, not the end. Digging deeper entails asking questions like these: How quickly do you need the information from the report; do you need to generate the report every month; if so, on what day of the month? To make sure you understand the stakeholder's definition of success, Nee recommends saying something like this: "So if you have the report no later than 10 a.m., on the 20th day of each month, would you agree we have been successful with the requirement?'" If the answer is yes, document the stakeholder's agreement. If not, go back to the drawing board, she said.

How do you get high-level business executives involved in requirements?

Scott Sehlhorst

Understanding and applying the right requirements elicitation techniques won't do a lot of good without the right people in the room. Getting senior executives engaged in requirements is hard work, according to Scott Sehlhorst, founder of software services firm Tyner Blain, in Austin, Texas. The most common reasons executives are reluctant to get involved are: 1) they are too busy and your product is too low on their priority list; and 2) they do not appreciate the importance of their participation, Sehlhorst said. In "Convince executives to be a part of writing business requirements," he offers tips on removing those barriers, including this one: "Your best bet is to try and get fifteen minutes of their time, or get them to delegate responsibility for decisions about your product to someone who has more time or fewer responsibilities. Then, go in with an outline showing your understanding of the company's goals and show how the specific goals of your product support the bigger picture."

Another common mistake software teams make in dealing with business executives? They make it difficult for them to sign off on projects. They hand executives a 600-page document and ask for their stamp of approval, said David Nyland, CEO of Blueprint Software Systems, in Toronto. No executive has time to wade through that document, he said. A better solution is present only those pieces of the project that are relevant to that particular executive, he said. He also recommends taking a visual approach, depicting key information in charts and other graphics.

What is best way to determine the appropriate feature set for the application under development? 

One reason software development projects run over budget and get delivered late is that they include features that aren't necessary, Seilevel's Hulgan said. To avoid requirements creep he recommends a ruthless approach. Every feature defined during requirements development must be traced back to a business objective. "If the feature doesn't correlate with a business goal, it's not worth developing," Hulgan said. "If your business objective is to raise revenue for a certain department, then you ask, 'How does this feature support that goal?'"

At what point in software requirements development should testers get involved?