Some days, you wish you had telepathy. You just know that your development staff is holding back in some way, but you don’t know how to get them to communicate. Is the project in trouble, but they’re afraid to tell you?
Since your software development staff won’t tell you what they’re really thinking, I asked them to confide in us instead. I posed a single question to professional programmers and testers: If you could get your CIO to understand just one thing about software requirements, what would it be?
From the answers, I collated the five things at the top of their minds. If you grok these concepts, you will win the respect and support of your programming department (prizes you’ll also earn for understanding the term “grok”), and you’ll optimize the chance of success for your next software project.
I must warn you that this will shock some developers. Most of them don’t expect you to have a clue.
1. The Inconvenient Checkbox: Understand the Role of Requirements
Many development projects are handicapped from the start. The requirements are vague and subject to interpretation, require intimate knowledge of the business to interpret correctly, and aren’t prioritized. “It’s a classic garbage-in, garbage-out situation,” says James Pulley, director of professional services at PowerTest.
“Poor requirements are provided to a development organization that either does not question them or receives hostile glares from the business community when clarification is sought. Items requiring insight or interpretation are interpreted one way by the requirement writer, a second way by development, possibly a third way by QA.”
It’s critical to establish some sort of process for documenting software requirements—what one developer plaintively described as avoiding an ongoing guessing game. Yet, say many developers, managers often forget why they gathered the software requirements in the first place. QA tester Darrel Damon complains that some organizations act as though requirements are “an inconvenient checkbox that has to be gone through for legal purposes.” In one project on which he worked, for example, management paid little attention to maintaining and updating the requirements. “It was as if the requirements checkbox had been checked, so we could move past requirements.”
2. Don’t Throw It Over The Wall: The Right People Should Define the Requirements
You want software requirements that help the development staff create an application that gives the user joy. To achieve that goal, you need to get the right people into the room. Many corporations depend on a business analyst to elicit information from the user, to document it in a company-approved way, and then to throw the paperwork over the cube wall to developers who rarely (if ever) interact with the people who will be using the software.
Instead, says developer Dave Nicolette, “CIOs should use business analysts in a role more in keeping with the job title: to analyze business processes and identify opportunities for improvement. … On software development projects, business analysts should not get between the customers and the developers. When they do, they only cause confusion.” The most important person in the requirements-gathering process is the user.
Daniel Corbit, senior software engineer at CONNX Solutions, says, “Software requirements are not dictated from the top; they are gathered from the bottom. If they do not model the real-life business process of how a company does its work, then they are doomed to fail in execution. … The key part of the equation is to carefully interview everyone who uses the tool and everyone who will be impacted by the tool to find out what it needs to do.”
Put the person who will use the software in the room with the person who will create the software—which you may note is also a foundation of agile software development. Find out what the user needs to accomplish. This doesn’t necessarily mean that you need to define what each screen looks like. Carlton Nettleton, a software developer and agile coach, points out that “meeting a series of requirements is not the same thing as meeting our customer’s goals. Tell me what the customer’s goals are; even better, bring the customer in and he/she can tell me in person. We can then figure out what types of requirements are needed. Then, when we are ready to execute, let us plan around our customer’s goals, not around the requirements.”
However, this isn’t a one-time visit. The stakeholders have to get and stay involved. According to Ellen Gottesdiener, principal consultant at EBG Consulting and author of The Software Requirements Memory Jogger and Requirements by Collaboration, it’s important for the CIO to ensure that technical and business communities collaborate on requirements, early and often. The classic approach is to throw a Marketing Requirements Document over the wall. Instead, she says, “A bridge must be built, to collaborate between technical and IT stakeholders. Get personally involved in this effort. Find out what works in your organization to actively and productively engage customers in requirements development.”
Gottesdiener offers a real-world example. A project started, ran and failed three times. The organization tried internally once; then it outsourced it; finally it tried again internally with another IT manager. From the start, Gottesdiener explained, the business sponsor was disengaged, and participation by the users and business experts was sparse. But the solution was necessary, for both business and political reasons, so the organization decided to try again. This time, however, it conducted a retrospective to examine the project in a deep and significant way; both product and process were explored.
Gottesdiener says that this time around, “They see the role management has played in colluding, not sharing information, infighting, lack of transparency. They examine the frustrations of not getting users to participate in requirements development and validation. The whole story gets put, literally, on the wall in an open manner. They decide as a team what they would need to do to be successful. It involves starting with full-time customer resource for a fixed time frame, requirements workshops, reviews, prototypes and ongoing retrospectives for each milestone. And of course, management helping them make all this happen with the right people and money, at the right time.” According to Gottesdiener, the fourth time was the charm: The group delivered on time, on budget—a first for the department.
When you gather the project stakeholders, be sure to include the testing organization in the process. Performance testing expert Jim Pensyl believes strongly that testers should be involved at project kickoff. He says, “Only the testing organization can tell you if the requirements are testable. Why not then use [their] deliverables for the source of truth in status and estimation refinements?”
Developer David Gelperin agrees: “Experienced testers and technical writers should be active participants in the cross-functional teams tasked with requirements development.” This is an important time to listen to the development team’s feedback. Says Jared Richardson, author of Ship it! A Practical Guide to Successful Software Projects, “If you don’t include us on the time line generation, don’t expect us to meet the time line. If the general contractor on a building project doesn’t ask the brick mason or the electrician how much time they need, how do they expect to generate a realistic schedule? They c