A typical business function might contain several unique events each of which we want to end up as a component of a larger software application.

So how do we go from a table containing textual information to a specification which a developer can use?

The first step is to turn each business event into a model – either a use case fragment, a DFD fragment or any modelling language you might be working with.

The following event table describes three typical interactions a customer would have with their bank:

Each of these events can be drawn as a separate use case:

These individual use cases (use case fragments) are only half the picture however. Today developers don’t write individual software programs for each event, particularly when multiple events will have numerous common components e.g. database enquiry, ID validation, etc.

What we do want is to be able to combine use case fragments into a single use case. We do this by identifying and sharing common actors (in this example the customer):

While we still need to write individual descriptions for each use case, we’ve given the developer a concise package of functional requirements, offering them the best opportunity to write efficient and effective code.

For an example of writing formal use cases see the paper How to use Use Cases.

The post Use Case Fragments appeared first on IRM Training.

An event can be any activity, action or business process where the system under investigation needs to respond. In this approach to business analysis, once the scope of the system has been identified, the first deliverable is a table (a list) of events.

Event-based analysis aligns very well with UML and object-oriented development as both are based on how a system responds to an event. For example, use case diagrams model system responses when an actor initiates an interaction with a system.

Events can be of different types (external, time dependant, internal to a system) and requirements analysis begins with the identification and documentation of these events.

As mentioned, each event describes a condition – a piece of functionality. The system under development must have the capability to successfully process the event.

Each event can be thought of as a functional or non-functional requirement and a typical Business Requirements Document could contain dozens or even hundreds of individual events. Once we’ve defined an event we can further analyse and model the process itself using any one of a number of modelling techniques.

Try our course Modelling Requirements with Use Case & UML.

If you liked this article, you may also enjoy:

Data Modelling & Object Oriented Development

Use Case Fragments

Most Popular BA Techniques

The post Event-Based Analysis & Modelling appeared first on IRM Training.