Diagrams

Task 1

I think that the problems caused by written communication is that the systems analyst cannot get their point across as well as they would be able to in a meeting. Meetings are better because you are in person so there is immediately more a relationship built because you are interacting, rather than reading a report written by a person. Also in writing you may be saying something a certain way in your head, but on paper it does not come across that way, so the people don’t get the full effect of what you are trying to show them. Another problem with written communication is that some people may find it harder to understand written documents than they do to understand someone explaining ideas in person. Also in meetings the systems analyst can show their enthusiasm and dedication much more to the panel than they could in just a written document, and this then leads to getting everybody more involved in the whole system which is a major advantage. In saying this though a written document could go well hand in hand with a presentation, but I believe that it should not be the sole way of communication.

Task 2

There are several different methods for a systems analyst to communicate with people other than written documents. One of these methods and probably the most common is Data Flow Diagrams (DFD’s) so I am not going to discuss this type. Instead I will give a some examples of other types of diagrams. In my research I have found a few other types of communication methods including:

Activity Diagrams – show the flow of activities through the system. They are read from top to bottom and have branches and forks to describe conditions.

Flow Charts – are quite common diagrams to use and show the process of the system in various types of boxes, connected up by arrows.

Event-driven Process Chains – are used to lay out business process workflows, using functions, connectors and events.

Use Case – shows use cases, actors, and relationships between them in the system.

Personally I like Use Case diagrams. The example below is from http://www.laynetworks.com/use%20case%20vs.%20dataflow%20diagram.htm (scroll down towards the bottom for the Use Case diagram)

The actors in Use Case diagrams are anyone or anything that interacts with the system. In this example the actors are the customer, bank officer and credit system. The customer is given 6 options to choose from, and depending on which option they select, another “actor” may come into play. For example if they wished to change their PIN then they select “Change PIN” and then the bank officer comes into play in order to help them achieve this, but if they just selected “View Balance” then the system would execute that without needing to go through any other “actors”. The advantage of this diagram is that the customers can look at this diagram and receive a great deal of information. By looking at the use cases, they will know what functionality will be included in the system. By looking at the actors, they will know exactly who will be interfacing with the system. By looking at the set of use cases and actors, they will know exactly what the scope of the project will be. This can help them identify up front any missing functionality. I think that this type of diagram has the detail required to show the business what the system will be doing, but it is also easy enough to understand within minutes of looking at it and studying it. For example the diagram above may be expanded if the Bank Officer is having trouble changing the Customers PIN, they may need to go to another “actor” being their supervisor or manager. This type of diagram in my opinion is much easy to understand, and as a result within a couple of minutes you could scan through and understand what functionality a large system will bring to customers and businesses.

Another type of diagram I would like to discuss is Activity Diagrams. They are made up of the following actions: Start, Fork, Branch, Merge, Join, End. All of the actions are joined by arrows which show the customer the direction the system is going. A Fork is used to indicate that after a certain activity, the next two activities will take place at the same time in parallel. The Branch is used when there are two activities, but only one will be executed, determined by a set of conditions. Merge is used to bring an end to the branched conditions, and then all parallel activities must be joined at the end by a Join. The example diagram below was obtained from http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/activity.htm (the first diagram on this web page)

The diagram above shows all of the actions in an Activity Diagram. After activity 1 is completed, there is a Fork so that activity 2 and 3 perform at the same time in parallel. After activity 2 there is a Branch so that either Activity 4 or activity 5 is completed, depending on certain conditions. Then after one of those is completed, they are Merged and are the Joined with activity 3 and then activity 6 can be performed.I think that the activity diagram is also very easy to understand. Once you know what each of the symbols mean, like Join, Fork, Branch and Merge, then you will again be able to go through a large systems activies and understand it all fairly quickly.

I think that these two types of diagrams would be my preferred ways of communicating as a system analyst to a panel of customers or businessmen, as I believe they are the easiest to understand, but also are easy to identify any missing functionality, and contain plenty of detail.