What is Requirement ?

The IEEE 610 standard defines a requirement as:

• (1). a condition or capability needed by a user to solve a problem or achieve an objective;
• (2). a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents;
• (3). a documented representation of a condition or capability as in (1) or (2)

The elicitation of requirements is an early but critical stage in the development of a project, involving many activities, with multiple techniques to capture the requirements of stakeholders in a project.

What is Requirements Elicitation?

Didar Zowghi and Chad Coulin define Requirements elicitation as the process of learning and understanding the needs of users and project sponsors with the ultimate aim of communicating these needs to the system developers. It involves uncovering, extracting, and surfacing the wants of the potential stakeholders.

Tip: Gathering a few extraneous requirements initially is always better than gathering less.

The Process of Requirements Elicitation

The requirements elicitation process involves a set of activities which allow for communication, prioritization, negotiation, and collaboration with all the relevant stakeholders. The typical activities of the requirements elicitation process are the following:

1. Understanding the Application Domain –

Investigation and examination in detail of the situation or “real world” in which the system will ultimately reside. The current environment needs to be thoroughly explored including the political, organizational, and social aspects related to the system, in addition to any constraints they may enforce upon the system and its development. Existing work processes and the related problems to be solved by the system need to be described with respect to the key business goals and issues.

2. Identifying the Sources of Requirements-

1. Stakeholders -

   Represents the most obvious source of requirements for the system.

2. Users and subject matter experts -

   Supply detailed information about the problems and user needs.

3. Existing systems and processes -

   Source for eliciting requirements, particularly when the project involves replacing a current or legacy system.

4. Existing documentation

   about the current systems and business processes including manuals, forms, and reports.

3. Analyzing the Stakeholders –

Stakeholders are people who have an interest in the system or are affected in some way by the development and implementation of the system and hence must be consulted during requirements elicitation. The customer, and more specifically the project sponsor, is usually the most apparent stakeholder of the system.

4.Selecting the Techniques, Approaches, and Tools to Use -

A choice of tools are available for the customers to choose from depending on the situation, the budget and the complexity of the project. Most often requirements elicitation is performed using a variety of techniques.

5.Eliciting the Requirements from Stakeholders and Other Sources –

Once the sources of requirements and the specific stakeholders have been identified, the actual elicitation of the core requirements then begins using the selected elicitation techniques, approaches, and tools. The process also determines the future processes the system will perform with respect to the business operations. The design could examine the ways in which the system may support future requirements in order to satisfy the major objectives and address the key problems of the business.

Requirements elicitation is strongly related to the context in which it is conducted and specific characteristics of the project, organization, and environment. In practice the budget and schedule of the project has a significant effect on the process and the way in which it is performed. The structure and maturity of the organization is another attribute which determines how requirements are elicited, as will the way in which the system will interact with users and other systems.

Roles of the Requirements Engineer During Elicitation

Requirements engineers (also referred to as the systems analyst or business analyst) play a variety of roles and assume different responsibilities depending on the project, people, context and organization involved. A substantial part of elicitation involves exploring the problem domain and the requirements that are situated in that domain. Furthermore, the requirements engineers often need to perform some typical aspects of project management and maintain effective communication to the stakeholders.

Requirement engineers are also responsible for being facilitators and ensuring that participants of collaborative elicitation techniques feel comfortable and confident with the process, and are given sufficient opportunity to contribute. This role represents a significant part of the skill and expertise required by the analyst in order to perform effective requirements elicitation. When disputes in prioritisations occur during the elicitation process, the analyst often plays the role of a mediator and is responsible for finding a suitable resolution through negotiation and compromise. It is important that the analyst is sensitive to all the political and organizational aspects of the project when mediating discussions related to the system.

Requirements engineers are responsible for documenting the requirements elicited and is particularly important as it represents the production of results from the elicitation process, and forms the foundation for the subsequent project phases. Evaluation of the elicitation process and the work performed by the analyst is based on these resultant artifacts, which in will form the basis of contractual agreement between the customer and Openlabs. Analysts from Openlabs are also trained to assume the various roles of the developer community during requirements elicitation. This includes system architects, designers, programmers, testers, quality assurance personnel, implementation consultants, and system maintenance administrators.

Techniques and Approaches for Requirements Elicitation

A range of techniques and approaches described in literature and practiced in industry. The following methods and practices are the recommended techniques employed by Openlabs in ERP implementation projects:

Task Analysis-

• A top-down approach where high-level tasks are decomposed into subtasks and eventually detailed sequences until all actions and events are described. The primary objectives of this technique is to construct a hierarchy of the tasks performed by the users and the system, and determine the knowledge used or required to carry them out. Task analysis provides information on the interactions of both the user and the system with respect to the tasks as well as a contextual description of the activities that take place. In most cases considerable effort is required to perform thorough task analysis, and it is important to establish what level of detail is required and when components of the tasks need to be explorer further.

Availability: All customers - Online (English Only) Onsite (English, Europe & Asia Only) Situations: Early Stages Mode: Online (English Only) Onsite (English, Europe & Asia Only)

Joint Application Development (JAD)-

• Joint Application Development (JAD) involves all the available stakeholders investigating through general discussion both the problems to be solved, and the available solutions to those problems. With all parties represented, decisions can be made rapidly and issues resolved quickly. A major difference between JAD and other methods is that typically the main goals of the system have already been established before the stakeholders participate. Also JAD sessions are typically well structured with defined steps, actions, and roles for participants (including a specialist facilitator from Openlabs). The focus of this type of meeting tends to often be on the needs and desires of the business and users rather than technical issues.

Availability: Only large projects Situations: After initial requirements have been gathered by some other methods Mode: Online (English Only) Onsite (English, Europe & Asia Only)

Requirements Workshops -

• Requirements workshop is a generic term given to a number of different types of group meetings where the emphasis is on developing and discovering requirements for a software system. The process involves a live demonstration of the system from the perspectives of the business, and Gap analysis from actual business processes as detailed by stakeholders.

Availability: All customers - Online - International | Onsite - Europe & Asia only | Watch out for road shows and webcasts on our website Situations: If you are considering one of the technologies as a possible solution to your business.

Observation -

• The analyst observes the actual execution of existing processes by the users without direct interference. This technique is often used in conjunction with task analysis. Observation are very expensive to perform and require significant skill and effort on the part of the analyst to interpret and understand the actions being performed. The effectiveness of observation and other ethnographic techniques can vary as users have a tendency to adjust the way they perform tasks when knowingly being watched.

Availability: Only large projects Situations: Business process improvement projects Mode: On-site (English, Europe & Asia Only)

Apprenticing -

• Involves the analyst actually learning and performing the current tasks under the instruction and supervision of an experienced user. In this technique the analyst is taught the operations and business processes by observing, asking questions, and physically doing, rather than being informed of them, as is the case with protocol analysis.

Availability: Only large projects Situations: Any Mode: On-site (India/United Kingdom|Other countries - Work permits and other legal obligations to be taken care of by the customer)

Goal Based Approaches -

• High-level goals that represent objectives for the system are decomposed and elaborated into sub goals and then further refined in such a way that individual requirements are elicited. The result of this process is significantly more complicated and complete than the traditional methods of representing system goals using tree structure diagrams. These approaches are able to represent detailed relationships between domain entities, requirements, and the objectives of the system. In general one of the risks when using goal based approaches is that errors in the high-level goals of the system made early on can have a major and detrimental follow on effect, and that changing goals are difficult to manage.

Availability: All Situations: Where customer has no clear understanding of his needs. New organisations.

Scenarios -

• Scenarios are widely used in requirements elicitation and, as the name suggests, are narrative and specific descriptions of current and future processes including actions and interactions between the users and the system. Like use cases, scenarios do not typically consider the internal structure of the system, and require an incremental and interactive approach to their development. Naturally, it is important when using scenarios to collect all the potential exceptions for each step. Scenarios are additionally very useful for understanding and validating requirements, as well as test case development.

Availability: All Situations: Where there are complex business processes which are better understood by cases.

The above analysis becomes the building blocks for a successful requirement specification.

At Openlabs we ensure that our customers get the best value for money and hence requirements gathered by above methods are documented in an IEEE Std 830 compliant specification.

Read More to find out why a requirement specification is important for your project to be a success.