Skip to Content

What is the end product of the event decomposition technique?

The event decomposition technique is a method used in requirements engineering to break down a complex event into smaller, more manageable components. The end goal of event decomposition is to produce a set of coherent, independent sub-events that can each be addressed separately. This allows software developers to better understand the overall system behavior and design appropriate functionality.

Overview of Event Decomposition

Event decomposition involves analyzing a high-level event and repeatedly breaking it down into sub-events. The technique is often represented visually using a hierarchical diagram. The top level contains the overall event that needs to be decomposed. Underneath are layers of smaller sub-events that collectively comprise the parent event.

For example, consider the high-level event of “making a phone call”. This could be decomposed into sub-events such as:

  • Entering phone number
  • Pressing call button
  • Establishing connection
  • Conversation takes place
  • Ending call

Each of those sub-events could be further decomposed. “Entering phone number” includes sub-events like “pressing number keys” and “displaying digits”.

The decomposition continues until the resulting sub-events are simple and well-defined. At each level, the sub-events should combine to fully represent the parent event above them.

Goals of Event Decomposition

There are several benefits provided by breaking down events through decomposition:

  • Understandability – Decomposing a complex event into pieces makes it easier to comprehend the overall system behavior.
  • Testability – Simpler sub-events are easier to test and verify than a monolithic system.
  • Reusability – Common sub-events can potentially be reused in other parts of the system.
  • Maintainability – Localizing functionality into sub-events isolates changes needed down the road.

Event decomposition enables developers to methodically think through the steps needed to fulfill a high-level system event. It encourages creating a modular, maintainable system architecture.

When to Use Event Decomposition

This technique is applied during the requirements analysis phase of software development. It is most useful for complex, multifaceted events that are difficult to break down mentally. Candidates include events that:

  • Involve many steps or sub-processes
  • Cut across different parts of the system
  • Need to handle many edge cases or exceptions
  • Will evolve over time

Decomposing these intricate events helps generate cleaner, more stable requirements for the design team. It reduces ambiguity upfront rather than leaving the details to be solved during implementation.

Decomposition Process

While techniques vary, the general process for event decomposition includes:

  1. Identify candidate events – Select complex, unstructured events that would benefit from decomposition.
  2. Define parent event – Write a short description for the starting parent event.
  3. Identify sub-events – Brainstorm child sub-events that make up the parent event.
  4. Decompose further – Recursively decompose child sub-events until they are simple.
  5. Verify completeness – Check sub-events completely satisfy the parent event.

Subject matter experts should be consulted to ensure sub-events fully capture the nuances of the parent event. Traceability should be maintained up and down the decomposition hierarchy.

Decomposition Guidelines

There are some best practices that help guarantee an effective event decomposition:

  • Sub-events should embody a single, coherent action or task.
  • Overlap between sub-events should be minimized.
  • Sub-events should not have unclear or ambiguous meanings.
  • The decomposition should preserve any sequencing constraints.
  • Loops and iterations should be indicated if applicable.

Adhering to these principles results in sub-events that are independent, unambiguous units of work. They provide an appropriate level of abstraction from the technical details.

Examples of Event Decomposition

Here are some examples of decomposing common events using this technique:

Online Order Fulfillment

  • Customer places order
    • Customer adds items to cart
    • Customer checks out
    • Payment processed
  • Order routed to warehouse
    • Order info sent to warehouse system
    • Items reserved from inventory
  • Order shipped to customer
    • Order packed and labeled
    • Shipping label generated
    • Order transported to shipper

ATM Cash Withdrawal

  • Customer requests cash withdrawal
    • Customer inserts ATM card
    • Customer enters PIN
    • Customer selects withdrawal amount
  • ATM dispenses cash
    • Account balance checked
    • Withdrawal authorized
    • Cash counted out
    • Cash dispensed to customer

These examples illustrate how complex events can be recursively broken down into simpler steps. The sub-events are driven by the specific details of the overall process.

Event Decomposition Notations

There are a variety of notations used to depict event decomposition hierarchies. Some of the most common include:

  • Outline format – Hierarchical outline with nested bullets/numbering
  • Tree diagram – Parent and child events in a tree structure
  • Flowchart – Events in boxes linked with arrows to show sequence
  • IDEF0 – Box and arrow graphics per IDEF0 methodology

The decomposition may also be captured in a simple table with events and descriptions. UML activity diagrams can model the sequence of sub-events as well. The optimal notation depends on the complexity of the decomposition and intended audience.

Example Decomposition Tree Diagram

Here is an example of a tree diagram decomposing the event “customer makes purchase”:

Tree diagrams provide an intuitive way to visualize the hierarchy between parent and sub-events.

Strengths of Event Decomposition

Event decomposition offers several strengths as a requirements elicitation technique:

  • Improved understanding – Breaks down vague, unclear events into details that are precisely defined.
  • Scalability – Allows very complex events to be broken into manageable pieces.
  • Quality – Results in complete, consistent requirements when done properly.
  • Reusability – Common sub-events can be reused across decompositions.

By thoroughly decomposing complex events, hidden requirements and edge cases are revealed early in development. This leads to more robust systems and avoids oversights down the road.

Weaknesses of Event Decomposition

The technique also comes with some limitations:

  • Time consuming – Breaking down large events requires significant analysis effort.
  • Prone to errors – Improperly defined sub-events can undermine the decomposition.
  • Order dependence – Sub-events must be sequenced correctly to work.
  • Scalability issues – Extremely complex events become unwieldy to decompose fully.

Performing event decomposition well requires skill and practice. The rigorous attention to detail needed can make it labor intensive for very large events.

Alternatives to Event Decomposition

Event decomposition is not the only way to uncover requirements for complex system behaviors. Some alternatives include:

  • User stories – High-level user stories describing desired system interactions.
  • Use cases – Detailed flows defining how users interact with the system.
  • State models – Model system states and transitions between them.
  • Flowcharts – Visual diagrams outlining process steps and logic.

Each approach has tradeoffs in terms of complexity, precision, and suitability for different events. Event decomposition stands out when requirements need to be broken down to an explicit, granular level.

Conclusion

Event decomposition provides an effective method for unraveling the details within complex system events. Breaking down events produces modular sub-events that can be implemented and tested independently. This leads to cleaner requirements and more maintainable system architectures.

However, decomposition requires careful analysis to avoid misrepresenting the original event. When applied well, the technique reduces ambiguity, encourages reuse, and sets the stage for robust system design.