This article is about developing requirements. I’ve used a number of different techniques and have come to appreciate their varying characteristics and how they can be used to advantage for different project needs.
The Illuminati Approach
Likely the most common method for developing requirements I’ve seen is what I’d call the “Illuminati” approach. In an Illuminati approach, a small cadre of senior people writes a requirements document and sends it off to the rest of the team. This can be fast and effective, providing all those senior people are actually able to speak to the complete scope of the project and find the time to do so. In practice though, my experience has been that this approach is neither particularly effective nor fast - partly because neither of those provisos tends to pan out. Beyond that, because so few people have been involved in the requirements development process, the eventual review and acceptance of the requirements will take quite a while. Similarly, this approach does a pretty poor job of informing everyone who needs to understand the requirements because most of them will only get the document - they won’t have the deep understanding of those who actually participated in developing the requirements development.
At this stage in my career, I’d be hard-pressed to use this approach.
Joint Application Development
The first game-changing process for requirements development I came across was Joint Application Development (JAD). JAD is more of a set of methods than it is a rigidly defined procedure in my experience; nevertheless, I should take some time to outline what we meant when we spoke of JAD for requirements development because people, in my experience, are rarely talking about precisely the same thing when they refer to JAD. In particular, the technique I’ll describe does not develop screen mockups or any other design artifacts but is rather solely focused on developing requirements.
Our JAD process starts off with a chartering session. Management and project leaders come together to develop, in real-time, a charter for the JAD. The most important things that get decided at that meeting are as follows:
- They agree, in rough measure, what the main features of the product will be.
- Perhaps more importantly, they agree what major features will be out of scope.
- They assign a JAD facilitator to run the sessions—ideally also a scribe.
- They define a core team including product management and senior development people, who will attend every JAD session. This core group should be 3-5 people and will provide leadership and continuity to the requirements development effort; in a Scrum context, the Product Owner would be the most important member of this team.
- For each major theme in scope, they figure out what other Subject Matter Experts (SMEs) should be involved and plan JAD sessions for each theme, taking care not to have more than 7 +/- 2 people in any one session .
- They agree on the schema to use for the requirements. Typically, these are fairly comprehensive and include things like description, priority, pre- and post-conditions, performance requirements, and other non-functional requirements, affected user roles, scenarios, constraints, and so on.
- Not necessarily in the charter session itself but in advance of the first JAD sessions, they develop a context diagram. A context diagram shows the product in its context of use with all major interactions depicted; one way we use it is to assess the “done-ness” of each theme-specific JAD session.
- Similarly before any JAD sessions are held but not necessarily in the charter session itself, they define user profiles that are relevant to the requirements themes. These too are used to help assess done-ness of the JAD sessions. From there, we get started with the theme-specific JAD sessions. Each of those works like so:
- In advance, the facilitator works with the core team to sketch out an agenda of topics relevant to that theme down to a roughly 15-minute granularity.
- At the JAD session, the facilitator, scribe, core team, and invited SMEs meet and collaboratively develop the requirements proposed by the team in real-time.
- The facilitator uses the agenda to move the discussion along.
- As each topic is discussed, the facilitator helps the team decide how it wants to phrase the requirement and the scribe captures the content in the agreed-on template.
- All of this is done in real-time with the document projected for all to see as it is being developed
- The invitees use the agenda, context diagram, and user profiles to assess whether or not they’ve said everything they need to about each theme by asking, “Have we addressed everything we need to about this theme with respect to each interaction and user type?” and “Have we covered everything we planned to?”
Once all scheduled JAD sessions have been completed, the core team refines the document and sets priorities in light of the complete set of requirements. Lastly, a review of the requirements is done. The review is normally pretty painless because most of the reviewers have been directly involved in the authoring of the requirements. In a Scrum context, the Product Owner drives this work and the ultimate deliverable is the initial Product Backlog. Certainly there’s no reason to believe the requirements are “final” at this point – but they would be solid enough to use as the basis of a release plan, for example. The strengths of this process are pretty broad and, overall, we are pretty happy with it. The buy-in on the requirements is much, much higher given the high level of involvement from the wider set of stakeholders. Similarly many more people being exposed to the requirements development process means that, across the team, there is a much deeper understanding of the requirements. The collaborative nature of the requirements development work also builds in a free-form, continuous review of the requirements similar to what pair programming does for code, ultimately leading to better requirements earlier. Lastly, the proactive planning and involvement of all relevant SMEs helps the team build both more correct and more complete requirements.
For waterfall/plan-driven/”Big Design Up Front” projects, this is the method I’d prefer for requirements development. That said, it’s been a long time since I was involved in a project like that. Even on agile projects, though, I could see using a process like this for collaborative, iterative Product Backlog grooming and refinement if the team preferred it. Or I can envision using this process to develop tests instead of requirements, using the Product Backlog’s stories as a basis. This would come to resemble a well-planned, structured approach to Acceptance Test-Driven Development.
The main weakness of the process is its performance—the JAD sessions take a while. Some of this is just perception. It feels longer because so many people are involved. But the truth is, it can take a while. The expense of a process typically scales with the number of people involved. In my experience, with a reasonably comprehensive schema of requirements attributes to consider for each requirement, we were doing pretty well to develop four requirements an hour. Much of that is due to the serial handling of each requirement—the group proposes it, the scribe records it, the team reviews it, and then we move on to the next requirement. Sometimes the tension in the room can be almost palpable as people grow impatient waiting to talk about specific topics that are near and dear to their hearts. Given that you’re normally looking at your best and brightest involved in these sessions, people can and do complain about the dent the sessions put in their schedules. Also it’s typically tough to do more than one two-hour session per day, mainly because people tend to lose focus in long meetings but also because two hours is about the limit people can accommodate given all their other responsibilities. Now don’t get me wrong, this is all very much time well spent. Steve McConnell notes in Software Estimation: Demystifying the Black Art that the two factors most correlated with project schedule or effort are requirements analyst capability and product complexity, so there’s little doubt that the investment in requirements called for in the JAD process will be repaid in spades. But even with that noted, if there were a way to make the process a little less expensive, I think it would go a long way towards making it more appealing to the people involved.
A set of colleagues and I participate in a software development study group. We get a book and read a bit of it at a time, getting together in between to discuss what we’ve read. It was at that forum that I first came across User Stories Applied by Mike Cohn. An awesome read, this - we did a Net Promoter Score on it when we finished it and it scored 54%, which is excellent. Reading it put me in mind of something I heard McConnell say once about Extreme Programming Explained by Kent Beck—that he loved how confidently prescriptive it was. Cohn’s book is like this as well. He’s sharing stuff that he knows works. There are lots of little changes you might want to make here and there to suit your specific needs, but at the end of the day, he’s pretty sure that you’re not going to go too far wrong if you just do what he’s saying. That assurance jumps right off the page.
Now I won’t go into detail on what a user story is in this article—there are other resources to consult to learn that but for the purposes of this article, the main thing I should point out is that a user story is intended to be much less detailed and precise than the requirements schemas discussed above. The details of the story are deferred until the user story is actually about to be developed. Even then, the details are intended to be developed in face-to-face discussions and may only really be captured in tests. So the detail that the JAD process outlined above isn’t developed upfront but rather is plumbed only when the team is just about to use that information.
The approach Cohn presents works as follows. Note that I’m not giving it to you in gory detail here but rather calling out the salient points that will motivate comparison.
There’s a session to develop the user roles (the expected types of users who will interact with the system) involving the facilitator, customer(s), and the development team.
- At it, everyone works in parallel, writing roles on cards, saying their role names aloud and taping them to a wall.
- When people have run out of ideas for roles, the participants merge them by putting potentially overlapped roles physically on top of one another.
- The facilitator helps the team determine, for each set of overlapped cards, whether or not they really need to be merged into one role or not and what the resulting roles should be .
- Finally, descriptions for each role are developed involving any interesting or useful attributes desired by the team (for example, level of expertise of the role, frequency that they would use the software, and so on).
With respect to developing the user stories, Cohn presents a number of techniques: interviews, questionnaires, observation and story-writing workshops, but he notes that the latter is “the most effective way to quickly trawl for stories.” His user story workshop involves these steps:
- Develop a low-fidelity prototype that maps high-level interactions with the envisioned software.
- Refine the prototype on the fly during the workshop as the participants determine what they think users will want to do with the software.
- For a “green-field” application development project, start with an empty box labeled as the main screen of the application. consider one of your roles, and ask “what should this person be able to do from the main screen of the application.”
- Capture the resulting discussion as both the user stories and a mapping of them to the emerging application architecture.
- As the discussion continues and a broader picture of the stories emerges, encourage the group to split the application into new views to allow the stories to be organized sensibly.
- Identify new stories using leading questions, such as, “What would the user want to do next?” “What additional information could the user need at this point?” and so on.
We borrowed a bit from Cohn’s user profile session and the JAD approach described earlier in developing our requirements. That said, what we do is very solidly based on Cohn’s techniques:
- Define themes of requirements. In user story terminology, these might be called epics. We do this in the same chartering exercise detailed above in the JAD discussion.
- Take care to invite the right people to each theme discussion: Product Owner, SMEs, and team members.
- Refine the agenda if needed to identify sub-themes to further focus the discussion.
- Turn the participants loose on a theme or sub-theme. Tell them to write stories on sticky notes as fast as they can, reading them aloud as they go.
- When they’ve run out of ideas, they review the set of stories and put stories on top of one another if they believe they are candidates for consolidation.
- The facilitator then helps the team decide how to dispose each pile of stories—leave them separate or consolidate subsets of them into new stories.
The first time we tried this, we spent 90 minutes developing and consolidating stories and finished with 20 stories. This was much, much faster than the JADs we’d done previously. The second time we tried this, we developed 12 stories in 45 minutes. Again, much faster than we’d seen previously—not surprising given the parallel nature of the story authoring and the reduced detail expectations inherent in stories. Still, when all is said and done, this is a good way to develop requirements quickly on an agile project.
We were happy with the performance of this process, and the people involved enjoyed it. I think this would be my opener in any future requirements development work on agile projects. I hope it proves helpful to you in your work also.
I’d like to thank Jon Tarry both for being my collaborator on the technique described below and for reviewing this article.