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?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
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.
If your company is in the target market for such a software product, you can become your own customer. See "Eat your own dog food".