Use Case Concepts 201Review the Basics if NeededPlease see 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 ExploredIn 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!In Exceptions 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. In Preconditions 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 ExploredIn 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 ExploredIn 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
|
