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?
4
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:
- Documentation. If this system is replacing an existing system, you can find out what that system does. If you made that system, use that entire requirements specification, if you can find it. If there are competing systems out there, find out what they do. This is probably best to determine functional requirements, and you can use some data elements (like frequency of occurrence over multiple systems) to start to prioritize functionality in your system.
- Defect or Enhancement Requests. If you have access to an existing system’s defect or enhancement tracker, find out what people are asking for. This will let you find out what problems might exist, develop an understanding of what your system might do, and find a niche in the market for your application if you can deliver features your competitors don’t have.
- Laws and Regulations. If the system is intended for deployment in an environment that must conform to various laws or regulations, determine what those laws and regulations are. Those must be captured as part of your business requirements.
- Surveys and Questionnaires. Contact as many potential users as you can. Find out what they need and what they want in this type of system. Analyze this for commonalities. Be aware of conflicting requirements, however.
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.
5
- Hire an expert from the field – this will offer you a view of someone working in the domain. Even if this is only one person, it is much better than you guessing how accounting works.
- Find potential clients clients and go talk with them – this is where you sell department comes in action. They can try to go out and sell the product to a few early adopters in exchange for valuable information for you.
- Release a version with less features and listen to what users want afterwards (do iterative releases in agile style). – This is how many agile projects work. They release often and in incremental updates. They release with a restricted set of features and let the product live in the real world. The feedback from these many and ordinary users is the most valuable.
Later Edit:
- the backlog should not be prepared for the whole lifetime of the project. That is impossible, unless you are making something very simple.
- let the backlog be minimal and add to it on the way
7
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”.
1