RAPPeL: A Requirements-Analysis Process Pattern Language for Object-Oriented Development


By: B. Whitenack
Published in: PLoPD1
Pages: 259-291

Summary: For analysts, developers, and project managers engaged in defining requirements for business applications in an object-oriented environment.

Category: Analysis

Url: http://www.bell-labs.com/people/cope/Patterns/Process/RAPPeL/rapel.html

Pattern: Building the Right Things

Pages: 263-264

To capture, communicate, and validate software requirements, identify requirements sources. Devise a work plan for interviewing and examining the sources and produce a set of interview results. Capture and validate sponsor objectives as well as manage customer expectations. Prioritize requirements. Establish and keep customer rapport during this process.

Category: Analysis

Pattern: Managing and Meeting Customer Expectations

Pages: 264-265

To manage and meet customer expectations for a product, create a list of customer expectations, and classify each as a real requirement or wish. Classify each real requirement in the requirements specification using Behavioral Requirements or Pragmatic External Requirements. These requirements must be prioritized. Use Prototypes to ensure system behavior will meet the customer expectations.

Category: Analysis, Customer Interaction, Organization and Process

Pattern: Customer Rapport

Pages: 265

To build a good relationship with a customer, first develop a good rapport with the customer, then move to specifying the customer's requirements. Focus on the user. Don't talk down to them. Don't use too much technical jargon. Use Prototypes

Category: Customer Interaction, Organization and Process

Pattern: Sponsor Objectives

Pages: 266

Hold interviews to build consensus on the most important business objectives (no more than eight). Ask, "If the system will not substantially meet this objective, is that sufficient reason to stop system development?" If the answer is yes, then the objective is a solid one. Each goal should be measurable.

Category: Customer Interaction, Organization and Process

Pattern: Defining Requirements

Pages: 266-269

Create and maintain a glossary of common business terms. Use Behavioral Requirements and Problem Domain Analysis. Validate the requirements specification with the customer.

Pattern: Problem Domain Analysis

Pages: 269-271

To determine the essential nature of the system's problem domain, use problem domain analysis. Use Finding and Defining the Domain Objects; Information Needs; Classifying, Associating, and Grouping the Domain Objects; Behavioral Requirements; Elaboration of the Domain Objects; Business Rules; Elaboration of the Domain Objects; and Object Aging

Pattern: Information Needs

Pages: 271-272

Identify the ways users will manipulate information. Use Envisioning, User Interface Requirements, and Prototypes.

Category: Analysis

Pattern: Finding and Defining the Domain Objects

Pages: 272-273

To determine objects in the problem domain and define their roles and responsibilities, consider every process, transaction, piece of information, and problem domain entity an object. Use CRC cards. If possible, derive the initial domain model from use cases. Alternatively, a written description of the business process can be used.

Category: Analysis, Design Process

Pattern: Classifying, Associating, and Grouping the Domain Objects

Pages: 273-275

To capture the set of associations among domain objects, for each object identified in Information Needs, and for each responsibility, trace a simple scenario in which the object uses the behavior. Note all relationships with other objects.

Category: Design Process

Pattern: Elaboration of the Domain Objects

Pages: 275

Instead of assigning attributes, state that a responsibility of an object is to convey information that may be held by an attribute. Use Information Needs to associate information with an object. Use Business Rules. To capture life cycle and states, use Object Aging

Category: Design Process

Pattern: Object Aging

Pages: 276

If an object changes state, define its life cycle, using Behavioral Requirements. For each domain object, determine whether there are state changes. Name each state and build a state transition diagram, listing the use case event that causes each state change.

Category: Design Process

Pattern: Object Stereotypes

Pages: 276-278

To determine roles of the objects in the problem domain, Wirfs-Brock has created a list of behavioral stereotypes for objects [Wirfs-Brock93]. Use this as a starting point.

Category: Design Process

Pattern: Behavioral Requirements

Pages: 278-281

To determine the system's required behaviors, first consider behaviors in terms of use cases--how clients will use the system. For each client, list all use cases. This will capture the primary external behaviors of the system.

Pattern: Envisioning

Pages: 281

Envisioning means: (1) imagining a system to support a set of business processes and (2) conceiving an entirely new set of business processes. Write the entire process, detailing each step. Each step of the process should be considered a potential use case.

Category: Organization and Process

Pattern: Requirements Specification

Pages: 281-282

Use a basic template to specify requirements that organizes the information into sections that reflect the activities and types of deliverables needed. Use Behavioral Requirements, Problem Domain Analysis, and Requirements Validation

Pattern: Business Rules

Pages: 282-287

To define and capture business rules so they can be verified and used, James Odell [Martin98] describes a taxonomy that classifies business rules into six types. Divide these into two categories: three that constrain use cases and three that constrain objects and their states.

Category: Organization and Process

Pattern: Pragmatic External Requirements

Pages: 287-288

Use a template to capture most nonbehavioral requirements as well as the constraining behavioral requirements. Review the constraints with all groups involved in delivery, installation, training, and implementation.

Pattern: User Interface Requirements

Pages: 288

Use cases provide a way for verbalizing user tasks. Use Prototypes to examine the user's views.

Category: Analysis, GUI Development

Pattern: Prototypes

Pages: 288-290

Work with the customer to build low-fidelity prototypes using paper widgets, drawings, self-stick notes, and index cards. Alternate between prototyping and use case modeling. Prototyping involves users and use case modeling provides rigorous analysis.

Category: Organization and Process

Pattern: Requirements Validation

Pages: 290

To verify that behavioral requirements are correct and complete, have all interested parties read the requirements specification. Conduct review meetings. Follow up on all issues raised. Use Prototypes. Continue requirements verification through each system development iteration.