3 of 3 added 1130 characters in body

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.