Use Case Example:
Yearlong Case Study Shows
Role Solves Problems
that Actor Cannot - Part 3 of 3
What Is the Underlying Cause of These Problems?
During the TAP use case example, the underlying architectural principle of encapsulation was violated in the original way of thinking about the TAP use case example in Part 1. Wikipedia.org describes encapsulation this way:
“In computer science, the principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change) … The term encapsulation is often used interchangeably with information hiding.” What exactly was not encapsulated that should have been in TAP? In the diagrams that apply the methodology, it is clear that the job titles belong to the HR system and not the TAP system. The Human Resources department is responsible for defining job titles organization-wide. In the original requirements TAP knew about the job titles and the developers wrote code with that knowledge. Actually it was worse than that. The original requirements in this use case example forced the developers to deliver code that was fragile to be compliant with those requirements. This is demonstrated in the case study when code had to be rewritten simply because a new functionality was required by a person in a job title in Part 1. Contrast this with the ability of quickly documenting functionality applying the Building Requirements Consensus™ Methodology – without undesired side effects – when the TAP security person made his observation above in Part 2. The Building Requirements Consensus™ Methodology explicitly identifies the systems involved and explicitly defines the use case roles. A role is the relationship a user plays when interacting with a specific use case. It is an interface to the use case functionality from the perspective of the system the use case belongs to. Any other entity that has access to a role, remember – the role is an interface, can play the role. Now we have visual reminders to ask the right questions.
Frustrating Real Life Example with the Same Problem
If you have a web-enabled phone, you most likely have already experienced, or will likely soon experience, one these frustrating scenarios:
1) You call an organization to talk with a person whose extension you do not know. The automated answering system presents a directory option that you take. The directory service asks you to enter in the person’s last name. You type in the letters on your keypad only to be told that no one matches your entry.
2) You call your credit card company. The automated answering system asks the security question you answered previously “Enter the first four letters of the city of your birth.” You enter the four letters and are told your answer is incorrect. In both cases, you know the answer and you know you entered it correctly. You may even try it again with the same result. What is going on?
Encapsulation Is Broken!
The answer is that encapsulation is being broken!Automated answering systems were designed to respond to tone signals associated to specific keys on phones. After all, the phone keypad had remained stable for decades And it had three letters assigned to the numbers 2-9. However, web-enabled phones do not use the “standard” keypad. For example, on the “standard” keypad the letter C is on the 2 key but on a BlackBerry the letter C is on the 7 key. Automated answering systems were built having direct knowledge of the “standard” keypad layout instead of defining an interface. This broke encapsulation. There was no problem apparent until companies decided to sell phones with a different keypad layout. That exposed the design flaw in telephones that was being exploited by automated answering systems caused by broken encapsulation as the two scenarios above demonstrate. In a well-encapsulated solution, automated answering systems should not have direct knowledge of which letters are associated with specific keys. Note that the problem of broken encapsulation in telephones was there throughout the decades. It just wasn’t exposed until a new keypad came along.
TAP Use Case Example Case Study Conclusion
In the TAP use case example, analysts highjacked the term role and used to apply to job titles that do not belong to TAP the system they were documenting requirements for. Security was compromised and data was corrupted. Even the title of the Change Request Form, TAP Role Upgrade, uses the term role inaccurately. As a result, business users could not do their jobs properly, these “solutions” tied up BA and IT resources and the benefit streams from TAP and other projects were pushed back. When you use roles properly, you write requirements that enable systems to be designed and built that can respond to changes rapidly. If TAP had been built this way in the first place, even when the missed requirements were identified, the change would have been isolated to the security mapping instead of code modifications. The original “roles” were not related to use case functionality. They are not roles as defined by the UML definition and the Building Requirements Consensus™ Methodology. They definitely are not roles of any part of the TAP system. Instead, they belonged to an entirely different system. Therefore, those “roles” should never have been used in the first place when documenting requirements for the TAP system. The Building Requirements Consensus™ Methodology strongly recommends that you only use the term role to refer to interfaces to use cases, with a one-to-one mapping, that belong to the system you are writing requirements for. Requirements written this way add clarity because they explicit identify system boundaries to encourage asking the right questions and build consensus because the interfaces are visible to everyone involved. As we have seen, this use case example applies the Building Requirements Consensus™ Methodology to enable the discovery of missed requirements - unlike traditional use case practice.
From Use Case Example - Part 3 of 3 to Use Case Example - Part 1
From Case Study - Part 3 of 3 to Case Study - Part 2 of 3
From Case Study Part 3 of 3 to Use Case Concepts 201
|
