4 Steps to Getting a Head Start on Requirements Elicitation

Consider this scenario: You’ve been charged with introducing a new Information System to support the work of inexperienced stakeholders. Some are inexperienced on the job while others know very little about the technology, opportunities and constraints related to the new information system. In this scenario, techniques such as interviews and workshops (event-based elicitation techniques) may not yield sufficient results. If the new system is being designed to assist experienced employees or improve the performance of stable processes however, one can expect requirements to be accurately supplied by the employees.

Consider a second scenario where your objective is to introduce innovation or organizational change. Engaging users on something they’ve not experienced before may not produce a full view of their requirements from the onset.

So, what exactly is the best way forward? Where else can analysts explore to get the right requirements?

1. Similar Systems in Other Organizations

Unless it’s a completely new idea, there are likely to be systems in other organizations that can be studied to extract requirements. Analysts should however, not limit themselves to exploring only the systems in their industry. For example, an analyst working on the development of a reservation system for a car rental company may have something to learn from a hotel reservation system, which is in a completely different industry.

2.  Standard Software Solutions

Existing software packages in the market often incorporate typical information requirements that suit a diverse set of users. Examining standard and relevant solutions in the market can help capture “typical” requirements that can be customized to suit the analyst’s environment.

Regardless of whether the plan is to buy software off-the-shelf or build in-house, requirements elicitation and analysis should still be approached rigorously by studying standard software solutions.

3. Description of Similar systems in Books and Other Publications

Information Systems and their features are often well documented in literature. For example, publications on ERP systems, forecasting systems and POS systems can provide an inventory of requirements to be confirmed with users. Though re-inventing the wheel is unnecessary in most cases, it’s critical for the analyst to take note of the unique requirements of each project and specify them accordingly.

4. Existing Systems Within the Organization

In some cases, the analyst may find that there are existing systems similar to the one being proposed within the organization. Such systems can be studied as they can provide a useful starting point for generating ideas on how the new solution should work.

Existing procedures and processes that the new system will replace may be completely manual or may be a combination of manual and automated steps. Such processes or systems can be studied through document analysis or observation after which they can be fully automated, wherever it adds value.

In cases where the analyst wishes to move beyond the mere automation of manual tasks to redesigning processes and innovating products and services, such techniques become less useful. For such situations, the analyst may skip analysing the way things work presently to focus on understanding the information needs of that part of the organization where the new Information System is expected to work.