Working in a large organisation, it is often the case that the members of the development team are not able to get direct access to the client to gather requirements. Is it possible/advisable to give a list of questions to an account manager so that they can gather requirements on your behalf?
Requirements – Can Non-Technical Staff Gather Requirements for Development Team?
Requirements
Related Solutions
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.
Infrastructure details are called "non-functional" requirements. It's a weird term describing those requirements that are not visible to the end-user, but are still necessary for the application to function properly.
However,
The application shall provide a mechanism for allowing the user to change his password
and
The user session must time out after 30 minutes
are not non-functional requirements, and they are not obvious. Always capture such requirements, and put them in your requirements matrix.
Best Answer
Possible: yes :-)
Advisable: only if there is really really no other way. This would easily result in very brittle, poorly understood requirements. And the problems may only appear at a later stage, during implementation or acceptance testing.
Requirements gathering ideally should be a series of detailed discussions between client and developer(s). Clients usually have very faint ideas of what they really want, thus implementing their first vague decription as is would almost inevitably lead to problems. So the developers should be able to tell the price of each idea/story/requirement, which helps clients prioritize their needs, and give technical feedback on what's possible and feasible. Also, they should understand the problem domain as deep as needed, in order to provide the best technical solution to the client's problem. And all along the way, they must ensure they understood the client properly, which means frequently asking back for clarifications and repeating what they understood with their own words during communication sessions (and frequently providing UI prototypes/mockups of client ideas). The best medium for this is oral communication - if it is not possible face to face, a video or phone conference is the next best option.
Having a nontechnical person as a communication channel between clients and developers severely limits the efficiency of communication. Even sending documents back and forth by e-mail would be better, where there is at least no intermediary, so there is one less possibility for misunderstanding.