The descriptions of the Use Case format include a number of vague definitions and hand-wavery descriptions of certain fields. This needs to be rectified and normalized.
scope
According to Effective Use Cases by Alistair Cockburn, a scope is a "Design scope". The system under discussion. It has a number of levels:
Organization (Black Box)
Organization (White Box)
System (Black Box)
System (White Box)
Component
What do these correspond to in the PEGS system?
Initial thoughts:
The scope should be invisible to the user. Black Boxes correspond to User Stories, and Use Cases correspond to white boxes
Organization Black Box corresponds to Goals -> User Story
[ ] Which means Goals -> UseCase needs to be renamed to "Scenarios" and User Stories introduced.
Organization White Box corresponds to Goals -> Use Case
System Black Box -> System User Story
System White Box -> System Use Case
Component -> System User Story or Use Case
A System in PEGS is defined by a composition of Components, so it seems redundant
According to Fowler, a User Story is a degenerate Use Case.
In HoRaBa p. 129, A User Story is just a single unit of interaction.
In a Cockburn style Use Case definition, a "level" refers to the granularity or scope of the use case, describing the breadth and depth of the interaction between the user (or actor) and the system. Alistair Cockburn introduced a hierarchical structure for use cases, categorizing them into different levels to help organize and manage the complexity of system requirements. The levels are:
Cloud Level (Summary Level): This is the highest level of abstraction, focusing on the overall business processes and goals. It provides a big-picture view and is often used to outline the major goals of the system or project. For example, "Achieve customer satisfaction."
Kite Level (User Goal Level): This level describes the main goals or tasks that a user wants to accomplish using the system. It typically represents a complete interaction that fulfills a user’s primary objective, such as "Place an order."
Sea Level (User Goal Level): At this level, use cases detail the step-by-step interactions between the user and the system to achieve a specific user goal. This is often the most detailed level where the interaction steps are fully elaborated. For example, "Log in to the system" or "Make a payment."
Fish Level (Subfunction Level): These are more detailed use cases that describe smaller tasks or subfunctions that support higher-level use cases. They often represent parts of a larger user goal. For example, "Validate credit card" or "Check inventory."
Clam Level (Too Low Level): These use cases are very detailed and specific, often focusing on internal processes or low-level functions that might be considered too granular for typical use case documentation. They might describe very small system interactions or internal operations. For example, "Update database entry."
Like the above, the same question applies: What do these correspond to in the PEGS system?
goalInContext / 'contextOfUse`
See the description here. I think this is just the Goal.description
trigger
The action upon the system that starts the use case. How is this action referenced?
A Goal Level Use Case can be triggered by an Environment Component.
This implies that it must be an interface reference as the behaviors are not exposed. Users (Stakeholders aka Goal Components) can also trigger but this is only via defined FunctionalBehaviors at the goal level. A Stakeholder does not have an interface unlike System/Environment components.
[ ] This implies that there must be GoalBehaviors and SystemBehaviors.
Goal relationship
Cockburn unifies the name with the Goal. This doesn't seem appropriate for our purposes.
Overview
The descriptions of the Use Case format include a number of vague definitions and hand-wavery descriptions of certain fields. This needs to be rectified and normalized.
scopeAccording to Effective Use Cases by Alistair Cockburn, a scope is a "Design scope". The system under discussion. It has a number of levels:
What do these correspond to in the PEGS system?
Initial thoughts:
The
scopeshould be invisible to the user. Black Boxes correspond to User Stories, and Use Cases correspond to white boxesAccording to Fowler, a User Story is a degenerate Use Case. In HoRaBa p. 129, A User Story is just a single unit of interaction.
Additional description: https://www.informit.com/articles/article.aspx?p=26061&seqNum=3
levelIn a Cockburn style Use Case definition, a "level" refers to the granularity or scope of the use case, describing the breadth and depth of the interaction between the user (or actor) and the system. Alistair Cockburn introduced a hierarchical structure for use cases, categorizing them into different levels to help organize and manage the complexity of system requirements. The levels are:
Cloud Level (Summary Level): This is the highest level of abstraction, focusing on the overall business processes and goals. It provides a big-picture view and is often used to outline the major goals of the system or project. For example, "Achieve customer satisfaction."
Kite Level (User Goal Level): This level describes the main goals or tasks that a user wants to accomplish using the system. It typically represents a complete interaction that fulfills a user’s primary objective, such as "Place an order."
Sea Level (User Goal Level): At this level, use cases detail the step-by-step interactions between the user and the system to achieve a specific user goal. This is often the most detailed level where the interaction steps are fully elaborated. For example, "Log in to the system" or "Make a payment."
Fish Level (Subfunction Level): These are more detailed use cases that describe smaller tasks or subfunctions that support higher-level use cases. They often represent parts of a larger user goal. For example, "Validate credit card" or "Check inventory."
Clam Level (Too Low Level): These use cases are very detailed and specific, often focusing on internal processes or low-level functions that might be considered too granular for typical use case documentation. They might describe very small system interactions or internal operations. For example, "Update database entry."
Like the above, the same question applies: What do these correspond to in the PEGS system?
goalInContext/ 'contextOfUse`See the description here. I think this is just the Goal.description
triggerThe action upon the system that starts the use case. How is this action referenced?
A Goal Level Use Case can be triggered by an Environment Component. This implies that it must be an interface reference as the behaviors are not exposed. Users (Stakeholders aka Goal Components) can also trigger but this is only via defined FunctionalBehaviors at the goal level. A Stakeholder does not have an interface unlike System/Environment components.
[ ] This implies that there must be GoalBehaviors and SystemBehaviors.
Goal relationship
Cockburn unifies the
namewith the Goal. This doesn't seem appropriate for our purposes.References