Where to start? That is often the first question that pops into one's head when first assigned the task of uncovering the requirements for a systems development project. Before you schedule that first requirements brain-storming session you should educate yourself first. You'll save a lot of time, uncover many of the questions that need to be asked and help ensure project success by doing a bit of leg-work.

First, find out who the stakeholders are in the project - the groups and individuals who will derive benefit from the new system. And, this is very important, find out who is paying for the project. These are the people you are going to talk to about their needs and current issues. Establish a connection and rapport with this group and ensure that there is adequate representation from all stakeholders on the project.

Second, determine the reason why the new system is required. If it is replacing an existing system what are the issues with the current system? What is the business case for the project? (i.e. what will it cost and what benefit will accrue to the organization?) What basic needs will the new system fulfill? Answering these questions will help frame the entire project and develop that overall vision for the project. In many instances these questions will have already been addressed in a business case or project charter document. If it is not, then it would be useful to establish such a document to ensure a common vision for the project.

Third, roll up our sleeves and do some digging. Uncover and research as much information as you can about the existing environment.

The new system is likely intended to replace an existing system or perhaps it is a major enhancement. Some sources of information to consider include:

• Any documentation about the current system that can be found, such as user and procedural manuals, forms for the collection of information entered into the system, samples of reports produced by the system, design and architecture documents, technical support manuals, any models (process, data, object) that may exist, etc. will yield a great deal of information about the existing system's functionality and data architecture.
• In cases where there is no (trustworthy) data model in existence then reverse-engineering a data model from the database, or the scripts that describe the database implementation, is easy to do with most data modeling tools. A model of the current data architecture will be a start in understanding the system's data requirements and it will be needed to support any data conversion requirements the project may have.
• Gaining access to the system in a test environment and learning its functions and behaviours will also help to understand what the new system must likely also support and help in understanding some of the issues with the current system.

Business models that describe the business functions your system is intended to support, should they exist, will yield a wealth of information. Candidate use cases and use case actors can be easily identified in the process flows, the business entities identified in the business model will form the basis for understanding the data requirements, the business rules become candidates for automation support, and the business model will provide a framework for understanding where the system fits in the overall business process. Should there be no existing business model then it would be wise to consider developing one as part of the project undertaking.

Researching packaged implementations that are in the same domain as the systems development project can also be a useful exercise. This will provide some idea of the kind of features your stakeholders may be looking for. This obviously becomes even more relevant if the project is to look at acquiring a packaged implementation - thus this research would be very necessary in that event.

By this point you will know who your stakeholders are and will have established a relationship with them, you will have an understanding of the major features the new system is likely required to support, and you will have an in-depth understanding of the current environment. Now you can start engaging your stakeholders and their representatives about what their needs are more fully. And you'll be able to do so intelligently, making effective use of your stakeholders' time.