Eliciting Requirements

Requirements Elicitation includes problem solving, elaboration, negotiation, and specification.

Collaborative Requirements Gathering

There have been numerous techniques of collaborative requirements collecting proposed.

  • Meetings are held and attended by software engineers as well as other stakeholders.
  • Preparation and participation rules are created.
  • An agenda is proposed that is formal enough to cover all critical topics while being informal enough to allow for the free flow of ideas.
  • The discussion is managed by a “facilitator.”
  • A “definition mechanism” (work sheets, flip charts, etc.) is used.

The purpose is to define the problem, offer solution elements, negotiate different approaches, and specify a preliminary set of solution requirements in an environment conducive to goal achievement. Each attendee is asked to make a list of objects that are part of the environment that surrounds the system, other objects that are to be produced by the system, and objects that are used by the system to perform its functions while reviewing the product request in the days leading up to the meeting.

The mini-specs are offered for discussion to all stakeholders. There are additions, deletions, and extra elaboration. In some circumstances, creating mini-specs will reveal new objects, services, constraints, or performance requirements that will be added to the original listings. The team may raise an issue that cannot be handled during the meeting at any time. An issue list is kept so that these suggestions can be followed up on later.

Quality Function Deployment

Quality function deployment (QFD) is a quality management technique that translates customer expectations into technical software requirements. It is focused on maximising customer satisfaction from the software engineering process.

The QFD defines types categories of requirements:

Normal requirements

The objectives and goals that are mentioned for a product or system during customer meetings are called normal requirements. The customer is satisfied if these requirements are met. Requested forms of graphical displays, specified system functionalities, and defined levels of performance are examples of normal requirements.

Expected requirements

These requirements are inherent in the product or system and may be so basic that the client does not express them explicitly. Their absence will be a major source of dissatisfaction. Expected needs include ease of human/machine communication, general operating correctness and reliability, and software installation simplicity.

Exciting requirements

These characteristics go above and beyond the customer’s expectations and are absolutely delightful when they are present. For example, software for a new mobile phone has typical functionality as well as a set of unexpected capabilities like multitouch screen, visual voice mail, etc. that thrill every product user.

Usage Scenarios

As requirements are acquired, an overall vision of system functions and features emerges. However, moving into more technical software engineering activities is difficult unless you understand how these functions and features will be used by different types of end-users. To do this, engineers and users can collaborate to establish a set of scenarios that identify a thread of usage for the system to be built.

Elicitation Work Products

The work products generated as a result of requirements elicitation will differ according to the size of the system or product to be constructed.

The work products for the majority of systems include

  • A need and feasibility statement.
  • A bounded statement of the system’s or product’s scope.
  • A list of clients, users, and other stakeholders who took part in the requirements elicitation process.
  • A description of the technological environment of the system.
  • A list of objectives, as well as the domain restrictions that apply to each of them.
  • A set of usage scenarios that provide information about how the system or product is used under various operational conditions.
  • Any prototypes created to help describe requirements more precisely.

Each of these work products is assessed by everyone who took part in the requirements elicitation process.

Notify of
Inline Feedbacks
View all comments