Software development teams struggle to accurately define application requirements at the outset of a project. Three tactics for getting better requirements are using LinkedIn, relying on visual aids and strictly adhering to business objectives, according to James Hulgan of product services consultancy Seilevel in Austin, Texas. Here are his five steps to building better requirements:
Step 1: Use LinkedIn to track down the people you need to talk to.
Social media sites don't offer much help in defining project requirements, Hulgan said. But LinkedIn, in particular, is helpful for tracking down the people you need to talk to as part of the requirements elicitation process. "In the initial stages of requirements, you get a list of people to contact, and it takes time to find them and set up appointments," said Hulgan, who estimates that this task consumes 20% of his time. "Any tool that makes me more efficient I like."
You have to take a step back and constantly set and reset priorities in order to define the features that deliver the most value.
In the past, he relied largely on the company Outlook directory. But he prefers LinkedIn because of the additional information it often provides. "People list their areas of expertise, the projects they have worked on," he said. "You can look and see if this person really is the right contact for requirements elicitation."
Sometimes he finds that the name he's been given is not the best option. "When you look at that person's connections, you find a better choice." Another useful LinkedIn technique, he said, is to request an introduction. "Some people are hard to nail down. So you go through their connections, see who you know and try to reach them through a mutual connection."
Step 2: Elicit, don't gather, requirements.
Defining application requirements effectively is challenging, and Hulgan said beware of tools or techniques that claim to simplify this complex process. He has worked with clients who have said, "Here's our template for requirements -- just fill it in." But that approach does not work. "You can't just ask people what they want and then build an application with the requested features."
Even though software requirements professionals are transitioning from a "requirements gathering" mind-set to "requirements elicitation" approach, Hulgan still encounters traditional business analysts who were "treated like and trained to be secretaries," he said. They ask project managers what the app needs to do, write it down and hope it sticks.
Step 3: Map the project features to the business goal.
A key reason software development projects run over budget and get delivered late is this: They include features that aren't necessary. "Every feature you define must trace 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?'"
If it doesn't, get rid of it, he said. "You have to take a step back and constantly set and reset priorities in order to define the features that deliver the most value."
Step 4: Don't just tell -- show.
One of the most effective ways to fill in the gaps and complete the application requirements elicitation is to take a visual approach, said Hulgan, whose Seilevel colleagues Joy Beatty and Anthony Chen authored a book on the topic: Visual Models for Software Requirements. "When you give people a picture to look at, they can tell you what is missing, what you need to talk about."
Presenting information visually is a powerful way to engage people, he said. He recommends mapping out these elements: organizational charts listing the systems involved in the application, data flow diagrams, a feature tree and a business objective model.
Step 5: Get developers to poke holes in your plan.
Developers play a key role in defining requirements, Hulgan said. Once the app's basic requirements are established, bring developers on board and get them to critique your plan. "The best developers ask a lot of questions, such as 'Why are we doing this?'" Don't look at them as naysayers, he said. The goal is not to seek their approval. It's to get a reality check on what you have come up with so far. "Silence from developers is a bad thing."