Requirements Prototyping

Definition

Requirements Prototyping

the requirements engineering task during which requirements prototypes are produced

Classification

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

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

Responsibilities

The typical responsibilities of Requirements Prototyping are to:

• Produce one or more requirements prototypes.
• Use these prototypes to:
  • Help elicit new requirements, especially functional, data, and quality requirements regarding user interfaces.
  • Identify defects in existing requirements.
  • Analyze (e.g., prioritize) these requirements.

Preconditions

Requirements prototyping can typically begin when the following preconditions hold:

• The business strategy team, technology strategy team, and/or requirements team are adequately staffed and trained in requirements prototyping.
• Customer representatives, domain experts, marketing representatives, and user representatives are available for evaluating the requirements prototypes in order to elicit new requirements and identify defects in existing requirements.

Completion Criteria

Requirements prototyping is typically complete when the following postconditions hold:

• The requirements prototypes have been properly evaluated.
• New potential requirements and modifications to existing requirements have been elicited.
• These requirements have been analyzed based on input from evaluating the requirements prototypes.

Steps

Requirements prototyping typically involves the business strategy team, technology strategy team, and/or requirements team performing the following steps in an iterative, incremental, parallel, and time-boxed manner:

• Determine Cost, Benefit, and Feasibility.
  • Will there be significant user interfaces?
  • Are there significant requirements involving these user interfaces?
  • Is there significant confusion or uncertainty regarding these user interfaces?
  • Is there significant confusion regarding the priorities of the associated requirements?
  • Would requirements prototypes help remove the confusion and uncertainty.
  • Would creating requirements prototypes be cost-effective?
  • Is requirements prototyping feasible in terms of available resources and schedule constraints?
• Plan Task.
  • Determine the objectives of the requirements prototypes.
  • Determine the types of requirements prototypes (e.g., low-fidelity prototypes, high-fidelity prototypes) to produce.
  • Determine the appropriate technologies to use (e.g., paper, GUI builder, simulation tool).
  • Determine which team members will produce the requirements prototypes.
  • Determine who will evaluate the requirements prototypes:
    • Customer Representatives.
    • Domain Experts.
    • Marketing Representatives.
    • User Representatives.
• Build Protoypes.
  • Build the requirements prototypes.
  • Informally evaluate the requirements prototypes.
  • Iterate the requirements prototypes.
  • Repeat as necessary.
• Evaluate the Protoypes.
  • Invite the prototype evaluators.
  • Evaluate the prototypes.
  • Elicit and record new potential requirements.
  • Elicit and record defects existing requirements.
  • Iterate the requirements prototypes.
  • Repeat as necessary.

Techniques

Requirements prototyping can typically be performed using the following techniques:

• Cross Functional Teams.
  Requirements prototyping should be performed by a cross-functional requirements team including multiple roles.
• Incremental development.
  Incrementally develop the requirements prototypes and lists of evaluators.
• Iteration.
  Iterate the requirements prototypes and lists of evaluators.
• Joint Application Development (JAD).
  Hold joint requirements prototype evaluation sessions involving members of development, customer, and user organizations:
• Parallel Development.
  Produce the requirements prototypes 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.
  Produce requirements prototypes and derive requirements from them.
• Timeboxing.
  Timebox the requirements prototyping task so that new increments of potential requirements are available for analysis at regular intervals.

Work Products

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

• Requirements Prototypes:
  • Low-Fidelity Prototypes:
    • Paper Graphical User Interfaces (GUIs).
    • Storyboards of use case paths.
    • Wireframes.
  • High-Fidelity Prototypes:
    • Prototype GUIs produced with a GUI builder tool.
    • Simulations of use cases and their paths.

Although technically not work products that are produced by the requirements prototyping task, the following are typically produced simultaneously:

• Informal lists of:
  • Potential requirements (technically an output of the requirements identification task).
  • Lists of requirements defects (technically an output of the requirements analysis task).
  • Lists of requirements priorities (technically an output of the requirements analysis task).

Guidelines

• There may not be adequate resources and time in which to produce significant requirements prototypes.
• Low-fidelity requirements prototypes are quicker and easier to produce than high-fidelity prototypes, and because they contain less design detail, they often enable the evaluators to concentrate on requirements rather than on iterating design details.
• Requirements prototypes require ready access to those who will evaluate them in order to be beneficial.