Event partitioning
Encyclopedia
The goal of event partitioning is to be an easy-to-apply systems analysis technique that helps the analyst organise requirements for large systems into a collection of smaller, simpler, minimally-connected, easier-to-understand ‘mini systems’ / use case
s. The approach is explained by Stephen M. McMenamin and John F. Palmer in Essential Systems Analysis. A brief version of the approach is described in the article on Data Flow Diagrams. A more complete discussion is in Edward Yourdon's
Just Enough Structured Analysis. The description focuses on using the technique to create data flow diagrams, but it can be used to identify use case
s as well.
The premise of event partitioning is that systems exist to respond to external events: identify what happens in the business environment that requires planned responses, then define and build systems to respond according to the rules of the business. In particular, a business system exists to service the requests of customers. A customer, in the jargon of the UML
, is an ‘actor
.’
The technique was extended with ‘non-event’ events by Paul T. Ward and Stephen J. Mellor
in Structured Development for Real-Time Systems: Essential Modeling Techniques.
s’. Each planned response may be modelled using DFD notation or as a single use case using use case diagram notation.
The basic flow within a process or use case can usually be described in a relatively small number of steps, often fewer than twenty or thirty, possibly using something like ‘structured English
’. Ideally, all of the steps would be visible all at once (often a page or less). The intention is to reduce one of the risks associated with short-term memory, namely, forgetting what is not immediately visible (‘out of sight, out of mind’).
Alternatively, using the notations of structured techniques, an analyst could create a ‘Nassi–Shneiderman diagram’. In the UML, the use case could be modelled using an activity diagram
, a sequence diagram
, or a communication diagram
. This could be problematic if there are many complex scenarios
of the use case; the analyst may wish to model all or most of the scenarios.
) into smaller ‘secondary use cases’ to keep the ‘parent’ primary use case smaller and simpler. These secondary use cases may prove to be reusable as well. (In a UML use case diagram
, they would be drawn as extended or included use cases, which are related to one or more primary use cases.)
While describing a use case, an analyst may also uncover ‘business rule
s’. Some analysts suggest capturing business rules in a separate document using the Object Constraint Language
or some other formal notation. Then when a business rule must be obeyed in a use case, the analyst makes reference to it. This minimises repetition within a specification, but risks fragmentation of a specification. One technique that may reduce this tension is to use hyperlink
s in the specification document.
In addition to functional requirements
captured in a use case description, an analyst may include such non-functional requirements
as response time, learnability, etc.
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
s. The approach is explained by Stephen M. McMenamin and John F. Palmer in Essential Systems Analysis. A brief version of the approach is described in the article on Data Flow Diagrams. A more complete discussion is in Edward Yourdon's
Edward Yourdon
Edward Nash Yourdon is an American software engineer, computer consultant, author and lecturer, and pioneer in the software engineering methodology...
Just Enough Structured Analysis. The description focuses on using the technique to create data flow diagrams, but it can be used to identify use case
Use case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
s as well.
The premise of event partitioning is that systems exist to respond to external events: identify what happens in the business environment that requires planned responses, then define and build systems to respond according to the rules of the business. In particular, a business system exists to service the requests of customers. A customer, in the jargon of the UML
Unified Modeling Language
Unified Modeling Language is a standardized general-purpose modeling language in the field of object-oriented software engineering. The standard is managed, and was created, by the Object Management Group...
, is an ‘actor
Actor (UML)
An actor in the Unified Modeling Language "specifies a role played by a user or any other system that interacts with the subject.""An Actor models a type of role played by an entity that interacts with the subject ,...
.’
Actor → Event → Detect → Respond
The method has the following steps.- 1. Identify the external systems by brainstormingBrainstormingBrainstorming is a group creativity technique by which a group tries to find a solution for a specific problem by gathering a list of ideas spontaneously contributed by its members...
a list of the ‘actors’ (external systems), which are the sources of external events. If you find a graphic to be helpful, create a context diagramSystem context diagramA System Context Diagram in software engineering and systems engineering is a diagram that represents the actors outside a system that could interact with that system. This diagram is the highest level view of a system. It is similar to a Block diagram...
showing the actors outside of the system under study and the flows/signals between them.
- 2. Putting oneself in the shoesEmpathyEmpathy is the capacity to recognize and, to some extent, share feelings that are being experienced by another sapient or semi-sapient being. Someone may need to have a certain amount of empathy before they are able to feel compassion. The English word was coined in 1909 by E.B...
of an ‘actor’ (or working with actor representatives), brainstorm a list of the ‘external events’ / ‘triggers’ that they want the system to have a planned response to. (Note that the system cannot originate external events; only an actor can.) - 3. Identify what will enable the system to detectDetection theoryDetection theory, or signal detection theory, is a means to quantify the ability to discern between information-bearing energy patterns and random energy patterns that distract from the information Detection theory, or signal detection theory, is a means to quantify the ability to discern between...
the external events:- the arrival of one or more pieces of data (possibly in the form of a message)
- the arrival of one or more points in time
- 4. Identify the plannedPlanA plan is typically any diagram or list of steps with timing and resources, used to achieve an objective. See also strategy. It is commonly understood as a temporal set of intended actions, through which one expects to achieve a goal...
response(s) that the system may carry out when the events occur. It’s the response(s)/use case(s) that will enable the system to achieve its goals.
The technique was extended with ‘non-event’ events by Paul T. Ward and Stephen J. Mellor
Stephen J. Mellor
Stephen J. Mellor is a computer scientist, developer of the Shlaer-Mellor method and signatory to the Agile Manifesto.Together with Sally Shlaer he founded Project Technology in 1985. That company was acquired by Mentor Graphics in 2004....
in Structured Development for Real-Time Systems: Essential Modeling Techniques.
Identifying Requirements and Their Reasons
The event-response information may be captured in a table. The event is the raison d’être for the response, which gives ‘traceability’ from the response back to the environment.| 1. Actor | 2. External Event / Trigger | 3. Detected by | 4. Response(s) / Use Case(s) |
|---|---|---|---|
| Guest | Guest requests a room of a certain type, for a particular arrival date, departure date, at a certain rate, etc. | booking request + (payment validation) + (*external reservation system* booking confirmation) |
Book Room (may include guaranteed booking, alternate hotel booking, waitlisted booking) |
| Guest | Guest asks to cancel room booking. | cancellation request | Cancel Booking |
| Guest | Guest arrives at hotel. | arrival message = * * = [guest name ; booking reference] |
Check in Guest |
| Time / Scheduler | Guest fails to arrive at hotel. [This is a ‘non-event’ event.] | 11 pm (local time) [A ‘non-event’ event is detected by the arrival of a point in time, a deadline.] | Create Guest Bill, Update Booking |
| Guest | Guest asks to check out of hotel. | check-out request = * * = [guest name ; room number] |
Create Guest Bill, Update Room Occupancy |
| Time / Scheduler | Guest fails to check out of hotel. [This is a ‘non-event’ event.] | 11 am (local time) [A ‘non-event’ event is detected by the arrival of a point in time, a deadline.] | Create Guest Bill |
| Guest | Guest offers payment of bill. | payment vehicle = * * = [cash ; cheque ; credit card ; debit card] + (guest id) |
Accept Guest Payment |
| Time / Scheduler | Time to prepare Room Occupancy Report for previous night. | 8 am (local time) | Report on Room Occupancy |
| Hotel Manager | Hotel Manager requests Room Occupancy Report. | occupancy report request | Report on Room Occupancy |
| Smoke / CO Alarm | Alarm detects smoke. | smoke alarm message | Report Smoke Alarm |
| Smoke / CO Alarm | Alarm detects CO (carbon monoxide). | CO alarm message | Report CO Alarm |
Defining requirements
This approach helps the analyst to decompose the system into ‘mentally bite-sized’ mini-systems using events that require a planned response. The level of detail of each response is at the level of ‘primary use caseUse case
In software engineering and systems engineering, a use case is a description of steps or actions between a user and a software system which leads the user towards something useful...
s’. Each planned response may be modelled using DFD notation or as a single use case using use case diagram notation.
Structured English
Structured English is the use of the English language with the syntax of structured programming. Thus structured English aims at getting the benefits of both the programming logic and natural language...
’. Ideally, all of the steps would be visible all at once (often a page or less). The intention is to reduce one of the risks associated with short-term memory, namely, forgetting what is not immediately visible (‘out of sight, out of mind’).
Alternatively, using the notations of structured techniques, an analyst could create a ‘Nassi–Shneiderman diagram’. In the UML, the use case could be modelled using an activity diagram
Activity diagram
Activity diagrams are graphical representations of workflows of stepwise activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system...
, a sequence diagram
Sequence diagram
A sequence diagram in Unified Modeling Language is a kind of interaction diagram that shows how processes operate with one another and in what order. It is a construct of a Message Sequence Chart....
, or a communication diagram
Communication diagram
A communication diagram in the Unified Modeling Language 2.0, is a simplified version of the UML 1.x collaboration diagram.UML has four types of interaction diagrams:* Sequence diagram* Communication diagram* Interaction overview diagram...
. This could be problematic if there are many complex scenarios
Scenario (computing)
In computing, a scenario is a narrative describing foreseeable interactions of types of users and the system. Scenarios include information about goals, expectations, motivations, actions and reactions...
of the use case; the analyst may wish to model all or most of the scenarios.
Complexity versus fragmentation
If the response is lengthy or complex (i.e., more than a page of text), an analyst may decompose (‘factor out’ or deduplicateDeduplication
The term deduplication refers generally to eliminating duplicate or redundant information.* Data deduplication, in computer storage, refers to the elimination of redundant data...
) into smaller ‘secondary use cases’ to keep the ‘parent’ primary use case smaller and simpler. These secondary use cases may prove to be reusable as well. (In a UML use case diagram
Use case diagram
A use case diagram in the Unified Modeling Language is a type of behavioral diagram defined by and created from a Use-case analysis. Its purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals , and any dependencies between those use...
, they would be drawn as extended or included use cases, which are related to one or more primary use cases.)
While describing a use case, an analyst may also uncover ‘business rule
Business rule
A Business rule is a statement that defines or constrains some aspect of the business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business. Business rules describe the operations, definitions...
s’. Some analysts suggest capturing business rules in a separate document using the Object Constraint Language
Object Constraint Language
The Object Constraint Language is a declarative language for describing rules that apply to Unified Modeling Language models developed at IBM and now part of the UML standard. Initially, OCL was only a formal specification language extension to UML. OCL may now be used with any Meta-Object...
or some other formal notation. Then when a business rule must be obeyed in a use case, the analyst makes reference to it. This minimises repetition within a specification, but risks fragmentation of a specification. One technique that may reduce this tension is to use hyperlink
Hyperlink
In computing, a hyperlink is a reference to data that the reader can directly follow, or that is followed automatically. A hyperlink points to a whole document or to a specific element within a document. Hypertext is text with hyperlinks...
s in the specification document.
In addition to functional requirements
Functional requirements
In software engineering, a functional requirement defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs ....
captured in a use case description, an analyst may include such non-functional requirements
Non-functional requirements
In systems engineering and requirements engineering, a non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or...
as response time, learnability, etc.