I am working on an application to create invoices. There are some features that are required based on the type of the application and are common to all invoice applications. However, we still need to determine what unique needs the user base might have. We do not have direct access to the users to obtain requirements or user stories. What techniques are most suitable for eliciting high-quality requirements from users when direct or frequent access is not possible?
Agile Requirements – Methods of Requirements Elicitation Without Direct User Access
agileRequirements
Related Solutions
If you really want to do this right, you have to accept that there's going to be a lot of manual work. Unit/system/integration/regression testing is vital, but it'll only verify that the software works the way the tests require. Requirements traceability means that each requirement gets an ID of some sort, and that ID is traceable throughout the development process. A requirement ID has to be tied to one (or more) features, features have to be tied to a design, and designs are tied to tests. Ultimately, you can look at any part of the system and trace it back or forward. If a test fails, you can see what requirement isn't being met. Look at some code and see why it is required and what parts of the system use it. If a requirement gets dropped, you can identify what code and tests can be removed. Unfortunately, there's no good tool support for this (we had a bunch of Perl scripts that wired FrameMaker, a custom change management system and a design tool together).
The user story format is pretty flexible.
“As a (type of user), I want (some feature), so that (some goal)”
I've seen this format used successfully at my workplace. For example:
"As a System Administrator, I want copies of the product catalog sent daily to our Sales Partners so that these partners always have the most current version of our product catalog"
In this example:
A feature is defined. The feature might take the name Partner Extract, for instance. It might be implemented as an ETL job that runs nightly to create data files that are made available to Sales Partners via SFTP.
The user story embeds the roles. The two roles identified are System Administrator and Sales Partner.
Incorporating non-functional requirements is easy. The above example includes one non-functional requirement: the product catalog updates must be daily. Requirements that address how much, how fast or how often are non-functional requirements. I like to refer to these requirements as "quality attributes". Here is another example of a user story that expresses a quality attribute:
As a Call Center Representative, I want customer search to return the result in 2 seconds or less (on average) so that customers are not left waiting on the phone.
Write user stories for reliability, security, capacity or any other quality that is deemed important.
Feature Dependencies
You have identified some legitimate limitations of user stories. They are unordered and there is no guarantee they will be independent. In fact, the might be interdependent-- a chicken-and-egg problem. I believe that all non-trivial projects require documentation to supplement the user stories. I watched the agile team here at work create activity diagrams (flow charts) of the business process. These diagrams were used to analyze the feature dependencies. Another approach might be to create PERT diagram in a big all-day session with the customer. In the end, some other artifacts will be necessary to support the user stories.
Epic!
A narrative that describes the scope of a project is a good idea. There should be something like a statement-of-work or a project charter. No serious project should be without one. These documents provide a starting place for identifying user stories. These document help answer tough questions like "What should be the priority of this feature?"
Metadata
After 15 years in the business, I have an opinion about meta-data. In general, it should be avoided. A few reasons include: after a month, no one knows if it is accurate; no one knows if it was updated; it is extra work to create it; you can't predict what metadata will be useful. Most meta-data is a distraction. I like to track owner, author, priority, estimate of effort, and date of last modification. Beyond that, I fight hard to keep meta-data out user stories and use cases.
Benefits (so that...)
I have an opinion about this as well. :-) Including the benefits is vital. Often, users will request a feature without having though about its value. No matter how good an agile team is, the project will fail if it implements unimportant stuff at the expense of more critical functionality. Also as a developer, I do a better job coding a feature if I know how it fits into the big picture. Here is a real-life example of a requirement without justification: "The system shall prevent transactions with EIP and a gift card from occurring.". Huh? What is EIP? Why do I care? Why does anyone care? I don't know. Understanding the context would have been helpful before I went to the business analyst for clarification.
Even worse is when no one remembers why the user story was written. Do we still need this one? Has the business process evolved to the point where this user story is invalid? Does anyone know? These conservations waste time. It gets suckier if the the author of the user story has left the company.
Measurement
Here is an example of user story that is not measurable:
As a Call Center Representative, I want the system to be fast so that customers are not left waiting on the phone.
How fast is fast? A millisecond? A tenth of a second? Ten seconds? Nobody knows. Nobody wants to be wrong so no one every even makes a guess.
Compare that user story to this one:
As a Call Center Representative, I want customer search to return the results in 2 seconds or less (for average daytime call volumes) so that customers are not left waiting on the phone.
This user story is testable. Average day time call volume can be determined from log files. Performance testing can be conducted to determine if the requirement has been met. Even better, the users and developers have agreed on the success criteria well in advance of the end of the project. Testable requirements are a beautiful thing.
Best Answer
When you don't have frequent two-way communication with potential users, getting requirements done right becomes more difficult. The first thing that I would do is to find some kind of domain expert to use to help refine and clarify any requirements that you have and to answer domain-specific questions that might come up in requirements and design activities. This person might not be representative of your user base at all, but at least they have knowledge that you can use to make informed decisions in the absence of user contact.
Following this, there are a number of requirements elicitation techniques that you can use to actually gather requirements:
Something to keep in mind is that there might be a number of different classes of potential user, each with different expectations. It might not be possible to fully satisfy the requirements of each one. In fact, some requirements generated by people of different user classes might even be in conflict, meaning you can't actually satisfy all of them in a given application.
You also tagged this question with the agile tag. One of the tenants of the agile methods is to be able to release quickly. If you can build a system and find early adopters to use it, you can then build up your own set of customer requirements through your defect and enhancement tracking system.
The two oft-cited resources for requirements engineering are Software Requirements and More About Software Requirements: Thorny Issues and Practical Advice, both written by Karl Wiegers. Although I've never read them, I also understand that Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise by Dean Leffingwell and Writing Effective Use Cases by Alistair Cockburn are highly recommended in the agile community.