Requirements Identification

Definition

Requirements Identification

the requirements engineering task during which raw new potential requirements are identified

Requirements identification is often also known as:

• Requirements Acquisition
• Requirements Discovery
• Requirements Determination
• Requirements Elicitation
• Requirements Gathering
• Requirements Invention
• Requirements Trawling

Classification

As illustrated in the preceding figure, Requirements Identification is part of the following inheritance hierarchy:

• Type: Abstract
• Superclass: Engineering Task
• Subclasses: None

Responsibilities

The typical responsibilities of Requirements Identification are to:

• Identify the desires, potential needs, and expectations of the application’s stakeholders.
• Transform these desires, potential needs and expectations into potential new raw (unanalyzed) requirements.
• Capture these potential raw requirements:
  • In the standard business language of the users, customer representatives, and the application domain.
  • From the perspective of the users and customer representatives.

Preconditions

Requirements identification can typically begin when the following preconditions hold:

• The initiation phase has started.
• The requirements team is adequately staffed and trained in requirements identification.
• Domain experts are available for workshops and interviews.

Completion Criteria

Requirements identification is typically complete when the following postconditions hold:

• All potential new raw requirements have been identified, collected, and informally documented.

Steps

Requirements identification typically involves the requirements team performing the following steps in an iterative, incremental, parallel, and time-boxed manner:

• Identify possible sources of requirements:
  • Stakeholders (who have a vested interest in the business, application, or component being specified).
  • Subject matter experts (e.g., domain experts, industry analysts, consultants).
  • Reusable requirements and requirements specifications (see Requirements Reuse)
  • Documentation (e.g., business strategy documents, business vision statement, documentation of relevant legacy systems, workflow procedures, vendor documentation, marketing studies, change/enhancement requests from the users and technical service representatives, industry analyst reports, etc.).
  • Human Interface Prototypes.
  • Legacy, competing, and similar applications.
  • Application and enterprise databases.
• Obtain and read documents that are sources of potential requirements.
• Hold joint requirements identification workshops using a cross-functional team including customer representatives, user representatives, domain experts, marketing personnel, and user support agents.
• Interview customer representatives, user representatives, domain experts, marketing personnel, and user support agents.
• Observe representative users at work.
• Study similar applications and databases.
• Evaluate human interface prototypes.
• Informally identify and capture the resulting potential requirements.
• Informally evaluate these potential requirements for quality (e.g., correctness, feasibility, etc.).
• Iterate the potential requirements as necessary.

Techniques

Requirements identification can typically be performed using the following techniques:

• Application Studies.
  Reverse engineer requirements from legacy applications, competing applications, similar applications, and databases.
• Apprenticing.
  A requirements engineer becomes an apprentist to a user representative, learns the user's tasks, and thereby learns the user’s needs.
• Documentation Studies.
  Study all documentation that may provide potential requirements.
  • Textual analysis (e.g., noun/verb for object/operation, shall/must/will for requirements).
• Cross Functional Teams.
  Requirements identification should be performed by a cross-functional requirements team including multiple roles.
• Incremental Development.
  Incrementally develop the lists of potential stakeholders, other sources of requirements, and requirements.
• Iteration.
  Iterate the lists of potential stakeholders, other sources of requirements, and requirements.
• Joint Application Development (JAD).
  Hold joint requirements engineering workshops involving members of development, customer, and user organizations:
  • Brainstorming.
    Brainstorm informal lists of potential stakeholders, other sources of requirements, and requirements.
  • Informal joint modeling (e.g., domain modeling, use case modeling, object modeling, and state modeling) using actor cards, use case cards, diagrams, printing whiteboards, etc.
• Interviews.
  Interview the stakeholders and subject-matter experts.
  • Active listening.
• Questionnaires.
  Have the stakeholders and subject-matter experts fill out questionnaires regarding the requirements.
• Observation.
  Observe the users while they are using the current or related application:
  • Note taking, audiotape, and/or videotape (in either public or surveilance mode).
  • Active questioning.
  • Verbal descriptions of duties.
  • Keystroke monitoring.
• Parallel Development.
  Elicit the requirements in parallel with:
  • Other requirements engineering tasks (e.g., requirements reuse, requirements analysis, requirements specification).
  • Other activities (e.g., architecting, design, testing, management, configuration management, training).
• Prototyping.
  Prototype the human interface of the application and derive requirements from the prototypes (e.g., storyboards, wireframes).
• Timeboxing.
  Timebox the requirements identification task so that new increments of potential requirements are available for analysis at regular intervals.

Work Products

Requirements identification typically results in the production of the following work products:

• Informal textual lists of requirements sources.
• Informal textual lists of requirements.
• Actor Cards.
• Use Case Cards.
• Informal diagrams (e.g., context diagrams, use case diagrams, sequence diagrams, activity diagrams, etc.).
• Audio and videotapes of requirements identification sessions with stakeholders and subject-matter experts.

Guidelines

• Requirements identification should be performed iteratively, incrementally, and in parallel with other tasks (e.g., requirements management, the development of a human interface prototype).
• Hold multiple JAD requirements workshops and individual interviews rather than one big mass meeting.
• JAD requirements workshops tend to be more effective than interviews and questionnaires.
• Use interview checklists to help ensure that no issue falls through the cracks.
• This task is called requirements identification rather than requirements elicitation or gathering to emphasize that there are many ways to identify requirements.
• The requirements team must understand the user’s work in order to properly elicit requirements from them and understand the requirements that they elicit because the application or component to be specified exists in order to help the users perform their work or else perform the work for the users.
• Requirements identification can be difficult for numerous reasons:
  • Stakeholders often have difficulty expressing their needs, although they are often convinced that they have expressed themselves clearly.
  • Stakeholders often have difficulties imagining new ways of doing their tasks (and new applications should enable new ways of doing things or enable new things to be done).
  • Stakeholders may not realize that stated requirements may not be real requirements.
  • Stakeholders may identify requirements that are not real:
    • Their requirements may not be feasible given business and technical constraints.
    • Their requirements may not be cost-effective (gold-plating).
    • Their requirements may not be validatable (e.g., testable).
    • Stakeholders often request solutions (implementations and constraints) rather than requirements.
  • The identified requirements may be at the incorrect level of abstration:
    • If they are at too high of a level of abstraction (e.g., at the level of a business goal), their achievement may rely on factors outside of the application (i.e., incorrect scope) and thus be beyond the control of the development organization.
  • The identified requirements, even when properly implemented, may not adequately enable the users to perform their tasks.
  • Stakeholders can have conflicting requirements.
  • Some requirements are much more difficult to identify than others:
    • Stakeholders often fail to identify requirements that deal with exceptional situations.
    • Stakeholders often find it difficult to identify data and quality requirements.
    • Missing requirements are a major cause of endeavor failure as measured by endeavor cancellation, cost overruns, budget overruns, inadequate functionality, etc.
  • Stakeholders often do not know all of the important consequences of their requests (e.g., cost, schedule, maintenance, technology).
  • Stakeholders (and requirements engineers) often have difficulty determining the scope of the requirements. For example, they may confuse:
    • Application or component requirements, which belong in the requirements specifications.
    • Endeavor “requirements” (e.g., cost, schedule, and legal responsibilities such as who is responsible for installation, user training, data conversion, and application operation), which are ou of scope and belong in the the contract or statement of work.
    • “Requirements on users” of the application, which are out of scope and belong in user procedures.
  • Stakeholders often find it far easier to identify problems with applications once they are placed into production than to identify what they need up front.
  • Requirements change during the course of the endeavor as conditions change (e.g., market pressures change, mistakes are found, lessons are learned, laws change, technology changes making new requirements feasible, etc.).
  • If the application is very new, there may not be stakeholders with any relevant business or application domain expertise.
  • Requirements engineers may not be properly trained in the requirements identification task and its associated techniques.
  • Requirements engineers may not be able to identify all relevant stakeholders.
  • Requirements engineers may not be provided adequate access to all stakeholders. In fact, with certain kinds of projects and application procurement, the development organization may not be legally allowed to collaborate with stakeholders to properly elicit the requirements.
• Avoid the use of technical jargon in the raw requirements, unless it is the well-known (within the business domain) jargon of the users or customer representatives. Avoid the use of application (e.g., systems or software) development terminology.