Discovering exactly what users, stakeholders, and sponsors want you to create is often the most difficult part of an IT project.
Communication between IT experts and nontechnical clients can be fraught with misunderstanding and misinterpretation. As I discussed in previous columns, users often don't know what they want until they see it, and they frequently can't articulate their expectations in language that IT experts use to design systems.
Technicians often frame their requirements questions in technical language, such as, "Must it work in a browser?" or "How will the data be validated?" and clients may not have the technical background to respond to these questions. Users often explain their expectations in vague language, such as "fast" or "responsive", which lack the specificity designers need to develop solutions.
Volare Requirements Specification Template
The IT community has submitted many ideas to solve these problems. The Volare Requirements Specification Template, created by James and Suzanne Robertson, authors of the book "Mastering the Requirements Process", is one example of a tool developed to aid system professionals in deriving user requirements.
This template, which has gone through 14 versions since its inception, offers a thorough set of specification categories, from concrete components such as "Goals of the Project" and "Implementation Environment of the Current System" all the way to highly subjective ones such as "Cultural Requirements". The template also includes technical elements such as "Speed and Latency Requirements" and "Data Model".
I've often recommended the use of this template to students and clients I counsel, as it brings discipline and consistency to their requirements efforts. In my years of recommending and training IT professionals in its use, however, some of its limitations have become clear. Few clients will know what the terms "Speed and Latency Requirements" or "Data Model" mean, so expecting them to be able to define those expectations is an exercise in futility; also, expecting clients to define "cultural requirements" or "political requirements" borders on the hallucinatory.
The expectation is that experienced IT professionals can elicit this information through clever questioning and facilitation, but, in my experience, the number of IT pros who have a deep understanding of cultural or political dynamics within an organization is, to be charitable, limited.
UML and Use Cases
Other methods of defining requirements, such as Unified Modeling Language (UML) and its associated Use Cases, use natural language and simple graphics to document user-described system interactions and activities.
Use Case diagrams captured in UML can get quite complex when describing large systems. The result can be baffling and undecipherable to nontechnical users and managers.
User stories
Some agile proponents, such as Alistair Cockburn, advocate a Use Case model for documenting requirements in agile projects, but Mike Cohn, author of "User Stories Applied", supports user requirements with even less formal structure. Cohn calls these short, pithy descriptions of a system capability or function "user stories".
The use of the word "story" is telling; rather than asking a user to describe the "speed and latency requirements" of a system, we ask them what tasks they plan to do when they sit down at the keyboard. In keeping with the "barely sufficient" concept of agile documentation, user stories are short and written in plain English as a simple narrative.
So, for instance, a project sponsor asking us to develop an online job site would tell us the following stories about how different users might interact with their proposed system:
- "As a jobseeker, I can search for jobs."
- "As a company, I can post job openings."
- "As a jobseeker, I will search for jobs by attributes like location, salary, title, company, and posting date."
- "As a jobseeker, I will drill down to more info on selected jobs."
- "As a jobseeker, I will learn more about the company posting the job."
User stories used in agile environments have no formal structure. If the user community can visualize how they intend to use the system and describe that in simple English, the resulting stories give the agile team someplace to start. Since agile theory contends that users must see something before they can start to visualize the complete system in detail, starting with a simple set of stories kicks off the collaborative process of experimenting towards a solution.
As Cohn reminds us in his book, there's another reason for applying the user story technique--it forces the customer to remain engaged throughout the process. While a huge, comprehensive requirements template like the Volare Spec can collect voluminous specifications up-front, it also enables the sponsor to look at requirements as an opening phase he can walk away from once "the requirements are done".
Since the user story approach requires constant refinement and builds upon itself from prototype to prototype, there's no other option but engagement for the sponsor.
Conclusion
User stories connect with the philosophical threads of agile methods by reminding us that we don't need formal templates or special graphical languages to have a conversation with the customer about what they want. User stories reinforce the "barely sufficient" mindset that keeps us from being diverted into low-value administrative tasks.
Most importantly, user stories help us stay engaged with the customer throughout the project, and require that the customer do so as well. The conversations that ensue from that collaboration are the core of agile engagement.
I've just grazed the tip of the iceberg regarding user stories. In future columns, I'll discuss using user stories to estimate the project, and explain how stories can be used to keep the sponsor informed and educated about the project status and progress.