RAPPeL: A Requirements-Analysis Process Pattern Language for Object-Oriented Development RAPPeL: A Requirements-Analysis Process Pattern Language for Object-Oriented DevelopmentBy: 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
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.
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
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
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
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.
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
Pages: 271-272
Identify the ways users will manipulate information. Use Envisioning, User Interface Requirements, and Prototypes.
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
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.
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
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
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.
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.
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
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
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
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.
Pages: 288
Use cases provide a way for verbalizing user tasks. Use Prototypes to examine the user's views.
Category: Analysis, GUI Development
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
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.