If you are an Enterprise Architect or a Solutions Architect in a company that is lacking a requirements department then you have probably been in the situation where you had to go hunting just to get the requirements for the system.

Then once you’ve managed to get some requirements you have to try and make sense of it all. There are lots of ways to tackle this situation and some evade it completely.

The purpose of gathering your stakeholders for brainstorming is “to produce numerous new ideas, and to derive from them, themes for further analysis. If you brought an assistant analysis with you, during the session they should try to secure a representative from each participating stakeholder group in the brainstorming session.

Also if they are serving as facilitator of a brainstorming session, they must ensure that while participants feel free to propose new ideas and solutions, they remain focused on the business need at hand and do not engage in scope creep, gold plating, or become distracted with other business issues. All ideas must be recorded so that they are not lost. Typically, the brainstorming method is used if your project has no clear winning choice for a solution, or if existing proposed solutions are deemed inadequate.

Document analysis involves gathering and reviewing all existing documentation that is pertinent to your business objective or that may hold data related to a relevant solution. This documentation may include, “business plans, market studies, contracts, requests for proposal, statements of work, memos, existing guidelines, procedures, training guides, among others. In other words, virtually anything that is written related to the project may be useful.

This type of elicitation is especially useful when the goal is to update an existing system or when the understanding of an existing system will enhance a new system. However, document analysis alone is rarely enough to thoroughly extract all of the requirements for any given project.

Focus groups consist of a mix of pre-qualified stakeholders who gather to offer input on the business need at hand and its potential solutions. Focus groups are particularly helpful when key stakeholders are not particularly imaginative or forthcoming. Focus groups are also a good way for time-pressed analysts to get a lot of information at once. They may be conducted in person or virtually.

An interface analysis carefully analyzes and deconstructs the way that a user interacts with an application, or the way one application interacts with another. A thorough interface analysis will describe the purpose of each interface involved and elicit high-level details about it, including outlining its content.

This one is my personal favourite as it is the most practical if you do not work for a large corporate company. One-on-one interviews are among the most popular types of requirements elicitation, and for good reason: they give you the opportunity to discuss in-depth, a stakeholder’s thoughts and their perspective on the business need and the feasibility of potential solutions. Research shows that interviews are the most effective way of eliciting requirements.

Whether an analyst chooses to have a structured (with predefined questions) or unstructured interview (with free-flowing, back-and-forth conversation), they must fully understand the business need in order to conduct a successful interview.

Observation is quite helpful when considering a project that will change or enhance current processes. There are two basic types of observation are available to an analyst:

(1) passive observation, where you just watch someone working but make sure not interrupt or engage the worker in any way, and
(2) active observation, where you ask questions throughout the process, get a strong understanding and even attempt portions of the work.

Prototyping is especially valuable for stakeholders such as business owners and end users who may not understand all of the technical aspects of requirements, but will better relate to a visual representation of the end product.

Stakeholders often find prototyping to be a concrete means of identifying, describing and validating their interface needs.

The prototyping process is normally iterative, improving as more input and evaluation are gleaned from stakeholders.

Prototyping may be an interactive screen (normally consisting of hypertext only with no real data behind it), a mock-up (such as a PowerPoint), a navigation flow (such as a Visio diagram), or a storyboard. Simple, throwaway prototypes (such as pencil sketches) may be done in the initial stages of discovery, and more detailed, interactive prototypes may be done once business requirements have been identified.

At the latter, more detailed prototype stage, prototype features must fulfil previously identified business needs as outlined in the requirements.

These investigation methods help you elicit relevant information for most type of I.T. projects.