Use Case Concepts 201
Review the Basics if Needed
Use Case Basics 101
to review the three fundamental concepts of the Building Requirements Consensus™ Methodology.
The intermediate concepts are organized around the three fundamental concepts.
Note: These intermediate concepts will help you the most after you understand and can apply the three fundamental concepts. We advise that you work on the basics before you apply these concepts for maximum effectiveness.
The Fundamental Concept Use Case Explored
In Alternative Flows
we discuss why the very concept of main and alternative flows is really a side effect from using text documentation. There is nothing inherent in UML specification that requires us to make this distinction!
we discuss how an exception is a way functionality fails to complete. It is not correct to call something that is recovered from an exception.
we discuss why preconditions and postconditions are not in compliance with the UML specification.
In Precondition Example
we discuss a commonly stated phrase that many analysts think is a precondition, namely "the user must be authorized". We show that this is not testable or feasible.
The Fundamental Concept System Explored
In ATM Example
we discuss in detail why the usual presentation of an ATM is so simplified that it teaches new adopters wrong concepts from the very beginning.
The case study in the next section discusses both roles and systems. We put it in the role section since they are featured more.
The Fundamental Concept Role Explored
In UC Diagram Abuse Example
we discuss how using roles as opposed to actors adds clarity and builds consensus while reducing ambiguity.
In Case Study - Part 1 of 3
we begin to describe the history of a financial Transaction Auditing Program (TAP) was put into production. Part 1 documents what happened when the Building Requirements Consensus™ Methodology was not used.
In Case Study - Part 2 of 3
we document what happened when the Building Requirements Consensus™ Methodology was used - a surprising discovery!
In Case Study - Part 3 of 3
we discuss the underlying architectural principle that is broken when actors are used. Using roles discovers undocumented requirements.
From Use Case Concepts 201 to
Building Requirements Consensus™ Home