Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
what have you tried? –  gnat Oct 24 '12 at 12:51
    
@gnat: I have used some applications and talked to some guys in the field. –  metadice Oct 24 '12 at 12:59
    
@Thomas Owens : Thanks a lot for the edit. –  metadice Oct 24 '12 at 15:39
1  
Vote to close - although I understand the problem well, the main problem is the requirement for "High Quality requirements from users" followed closely by "Cannot talk to them" - making the question unanswerable. –  mattnz Oct 25 '12 at 0:09
    
@mattnz : the question is totally answerable, see Thomas Owens answer and the comments. The problem needs a different way to approach it. –  metadice Oct 25 '12 at 4:13

3 Answers 3

up vote 3 down vote accepted

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 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.

share|improve this answer
    
+1 for 'find early adopters to use it' and for nice detailed explanation. Instead of wasting time trying convincing people to get user stories, finding a few early adopters for my application and then building iteratively from there seems a good to way go. –  metadice Oct 25 '12 at 3:41
    
it would highly appreciable if you can include or point me to some methodologies and tools with some live examples(kinda like brainstorm.ubuntu.com) to better manage all these Defect or Enhancement Requests, Surveys and Questionnaires and the whole Requirements/user stories part. By the way many thanks for your kind help so far.(to keep this question alive) –  metadice Oct 25 '12 at 3:58
    
@metadice Look at most open source projects. They frequently have some kind of Bugzilla, Trac, or similar tool. Hosting companies like GitHub and SourceForge include various types of forums or defect tracking tools by default. As far as managing surveys and questionnaires, I've never used this particular technique, but there are online survey management services. The actual management and control of requirements is a very different story than eliciting them and is probably well beyond the scope of this question. –  Thomas Owens Oct 25 '12 at 10:26
    
could you please point me to some reference material or books to learn from, so that I don't keep asking stupid questions ? –  metadice Oct 25 '12 at 11:26
    
@metadice I just added links to four books, two of which I've read and can attest to and two others that I've seen highly recommended. –  Thomas Owens Oct 25 '12 at 11:58
  1. 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.
  2. 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.
  3. 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
share|improve this answer
    
Answers should provide explanation and context. What are the advantages and disadvantages of each of these options? Are there some cases in which each option might not be suitable? Can you share experiences with using any of these methods? Are there any reputable sources that provide additional details about these options that could be useful? –  Thomas Owens Oct 24 '12 at 14:16
    
These seem like reasonable, if obvious, answers to me. The three close votes and "what have you tried" comment on the question suggest that the OP could have come up with some or all of these on his own. –  Robert Harvey Oct 24 '12 at 14:42
    
@Patkos Csaba : Thanks for your answer. 1.I can't pay for an expert. I am a freelancer. 2. That's exactly what I am doing but there are very few people who are willing to talk and even fewer number of user stories. 3. That's exactly what I am planning but I want to be more prepared and informed & want to get to the position where I can create a good Product Backlog to start developing. (I hope I am clear enough and on the right track if not please correct me). –  metadice Oct 24 '12 at 15:54
    
Updated my answer, because I've seen downvotes as for lack of explanation. –  Patkos Csaba Oct 24 '12 at 15:56
    
@PatkosCsaba : I completely agree with you on Backlog point and I do understand this. But here lies the problem, if I create a very minimal application, nobody cares to even listen to me, let alone using it. Now to create an application so that someone considers it, I need to make it good up to some level, and to make it good(to some level) for those people, I need to know the requirements which they don't care to tell me. –  metadice Oct 24 '12 at 17:16

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".

share|improve this answer
    
+1. Thanks for your link. It is helpful and I'll refer to it when the need arrives. –  metadice Oct 24 '12 at 17:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.