This chapter is from the book
This chapter is from the book
This chapter is from the book
Object Engineering Techniques
A technique is a systematic way of carrying out a complex task or procedure. Techniques are only useful if performed within an appropriate methodology. These techniques, however, can be applied within almost any methodology, including the light approaches of XP (extreme programming) and agile modeling.
I recommend the use of a hierarchy of techniques to aid in the construction information systems. These techniques include the development of a problem or opportunity statement, the specification of a context diagram, the 1-hour use case diagramming session, the development of three to five critical use cases, the CRC card modeling session, and the Abbott Textual Analysis.
Object technology and component-based systems should be concerned with 80/20 and just-good-enough development. The 80/20 development method is an iterative approach to systems development that initially attempts to discover and implement the 20 percent of the systems that contains 80 percent of the functionality. Typically, this critical 20 percent of the system consists of the mainline processing requirements of the users of the system, independent of error or exception conditions.
The initial iteration should consist of the three or four most important use cases together with the use case that involves the most difficult technical requirement of the system. Ideally, this first development iteration will demonstrate that the users' key requirements are understood and can be implemented by the developers. Most projects will probably involve three to nine iterations to fully develop the rest of the system. The upper limit of nine iterations would be found in life-critical systems that might have as many as 800 or more use cases, such as an air traffic control system or a major telecommunications organization.
I usually recommend that error handling and exceptional processing be deferred until the third iteration. The initial iterations are used to demonstrate quickly to the users that the system will be able to deal with their most urgent requirements, that we have assembled the proper team, that we have appropriate systems development and project management methodologies in place, that the system architecture is able to handle all of the operational constraints, and that the organization's learning curve maturity is appropriate to the object technology approach.
Problem or Opportunity Statement
A problem statement can describe in as little as 25 words of less "Why this system, and why now?" In any event, the problem statement should not exceed two pages in length. It should ignore implementation considerations, except in the case of the mandated use of a certain technology, vendor, or the inclusion of legacy systems into the new system. The problem or opportunity statement is used to prioritize the work that will be done on the new system in terms of how the work and work products will solve the organization's problem or how the work and work products will enable the organization to take advantage of a new opportunity.
The goal of the development team is to initially capture those 20 percent of the functional requirements that will supply 80 percent of the system. One effective way of identifying the critical 20 percent of the processes is to first develop a problem or opportunity statement and then use the problem statement to set system development priorities. Work should begin on those three to five use cases that go the furthest to solve the problem or meet the opportunity. An example of a problem statement for a new prescription drug control system would be "The health care industry is concerned that prescription drugs can be obtained with fraudulent or duplicate handwritten prescriptions."
The problem statement is usually developed with the project sponsor (the most senior manager who has the most to gain from the success of the new system) and then is reviewed and confirmed by all of the actors and stakeholders of the new system. The problem statement will be used to assign the development priorities of subsequently identified use cases. After the development of the problem statement, the next step is to develop a context diagram.
Context Diagram
A context diagram is a very high-level, black-box view of the new system that indicates all of the actors (people or systems that will actually use or touch the new system).
Use Case Diagram 1-Hour Brainstorm
One extremely powerful technique that can be quickly applied to any project is the 1-hour use case brainstorm. After the development of the problem statement and context diagram, all of the significant actors and stakeholders in the new system are invited to a 1-hour time-box session where they are asked to list all of the possible use case titles they can envision. The candidate titles are recorded as 3-word to 5-word verb phrases that describe how an actor would use the new system. At the end of the hour, the total number of titles is multiplied by 1.25 if the users seem to be very familiar with the requirements of the new system or by 1.5 if the users seem to be unfamiliar with the new system requirements. This new number of use cases is a very quick approximation of the final number of use cases that will make up the scope of the new system.
If there are expected to be more than 50 use cases, this is usually an indication that the project is too big for a single small team to develop within a 3-month to 6-month timeframe. The alternatives are to decrease the scope of the project or to employ multiple teams to work on the project in parallel. It is also possible that the use case titles were developed at too low a level of granularity. My rule of thumb is that the main course of events of the actual use case should fit on one page (about 8 to 16 sentences) and should contain 5 to 15 candidate classes. These candidate classes are nouns in the use case that refer to things and concepts in the business domain.
I have found it useful to develop a short description of each use case title in one of the following formats:
Three-sentence summary:
This use case begins when...
This use case does...
This use case ends when...
One-sentence summary:
Time sequence, actor, action, and constraint. For example, "At the end of the month, the accounts receivable clerk will prepare an aged accounts receivable report for all receivables outstanding for more than 30 days".
These summaries are used to quickly describe to all actors and stakeholders the expected functionality of the new system. I have found these summaries to be a very effective way of quickly explaining the functionality of the system.
Ivar Jacobson provides some guidance on the number of use case titles we can expect to encounter: "From our experience, a smaller system (2 to 5 man-years) might include something like 3 to 20 use cases. A medium sized system (10 to 100 man years) might include 10 to 60 use cases. Larger systems, such as applications for banking, insurance, defense, and telecommunications, may contain hundreds of use cases."1
Use Case Models
Ivar Jacobson describes the use case model (see Figure 8.1) as a representation of actors and use cases.
)
Figure 8.1 Jacobson use case model.
The actors represent what interacts with the system. They represent everything that needs to exchange information with the system. We differentiate between actors and users. The user is the actual person who uses the system, whereas an actor represents a certain role a user can play.
When a user uses a system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case.2
The use case model is the basis for identifying the domain object model, the analysis model, the design model, the implementation model, and the testing model. The use case becomes the documentation for the system. It eventually serves as the acceptance test of the system.
User-centered documentation techniques such as Ivar Jacobson's use case or Ian Graham's task case describe the services, responsibilities, and behaviors of a system from the point of view of a typical user of the system. Traditionally, system requirements have been described in terms of features and services from the point of view of the system. In practice, this traditional approach requires redundant and time-consuming activities of documenting the requirements, writing user training manuals, developing testing scenarios, and instituting change management and project management reporting procedures. Traditionally, systems development personnel have spent significant amounts of time trying to analyze and understand the user's current operations in the hope that this will somehow lead to the design of a new system.
Users already understand their current operations. What users need is a way to describe their new information system requirements to systems personnel who are experts in implementation. User-centered techniques can be used to produce in the first few hours or days of a project a single document that records the users' system requirements, the users' training manual, the users' test acceptance criteria, the users' change request form, and the users' key vehicle for project management planning and progress reporting.
Proper application of user-centered techniques can speed up system development and allow the users of the information system to be 100 percent involved in the specification, development, testing, and maintenance of their own systems. Errors in specification can be caught early in the systems development process when they are easy and relatively inexpensive to correct. Implementation begins immediately, starting with the most significant and most technically challenging of the user-centered. If implementation of these first critical parts of the system indicates that the rest of the system cannot be developed in an economical, efficient, and effective manner, the project can be modified or abandoned before additional resources are wasted.
I have found that an important part of the user-centered approach is the use of stimulus–response use case documentation. Each sentence of the basic and alternative courses of action in a use case should be written in "SVDPI" (subject–verb–direct object–preposition–indirect object) grammar. This grammar will result in short, active-voice sentences. The actor or user of the system always initiates the use case. All odd-numbered sentences are external "stimuli" to the system. All even numbered sentences are "responses" from the system. The use of stimulus–response sentences results in user-centered requirements documentation that is also the basis of the user training manual and the user test acceptance criteria, and the foundation of the work of the presentation interface team (since every stimulus–response sentence crosses the boundary between the user and the system, every stimulus–response sentence must relate to input and output data elements in the presentation interface). Stimulus–response sentences also form the basis of user help screens and can be used to develop questionnaires to collect and verify requirements from large groups of users.
In the following example, an ATM transaction demonstrates stimulus–response use case documentation. The odd-numbered SVDPI sentences are user stimuli, and the even-numbered SVDPI sentences are system responses. All sentences are independent of presentation interface technology. Every sentence crosses the user interface; therefore, every sentence is used by the presentation interface team as a work assignment for interface design. Even-numbered sentences are the features of the system.
|
Odd-Numbered SVDPI Sentences |
Even-Numbered SVDPI Sentences |
|
1. -The customer initiates the transaction with the system. |
2. The system requests the PIN from the customer. |
|
3. -The customer provides the PIN to the system. |
4. The system presents a service menu to the customer. |
|
5. -The customer selects a service from the menu. |
6. The system requests the account type from the customer. |
|
7. Etc. |
8. Etc. |
One very interesting technique I use to implement user-centered development is to videotape the JAD (Joint Analysis and Design) user presentation interface design sessions. Videotapes of these development sessions can be stored in streaming video format and embedded in the system documentation and code. These videos can be used by new team members and by maintenance personnel to quickly acquaint themselves with the key personnel in the project and the rationale for various design decisions.
Table 8.1 Use Case Template
|
Field |
Description |
|
Use Case |
Name of the use case. |
|
Actors |
All the different user roles and/or other systems that initiate the use case. |
|
Contact Person/Dept |
The name of the user who provided the information regarding this use case. This is especially useful for large corporations where team members may change during the middle of a project, or in the event the use needs to be further explained, or simply for accountability purposes. |
|
Name |
The person who recorded the information in this use case. |
|
Phone # |
The telephone number of the person who recorded the information in this use case. |
|
Summary |
A very brief description of what the use case is about. Use the threesentence or onesentence approach shown previously. |
|
Preconditions |
The necessary conditions that have to be met before the use case can be performed. The preconditions could be other use cases as well. |
|
Description (scenario) |
A detailed description of the interactions between the actor and the system. This is the basic course or the normal course that should be taken by the system if the system should perform as intended. |
|
Postconditions |
The state of the system after the use case is performed. |
|
Exceptions |
All the different alternative courses that can potentially be taken for various reasons—for example, if the preconditions are not met. |
|
Security Exceptions |
Any security considerations that need to be implemented while developing this use case. |
|
Related Use Cases |
List of other use cases related to this use case. |
|
Attachments |
Any attachments that need to be specified for this use case—for example, "IEEE std 8291983; standard for preparing a system test plan." |
Chandra Vemulapalli of the Advanced Software Technologies Group at WorldCom, Inc., developed the simple use case template detailed in Table 8.1 that I have found useful for small projects.
In my own work, I have developed a use case template (Figure 8.2) that can be used on any size project.
)
Figure 8.2 Typical Course of Events
)
Figure 8.2 Continued
)
Figure 8.2 Continued
)
Figure 8.2 Continued
)
Figure 8.2 Continued
)
Figure 8.3 Example of the template for an e-commerce application for placing
an order.
)
Figure 8.3 Continued
)
Figure 8.3 Continued