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:
Finding Business EventsThe 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. |