In order to design a successful enterprise solution, you must not just look at an individual scenario, you must see the big picture. How does everything fit together? Can one process be improved by improving another process? Does improving communication between different parts of a workflow improve the overall workflow? Be creative, use your imagination. Perhaps one of the best sources of ideas is the brainstorming sessions in the second consensus meeting. Many great ideas will come out of this meeting. The reason I suggested writing down all suggestions, even ones that did not get a high ranking, is that sometimes an idea that seems stupid or just too risky at first, may turn out to be the best solution. The suggestions you gather at the consensus meeting are the creative ideas of the entire team, and more importantly, the people most familiar with the business processes. These are the people who are most likely to come up with the best solutions.
In the conceptual stage we take this a step further. We interview users to find out exactly what goals they need to achieve, how they currently achieve them and exactly how we can improve the ease and efficiency with which they can achieve them. The users are a great source for recommendations on how to improve processes. By reviewing their reasons why a process is poor, we can often see how to improve it. Based on this information we create scenarios and use case models for every third level goal identified in our Vision/Scope Document.
Thus we have a set of use case models based on the goals identified by the client and management (and refined by the whole team) along with detailed information about how exactly the user would interact with the system. By proceeding in this manner, we are well on our way to creating an application that will satisfy both business and user requirements. It is very important that the entire team stops focusing only on building components. Instead, they need to start viewing their coding as the fulfillment of one or more goals of the client. This shift in thinking is critical to producing Visual Basic applications that meet the expectations of the client.
In the next chapter the use cases will be analyzed for a description of the services the system must provide (identified by the verbs in our use case Flow of Events, such as create, update etc.) and in order to start to identify system components (prime candidates are the nouns in our use cases, such as Customer, Order etc.). However, we will see that before we can really identify which components we will need, we need to consider the framework within which they will operate.
Was this article helpful?