Home > Articles > Software Development & Management > Object Technology

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.1Figure 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



Use Case

Name of the use case.


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.


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.


A very brief description of what the use case is about. Use the threesentence or onesentence approach shown previously.


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.


The state of the system after the use case is performed.


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.


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.2aFigure 8.2 Typical Course of Events

Figure 8.2bFigure 8.2 Continued

Figure 8.2cFigure 8.2 Continued

Figure 8.2dFigure 8.2 Continued

Figure 8.2eFigure 8.2 Continued

Figure 8.3aFigure 8.3 Example of the template for an e-commerce application for placing an order.

Figure 8.3bFigure 8.3 Continued

Figure 8.3cFigure 8.3 Continued

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020