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

Copyright 1994, Knowledge Systems Corp.

Author: Bruce G. Whitenack, Jr.

Knowledge Systems Corporation
4001 Weston Parkway
Cary, North Carolina 27513
Phone Number: 919-481-4000
Fax: 919-677-0063

Abstract

Pattern Index:

• Customer Expectations
• Customer Rapport
• Sponsor Objectives
• Defining Requirements
• Problem Domain Analysis
• Information Needs
• Finding And Defining The Domain Objects
• Classifying Associating And Grouping The Domain Objects
• Elaboration Of Domain Objects
• Object Aging
• Object Stereotypes
• Behavioral Requirements
• Requirements Specification
• Business Rules
• Pragmatic External Requirements
• Prototypes
• Requirements Validation

Rationale for RAPPeL:

The goals of this pattern language are the following: (1) to guide analysts and product developers to most appropriately apply a set of techniques and methods so as to produce a more thorough analysis and understanding of the problem area (2) to provide a framework upon which to define and capture requirements before and during object-oriented development and upon which a proposed software product can be evaluated, designed, built and tested and (3) to be able to trace the design of the system back to the original business and system objectives. In short, the primary goal of this pattern language is the primary goal of requirements analysis in general - it is to ensure that systems that 'do the right things' get defined and built.

Caveats

This is a work in progress. The reader should assume there are no other patterns then the ones that exist in this paper. The numbers used for each pattern indicate that I expect to add new patterns as the language matures and as the existing patterns expand. I also expect RAPPeL to be joined with other potential languages (e.g. Project Management, Product design, etc.).

To make best use of this pattern language I suggest the reader first take a quick pass through the language and read the problem statements of each pattern. Subsequently go back and read each pattern entirely. Few of the patterns stand alone. They need to be read in the context of the whole language. I believe those readers who are involved in development of business applications using object-oriented languages will be rewarded for their efforts in understanding and applying these patterns. I know I have been. It is the hope of the author that software development will eventually becomes more akin to rapidly rappelling down the mountain (from one sure point to another, moving towards a safe destination) rather than being bloodied as one continually picks his way around crags and through crevices.

Table of Pattern References

Direct Deliverables:

Requirements Sources [D].
Work Plan[D]
Interview Sheets and Group Meting Results [D]
List of Customer Expectations[D] 
Business Goal Matrix[D]
Business Goal Summary Report[D]
Use Case Matrix[D].
Model Structure Diagrams [D]
Business Process Definitions[D]
Business Process Diagrams[D]
System Boundary Diagram [D ].
Information Source Matrix [D]
Information Flow Diagrams [D]
Scenario Script[D] 
Use Case Matrix[D ]
Use Case Definition[D ]
Use Case Models[D ]

Decision Table[ D]

Decision Tree[D]

Moore State Transition Matrix[D]

Harel Statechart[D ].

Petri Nets [D].

Business Rules[D ]

Information views definitions with attribute definitions
and edits[D]

Pertinent object relationships [D]

Low fidelity Prototypes[D] 

High Fidelity Prototypes[D]		

CAR diagrams[D]

Window Flow diagrams [D]  

Pragmatic Requirements Template[D]

Issues List[D]

Glossary of Terms[D]

Error Message List [D]

 CRC Cards[D] 

Object Definitions[D] 

Message Flow Diagram[D]

 State Transition Diagram[D]

1. Building the Right Things

Problem:

Discussion:

Solution:

Now comes the fun part. When the initial investigation described above is done and all the players are identified, the real requirements analysis game begins. The following paragraph makes the process sound trivial but in reality it means alot of varied activities in which inventiveness and experience play a big part. RAPPeL is meant to provide guidance and experience to lead you down the right paths.

Use the methods and activities described in Requirements Analysis [17] to determine how to best use and bind together the three key threads of activity (Problem Domain Analysis [20], Requirements Specification [34] and Requirements Validation [99] so as to produce a specification that will best communicate and model the requirements. It is extremely important to include the use of Prototypes [97] as a key part of requirements analysis. The end result of all activities pointed to by this language is a validated Requirements Specification and one or more product simulations.

5. Managing and Meeting Customer Expectations

Problem:

Discussion:

Solution:

Build one or more prototypes as discussed in Prototypes[97] to validate that the defined behaviors of the system will meet customer expectations.

9. Customer Rapport

Problem:

Discussion:

Solution:

Every successful Smalltalk project that I am aware of used prototypes to model behavior and to build upon.

14. Sponsor Objectives

Problem:

Discussion:

Solution:

The business objectives discussed and chosen should essentially reflect the reasons the enterprise is undertaking the development of the system in the first place. A good guideline that American Management System [AMS92] suggests for determining whether a business objective is appropriate is to ask the question: if the system will not substantially meet this objective, is that sufficient reason to stop the system's development? If the answer is yes than you have a business objective. Try to limit the objectives to no more than eight.

Determine who will support the system and who may oppose it. As a result of these activities, complete a Business Goal Matrix[D] containing business goals. Each goal will have an explanation of the metric used for the measures, a current measure and a target measure. Also complete a Business Goal Summary Report[D] which includes consensus answers and significant variances between users.

Use the measurable business goals to negotiate to deliver requirements that are both valid and reasonable from both customer and development perspectives.

17. Defining Requirements

Problem:

Discussion:

Also, what is one organization's requirement is another organization's design feature.

Company Q may be satisfied to simply state their sales people should be able to add a term to a contract . Company B may want to state that the Contract window must display a contract in a particular outline form and the sales person must be able to select a term and place it in the outline. Natural language is a clumsy way to specify user interface design/requirements. Analyzing the problem domain with minimal thought to the functional requirements of the system will lead to well-rounded objects. These are objects that are not slanted towards a particular service, application or use imposed on them by a particular external user. They may be shallow, however, as they have not been called upon to provide a set of services for a number of external users. Consequently, there must be activities to focus and define the behaviors of the new system . These activities must answer the following questions :

• Since there must be business reasons to limit and prioritize the essential requirements, what are the Sponsor Objectives[14] to be supported by the new system?
• Since the scope of the problem domain must be bounded , what are the boundaries of the system ?
• What clients (users) will use it?
• What external entities will provide services to it?
• Since the system will be built and developed in an environment (both business and technical) that has limitations and standards, what are the Pragmatic External Requirements[40] on the system?
• Since the users will have special needs and tasks to be supported by the system, what are the information needs of the users?
• What user tasks will it support?
• How must it support those tasks?
• Since the system must enforce the rules and policies of the domain, what rules of the domain (business rules) must be enforced by the system?

Solution:

Requirements analysis may be thought of as a three-stranded process (like a three-stranded rope). The first strand is problem domain analysis, the second is requirements specification and the third is validation of the requirements. Each strand overlaps and reinforces the others. The threads are intertwined, not connected end to end as in a waterfall approach. If a product is to be built to solve a problem then the problem must be understood by analysis before a solution is defined. The solution is the requirements specification. The validation step is to ascertain that the defined requirements will actually solve the analyzed problem.

Use and study the template discussed in Requirements Specification[34]. It will serve as a framework for the requirements analysis effort. Initially capture the Behavioral Requirements[30] and do Problem Domain Analysis[20]. As the activities in these patterns are completed so that requirements deliverables are produced, complete the corresponding sections of the requirements specifications. Validate the deliverables and the sections of the requirements specification with customers. As discrepancies occur, the areas of the requirements specification are revisited and re-reviewed. Finally, the last aspect of the problem is analyzed, all issues are reconciled and a public version of specification is completed.

The problem will be better understood as the behaviors are specified and modeled. In fact, because most OO development efforts have an object model which is used to conceptualize the problem domain and which may be incorporated directly into the system design, there is an increased understanding of the problem domain as development continues. The specification should be validated and understood so the product will conform to the right set of behaviors. As the specification is validated by the customer, the desired behaviors may be refined or changed.

20. Problem Domain Analysis

Problem:

Discussion:

The purpose of problem domain analysis is not to define requirements for a product but to get the deepest understanding of the problem area.

Consider we are interested in investigating how the human brain works. We would identify its parts, its cells, its regions and then try to determine what each does. What are the parts of neurons? What happens when we see , smell, hear, feel, taste? How do these things happen? We could do all kinds of studies to see what are the effects of different environmental conditions on the brain. We could study memory, language and thought processes. However, let us say that more specifically, we are funded and required to find the best way to treat brain tumors. This narrows our scope to brain tumors and ways of destroying them without harming the brain. It focuses our analysis of the brain to aspects that have to be considered with the destruction of brain tumors. After all, this is the reason we are doing the analysis. These two things, analysis and requirements specification are very much intertwined. The more we specify the requirements, the more it focuses the analysis of the problem area. Consequently, the identification of the tasks to be performed (like the eradication of brain tumors) are considered to some degree during problem analysis. This results in the 'Ping-Pong' process of defining behavioral requirements and doing domain analysis at the same time. How does this process work when one is doing problem domain analysis?

Solution:

What are the essential objects in the problem domain? What is their nature? What are their roles and responsibilities? The roles depend on how they are viewed by the users of the objects. A coffee mug can be viewed as a paper weight, a holder of coffee, a holder of pencils and other objects, or as decorative art. It can be a valuable keepsake or a piece of junk. It can even be conceived as a breakable item or a marketing gimmick depending on the users point of view. See Finding and Defining the Domain Objects[24].

What 'important information' is inherent in the objects ? What is important information also depends on the user's point of view. Information associated with a coffee mug can be its logo, color, size, price, material, shape, weight, manufacturers, suppliers, balance on hand, price. See Information Needs[22].

What are the relationships between objects? What objects are part of other objects? See Classifying, Associating and Grouping Domain Objects[25].

What processes are inherent in the community of objects? (i.e. order fulfillment, or making a sale, producing a product) See Behavioral Requirements[30].

What are significant events? (i.e. parts in the warehouse are below threshold so produce an order and notify purchasing) See Behavioral Requirements[30].

What rules (or business rules) constrain the objects? See Elaboration of the Domain Objects[26] See Business Rules[36].

What is the life cycle of an object? What states can each object be in? See Elaboration of the Domain Objects[26] Object Aging[27].

The goal of problem domain analysis is to define the world (often called the problem space, product space or problem domain) in which the product is to be built. The nature of the domain makes some of the What questions listed above more important than others. In many business applications the Information Needs[22] and the Business Rules[36] are the two most important aspects to be defined. The information needs must be identified and in many cases those needs dictate what are the essential information-holding objects that are part of the business domain (See Object Stereotypes[28] ).

To do a good and meaningful domain analysis follow the patterns that answer each of the analysis questions asked in the table above.

22. Information Needs

Problem:

Discussion:

Solution:

Construct an Information Matrix[D] which identifies the information object, what is its source (is it calculated or does it come from an external system), a description of it (its semantics). In addition in order to check for completeness what object/class the information may be part of and what prototypical views it is in may be included.

To define transformations of information draw Information Flow Diagrams[D] that show the information flow through the use cases. These data flow diagrams will show the source of the information and how it gets manipulated in the use cases. To do this successfully requires a fairly complete Use Case Model[D] . As pointed out in Caterpillar's Fate [Kerth94], event-partitioned data flow diagrams provide a number of features to help in translating requirements analysis to design.

24. Finding and Defining the Domain Objects

Problem:

How do you define their roles and responsibilities?

Discussion:

There are complex objects and their are simple objects. There are objects that are known by end-users and are visible and essential to the problem domain (commonly called first-class objects). There are also those that are supportive of the first-class objects. Most objects in the problem domain can be categorized into one of a number of role-types. This type of classification helps in understanding the essential nature of the problem domain. See Object Stereotypes[28]. Defining the first-class objects in the problem domain is a task that can be done in several ways. An experienced analyst, after a careful study of the business processes should be able to define a large percentage of the domain objects.

Solution:

If use cases can be easily defined for the new system then the first solution is to derive the initial domain model from use cases using the CRC technique. If the problem area is complex and a system is not easily envisioned, it is difficult to define use cases. In this case, it is helpful to ensure that each business process is well-defined and written out. From the written description of the business, underline the nouns as possible objects ( Yes this really does work) while verbs may reflect responsibilities of the object or use cases.

After the business processes and problem domain are better understood, the use cases can be more easily derived.

The optimal size for work groups is 3-6 persons. Use a small table with enough room for all group members to easily read and access the cards. Assign a scribe (with legible handwriting) for writing and editing the cards. Revisit each system use case, identifying any terms that seem common to the business domain being addressed. Use these terms to develop a list of candidate domain objects.

Write each candidate's name on a CRC card.

Order the cards by their relative importance in the domain.

Starting with the first card, propose responsibilities for the object using the use cases and domain experts as a guide.

Document each responsibility on the CRC card.

Based on the responsibilities, determine what set of roles the object has. Usually it will have one main role. See Object Stereotypes[28] for possible roles.

25. Classifying, Associating and Grouping the Domain Objects

Problem:

What are the relationships between objects?

What objects interact with other objects?

What objects are part of other objects?

Discussion:

This is a very rich set of associations. How does one go about capturing and defining the associations?

Solution:

For each (major) responsibility:

1. Develop a simple scenario where the object used requires this behavior.
2. Role-play the scenario again. This time, when the behavior is requested from the domain object, determine the collaborators (servers) required and develop a mechanism for fulfilling the defined responsibility.
3. Repeat the role-play until the mechanism works.
4. Consider all the use cases and events that are triggered by external clients.
5. Be sure the use case or triggering event has been captured in the Use Case Matrix[D].
6. For each one develop a simple scenario where this event or use case is triggered.
7. Role-play the scenario to see if it makes sense.
8. Document the mechanism as a validation scenario in a Message Flow Diagram[D] or Scenario Script[D]

Using the cards and a tool with notation of choice to group and classify the objects to show the associations. Use Model Structure Diagrams [D] to capture the following relationships among the Domain Objects within the system:

	Containment

	Inheritance

	Creation

	Dependency

	Indirect associations

26. Elaboration of the Domain Objects

Problem:

Discussion:

However, during requirements analysis, it is important to determine what business rules constrain objects. It has been our experience that business rules are seldom explicitly specified during product development (regardless of the fact that they are often important constraints of the behavior of the system) even though they may be discussed and identified during the analysis. Most of the time they are explicitly defined only in the database schema via stored procedures or in the coding of the application as developers become aware of the constraints on the application behavior. Consequently rules are spottily defined, are not consistently maintained and are implemented in an ad hoc manner throughout the product. Rules however, are often an effective way to define the behavior of a system. How can the important business rules be identified, captured and organized?

Solution:

To capture business rules refer to Business Rules[36] .

To capture life cycle and states of the domain objects refer to Object Aging[27].

27. Object Aging

Problem:

Discussion:

Solution:

These state transitions are often reflected in business rules and determine workflow. The diagrams are an excellent means to validate and capture the domain expert's view of what transpires during a use case or business process involving an important business object. For example a Schedule may be in one of three states: Working, Validated or Approved. It must first be Validated before it can be Approved. If it is Approved it will cause other dependent Schedules to have to be updated. If an Approved or Validated Schedule is changed it becomes a Working Schedule once again. In addition, it is not uncommon to discover that objects can also transition to different versions. The same schedule may have several Validated Versions. This creation of new versions can also be captured in a State Transition Diagrams[D] .

28. Object Stereotypes

Problem:

Discussion:

Solution:

1. Information holders - maintain values that other objects can ask about.

   These include things like shipping movement, customer account, transactions.

   Many business objects are simply information holders. They have a set of attributes with primary values that are associated with an instance of a business entity.

2. Structurers - Maintain relationships between objects.
3. Controllers- Perform a cycle of action. An example of this is a workflow object. An object that monitors and schedules a set of tasks .
4. Coordinators - Pair client requests with objects that can perform a single service. These objects act like brokers or middlemen.
5. Service providers (I like to call these Task Helpers. The problem here is that all objects are essentially service providers. ) - These objects perform a single business task upon demand. An example would be a helper object to calculate the balance on hand. You give it a Raw Materials recipe and it will tell you if the raw materials exist in the warehouse.
6. Interface objects - support communication between objects within our program and external systems or users. Interface objects are windows that the users will work with like the schedule on the screen the user works with. Or a database broker that stores a persistent object. An object to help communicate with a CICS program on a host.

In addition to the above list of stereotypes, there are two specialized role types that I find useful during analysis/design. These are:

1. Catalogues - Libraries or repositories for managing the capture, deletion, selection and modification of business objects. Examples are a parts catalogue or a warehouse of items.
2. Display Helper - These may also be termed application model (however I think application is an overloaded term). It is an object whose main purpose is to support the display of a business object for a particular window ( i.e. a spreadsheet) . In this regard it could be considered to be part of either an Interface object or a Information holder. For example, a scheduler may wants to examine the weekly shipping movement of products from a warehouse for the same period one year previous to the current week.

In addition he wants other related information to be visible such as current inventory and scheduled use. Special display support models may be needed to view the values in the information holders.

These are role stereotypes. Invent your own as appropriate during analysis. These stereotypes provide a richer set of analysis objects than the usual entity, control and interface objects used in other analysis methodologies but they also draw close to being design objects so be careful in their use. However, be sure to assign one or more roles to your objects in the Object Definitions[D].

30. Behavioral Requirements

Problem:

Discussion:

The system will be able to store versions of objects of all types -- text, musical, visual, executable, etc. Too often requirements are stated in general abilities of the system. Analysts fail to grab the 'bull by the horns' and visualize how the system will actually work for a particular user. The 'customer' often does not exactly know what the system is to do.

Solution:

For each client, list all the use cases in a Use Case Matrix[D] . The use cases will form the framework of the behavioral specification. Describe each use case in detail in a Use Case Description[D] . Complete a set of Use Case Models[D] to see how the use cases use and extend each other and what use cases have common parts.

A use case is a specific way of using the envisioned system consisting of a behaviorally related sequence of exchanges between a user and the system. It can be described textually as a high level description of business scenario, in outline form or as user/system conversations [Wirfs-Brock93b]. For every complete course of events initiated by a user identify one use case. Use cases are defined in [Jacobsen+92].

Use cases guide developers in design and implementation, provide test cases for system testers and communicate the functions of the system to users and customers. A Use Case Matrix[D] (containing all users and their associated use cases) will define completely the functionality of the system. It is best to define the initial set of basic use cases totally independently of any extended functionality.

A User/System conversation is often the best way of defining the use case. This consists of a set of exchanges between the users and the system. The system responds to each user action. After each system response annotate meaningful and useful related items: such as user views, steps performed by the system, data validation or business rules that must be enforced, etc. . For this type of requirements definition to be fully effective a tool is required to organize all the information and its associations.

As Rebecca Wirfs-Brock as pointed out [Wirfs-Brock92b], the identification and organization of use cases may get quite complex. The same tensions that exist for defining objects also exist for defining use cases. Use cases can expand polynomially. Use cases can be generalized into abstract use cases. In defining use cases Wirfs-Brock has noted that you need to ask the same types of questions as you do when defining objects. Below, I have attempted to answer the questions she asks.

• What process do you use to build good ones? (Look for the main responsibilities of the external users and what tasks they must perform to fulfill those responsibilities. If the business processes are well-defined, examine them and select the tasks that are potentially automatable as use-cases. )
• How should they be captured? (With Use Case Definitions[D] - some containing Use Case Conversations, Use Case Matrices[D] , Use Case Models[D] - showing extension and uses, Prototypical windows ).
• How detailed should they be? (As detailed as required to specify the requirements so that you cannot afford a deviation)
• When are you done finding and describing them? (At least get to the point where you have a complete use case matrix defined - all the users and all the major tasks that each initiate).

	Business Rules[D ]

	Information views definitions with attribute definitions and edits[D]

	Pertinent object relationships [D]

	Low fidelity Prototypes[D] 

	High Fidelity Prototypes[D]		

	CAR diagrams[D]

	Window Flow diagrams [D]  

To unambiguously model complex runtime system behavior, augment the use cases with the appropriate formal techniques using the following guidelines based on [Davis92].

If the use case involves a single system behavior which is a function of a set of simultaneously occurring conditions or stimuli use a Decision Table[D] . It is better at first to use a decision table because it helps make sure you have not omitted any conditions or stimuli. Convert the decision table to a Decision Tree[D]. The reasons for this is that it takes less space and it is easier for most people to understand. It also helps to capture the order of evaluating conditions (if that is a key criteria). Use both in the specification.

If the use case involves a series of sequential occurring stimuli, where the system behavior is a function of the previous set of sequential stimuli (a common example of this is a telephony system where the user will dial a series of numbers after getting a dial tone) , then use a model based on a finite state machine. This could be either a Moore State Transition Matrix[D] or a Harel Statechart[D]. Use statecharts with communication channels to enable signals to be communicated between specific processes without broadcasting those signals globally.

Harel's statecharts provide natural extensions to Finite State Machines to make them more suitable for dynamic real time systems such as an automobile cruise control system or an aircraft collision avoidance system. The extensions support the hierarchical decomposition of states and specification of transitions dependent on global conditions and being in particular states. If the use case involves complex synchronization such as process synchrony of time critical applications then use Petri Nets [D].

32. Envisioning

Problem:

Discussion:

It has been our experience that the envisioned business processes of complicated domains are of such a high level and lack sufficient detail such that it is difficult to derive use cases from them. This complexity and detail of the processes also make it difficult to envision the new automated system's behavior. How can these problems be remedied?

Solution:

Potentially, the users will want to interact with the system in a set of coordinated conversations. See [Wirfs-Brock93a] on use case conversations.

It is also helpful to use Lo-fidelity Prototypes[D] as a basis for visualizing how the user will interact with the system. This makes more tangible the scenarios that are described in the use cases.

34. Requirements Specification

Problem:

Discussion:

1. natural language - such as in use cases and process descriptions.
2. formal techniques- conceptual models reduce the inherent ambiguity of natural language by conveying the behavior in a more precise and unambiguous "language", diagram or notation.
3. prototypes - These simulate the external behavior of the system as it will be experienced by the user in the final product.

Solution:

This organizes the information into sections that mirror the activities and types of deliverables needed for requirements analysis. Initially capture the Behavioral Requirements[30] and do Problem Domain Analysis [20]. As the activities in these patterns are completed so that requirements deliverables are produced, complete the corresponding sections of the requirements specifications and add the deliverables to the document. Validate the deliverables and the sections of the requirements specification with customers. See Requirements Validation[99]. As discrepancies occur or requirements change, the affected areas of the requirements specification are revisited and modified. The Requirements Specification should be maintained throughout product development as it is the reference point for issues and for development of future versions of the product.

1.0 Requirements Gathering Plan   
	1.1. Overview of the proposed system 
 	1.2  Supporting  Personnel 
	1.3  Business organization
	1.4 Applicable References for requirements 
	1.5 Requirements Gathering Plan and Schedule 
	1.6  History of efforts in this area (systems and procedures).

2.0  Business Aspects  
	2.1  Business Goals and Measurements
	2.2  Expectations. 
	2.3 Summary report with consensus answers and significant variances 		between users 
	2.4. Impact of the System 
	2.5  User Attitudes *

*  This section may be kept internally 


3.0 System Aspects 
	3.1 External Clients
	3.2 External Servers
	3.3 System Boundary Diagram Form 
	3.4 System Goals with Measures 
	3.5 Business Processes 

4.0  Use Cases
	4.1 Use Case Matrix
	4.2 Primary Use Case Descriptions 
	4.3 Secondary and Exceptional Use Case Definition Forms 		
	4.4 Use Case Model 

5. Essential Object Definitions and Models
	5.1 Class Specification Forms
	5.2 Model Structure Diagram Forms
	5.3 Object Collaboration Diagrams 
	5.4 Object Life Cycles/Transitions  

6.  Information Needs	
	6.1  Information Matrix
	6.2  Data Flow Diagrams

7.  Interface Design
	7.1 Lo-fidelity prototypes
	7.2 Hi-fidelity prototypes
	7.3 CAR Diagrams 
	7.4 Task Analysis and Window Flow 

8.  Business Rules 
	8.1 Object-centered rules
	8.2 Use Case/operation rules

9. Pragmatic Requirements  
	9.1 Major Project  constraints 
		9.1.1 Time constraints - Delivery, market opportunity.
		9.1.2 Resource constraints - People, machines, money, 
		9.1.3 Organizational constraints - certain organizations must do 			certain jobs.
	9.2 Operational requirements  (Project related ) -  
		9.2.1 Configuration management 
		9.2.2 Versioning
		9.2.3 Performance
		9.2.4 Disaster recovery
		9.2.5 Training
		9.2.6 Hardware
		.........Software

	9.3 Application Interface Standards  

36. Business Rules

Problem:

Discussion:

Frequently, rules are defined only in the database schema via stored procedures or in the coding of the application as developers become aware of the constraints on the application behavior. Because there is no well-defined framework in which to plug rules and because there are a variety of rule types that are not well understood, rules are often ignored until implementation. Consequently, rules are seldom explicitly defined or consistently maintained and are implemented in an ad hoc manner throughout the software product. Rules are however, often the most effective way to define the behavior of a system. How should important business rules be identified, captured and organized?

Solution:

RULES that Constrain USE CASES

1. Stimulus/Response Rules (also called triggering conditions) constrain behavior within the context of a use case or an event that may trigger a use case. They specify WHEN and IF conditions that must be true in order or an operation (use case) to be triggered. The examples below are two rules that will trigger the use cases of Searching Stores for Copies of a Movie and Placing a MovieCopy on Reserve. (These use cases are part of the larger use case, Requesting a Movie Copy).

   	WHEN a Movie is requested by a Customer
   
   	IF  a Movie Copy  is not available in the store
   
   	THEN search other Stores for a  MovieCopy 
   
   	And 
   
   	inform the Customer as to availability.
   
   
   
   	WHEN a Movie is requested by a Customer
   
   	IF no COPY is available in any STORE 
   
   	Then place next available Copy on reserve. 
   

2. Use Case Precondition Rules specify what conditions must be true before an operation or use case can be ensured of performing correctly. An example is:

   	Schedule production of a Finished Good
   
   		ONLY IF Raw Materials and Plant Resources
                   are allocated successfully.
   

   The use case, Scheduling of a Finished Good, cannot proceed unless this condition is true.
3. Use Case Postcondition Rules guarantee the results of a use case or operation. A Production Schedule is CORRECTLY COMPLETED (or valid) ONLY IF all Raw Materials and Plant Resources for all FINISHED GOODS are allocated successfully.

   The Creation of a Validated Production Schedule is the use case guaranteed by this rule.

RULES THAT CONSTRAIN OBJECTS AND THEIR STATE

1. Object Constraint Rules.

   Most business rules have a constrained object and its associated constraining objects. Rules make references to one or more other objects besides the constrained object. The rule, a customers must have a SSN, has customer as the constrained object and SSN as the constraining object. To state this rule, there must be an association between SSN and Customer. It is a responsibility of Customer to convey and know its associated SSN. It does not have to possess it as an attribute although it probably will.

   Object constraint rules define conditions and policies for objects and their associations that either must not or should not be violated. A must not be violated rule should hold under any circumstance and during any use case.

   Examples of this are

   IT MUST ALWAYS HOLD THAT
   
   	A Production Machine's daily batches cannot total
           greater than 15,000 gallons
   

   IT MUST ALWAYS HOLD THAT
   
   If a customer has a SSN then the Driver's LICENSE NUMBER is his SSN
   

   The second example is an Object Constraint Rule that applies only when an IF condition is true.

   Once captured it is valuable to further categorize the rules as being inviolate (they can never be broken under any conditions like the ones above), exceptional (they can be broken under certain conditions or guidelines (they should be followed but do not need to be enforced).

   An example of an exceptional rule is

   IT MUST ALWAYS HOLD THAT
   
   	A Production Machine's daily batches cannot total greater than 15,000 gallons
   
   UNLESS
   
   	The Production Manager has Okayed added amounts for the Machine
   

   An example of a guideline is

   IT SHOULD HOLD THAT
   
   	A Production Machine's daily batches cannot total
   greater than 15,000 gallons
   

2. Inference Rules state that when certain conditions hold a new condition can be inferred. They can derive Object Subtypes as in:

   	A Product is a RecipedItem IF AND ONLY IF
   
   		it has an Approved Recipe 
   

3. Computation Rules are rules where a result is derived from an equation or algorithm.

   Examples of this are

   	Product Quantity IS COMPUTED AS FOLLOWS
   
              		Product Need -  Current Inventory + Shipping Movement
   

Now that we know rule classifications lets consider how to capture business rules:

1. Examine every use case. Determine what Stimulus/Response rules may trigger the use case or operation and what precondition rules and post condition rules are true for the use case and for operations within the use case. If there is a business rule evident in the use case and it is not yet captured, add or modify the rules to the Use Case Definition [D] .
2. Examine every essential business object and determine its associated object constraints rules. For each business object, list and number all the associated business rules (in natural language) wherein it is the constrained object. Also attach the appropriate Inference rules and Computation rules with each Object Definition[D] .

40. Pragmatic External Requirements

Problem:

Discussion:

Solution:

50. User Interface Requirements

Problem:

Discussion:

User Interface requirements need to be done early so as to get early customer feedback and for the timely development of user training materials and information documentation. The complexity of the user interface has a big effect on the underlying object models. The more complex it is (e.g. using hypertext, speadsheets, graphical networks) the greater the need for supporting display objects and the longer the development time.

How and what UI design should be accomplished during Requirements Analysis?

Solution:

97. Prototypes

Problem:

Discussion:

There are several major metaphors for software development. The software development metaphor used has an effect on the rigor and type of requirements specification. The software manufacturing and construction metaphor is where building software is like constructing a building. At one extreme of this metaphor, requirements are gathered in one-shot and a detailed specification is passed off to the designers who will then design a working system. The designers in turn complete their design and give it to the coders to implement. This is also called by other names such as the waterfall approach and the throw it over the fence process and usually culminates in the big-bang implementation (integrate all the pieces together at one time and then watch it disintegrate). The more evolutionary, incremental and iterative your approach, the more likely there will be a set of prototypes in the requirements analysis. The more likely requirements analysis with prototyping occurs early in system development, the more likely the system will work and the more likely the customer will be satisfied.

The dark side to prototyping is that solutions can be hacked together with the software inadequately robust and not well designed. It takes maturity, discipline and a very good programming/design environment to reengineer quality back into a product. Without rigor and discipline a product is in serious risk of failure when features are continually added. As more prototyping and evaluating are done, there will be the need to modify the requirements. Iteration between prototyping and use-case modeling occurs during requirements analysis. In addition, user expectations have to kept realistic as a prototype is not a product. Customers must realize that what they are seeing is a product simulation -- not the product itself.

Solution:

The high fidelity prototypes that are developed with a tool capable of generating useful code may be used for evolutionary development. It may not be a throwaway prototype but should be developed with the spirit that it will be thrown away. It has been my experience with Smalltalk development that if the developer has a good design in mind and if he is experienced, the prototype will probably contain code that is very usable for a production version. Be sure to plan for training of beta users and for doing a number of prototypes for perspective users.

99. Requirements Validation

Problem:

Discussion:

Validation is the process whereby it is confirmed a product has and does what is expected or specified. In the case of requirements analysis, the requirements specification is validated by the customer. The appropriate customers must rigorously read, study and validate the requirements against what they expect the product to be able to do and have. Use cases are excellent in structuring the specification of the behavioral requirements for study and validation. Customers can 'role play' the various use cases using the domain objects to get a better feel on whether the system is doing what is expected.

It is difficult to validate the completeness and consistency of systems defined manually. It is a human process with no automated validation.

According to Gilb [Gilb94], ideally there should be less than .5 major defects per page remaining after quality control and editing of the requirements specification. A project team can save eight hours of development work for every one hour of review effort applied. This can possibly lead to the delivery of projects 25% ahead of schedule, rather than late.

Solution:

Build prototypes and review then with users. Again, record every issue raised in the Issues List[D] and have follow up on each issue. Continue verification of requirements during system development through each iteration.

If needed, establish an arbitration group to reconcile disagreements on requirements.

Distribute prototypes to customers and conduct surveys and usability studies.

Bibliography

[AMS92] American Management Systems (1992). Methodology: Management Objectives & Business System Concept, American Management Systems, Inc.

[Arthur92] Arthur, Lowell J. (1992) . Rapid Evolutionary Development Requirements, Prototyping & Software Creation. New York: John Wiley & Sons, Inc.

[Beck94] Beck, Kent (1994). Smalltalk Report, March-April, 1994, pp. 15 - 16.

[Booch94] Booch, Grady (1994). Object-Oriented Analysis and Design with Applications. Second Edition. Redwood City, CA: Benjamin Cummings.

[Davis93] Davis, Alan. M. (1993). Software Requirements Objects, Functions, & States. Englewood Cliffs, NJ: Prentice Hall.

[Gilb94] Gilb, Tom. (1994). IDEA MANAGEMENT: The Results-Driven Quality Planning Method, Preliminary Paper.

[Jacobsen+92] Jacobsen, Ivar, Christerson, M., Jonsson, P. Overgaard, G. (1992). Object-Oriented Software Engineering A Use Case Driven Approach. New York: ACM Press.

[Kerth94] Kerth, Norman L. ``A Caterpillar's Fate: A Pattern Language for Transformation from Analysis to Design'', Proceedings of the First Conference on Pattern Languages of Programs, 1994.

[Love93] Love, Tom (1993) Object Lessons: Lessons learned in Object Oriented Development Projects. New York: SIGS Books.

[Odell94] Odell, James (1994) Paper - A Taxonomy for Business Rules.

[Pressman82] Pressman, Roger S. (1982) Software Engineering: A Practitioner's Approach. New York: McGraw-Hill.

[Retig94] Retig, Marc (1994) - Communications of the ACM April 94.

[Ross94] Ross, Ronald G. (1994). The Business Rule Book Classifying, Defining and Modeling Rules. Boston, Massachusetts: Database Research Group Inc.

[Schultz92] Schultz, Ron (1992) A Project Management Handbook for Object-Oriented Software Development. Berard Software Engineering, Inc.

[Wirfs-Brock93a] Wirfs-Brock, Rebecca (1993a). Smalltalk Report February 1993. Characterizing your objects pp. 7-9

[Wirfs-Brock93b] Wirfs-Brock, Rebecca (1993b). Smalltalk Report Nov-Dec 1993. Designing scenarios: making the case for a use case framework pp. 9, 10.