Build Event Models (Process Notes 2.1.9)


You are looking at the functional part of the system. Break the whole system into its constituent business events. We will use the term "event" to signify this partitioning as a convenient way to look at each of the system's functions.

The objective of partitioning the system into events is to provide a way of breaking up the system in a consistent and communicable way. Event partitioning is nothing more than a special knife for carving a system into logical, minimally related pieces. However, despite its simplicity, it gives you several advantages:

  • The events are minimally connected, so you can study isolated pieces without getting involved in all the details of the system.

  • Events can be readily measured using function points or other measuring methods. Thus it is easier to make estimates that are based on real measurements.

  • Management can use event partitioning to monitor progress.

  • The main benefit to the requirements process is that events allow you to separate the actions of the system, and deal with the system's functionality in a way that is familiar to your users.

Finding Business Events

The work context is the best place to identify events. All of the data flows that connect the system to the outside world are somehow part of an event. Start by looking for the adjacent systems that communicate with the work context. Each discrete business data flow connected to them is a potential event. Some of these will be simple data flows that have to be stored by the system. Others will be complex interactions with the adjacent system that persist until the piece of business has been completed.

Some of the data that flows from the system does so as a result of a temporal event. Use these data flows to identify more of the events. Ultimately, you must be able to account for all of the data flows that bound the system. The flows will either trigger an event or result from one. Some events have both input and output flows.

Once you have listed all the events, consider the functionality of each. It may be necessary to model some of the events to more clearly see the requirements. However, at this stage you should try not to get bogged down in detailed modeling. It is suggested that scenario models may be the tools that give you enough of a description for each function to write its functional requirements.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net