Thoughts on Chapter 6

Chapter 6 of our book discussed different types of requirements modeling used in development. The chapter specifically emphasized use case diagrams, use case descriptions, activity diagrams, system sequence diagrams and statechart diagrams. The different diagrams are used to represent different aspects of the system with varying levels of detail. Another purpose of using multiple diagrams and descriptions is so that users and other non-technical stakeholders can have multiple perspectives for understanding how the analysts intend the system to function. The variety of diagrams and descriptions helps cater to different learning styles such as drawings for visual learners or highly detailed written descriptions for users who learn by verbal or written communication.

Learning about the different diagrams and their purposes led me to evaluate which diagrams prove to be the most effective for myself in conveying information. I personally think that the verbal/written descriptions found in the fully developed use case description would benefit me most in understanding the purpose of a specific use case. I liked the high level of detail found in the use case description and I feel like it specifically states information for users that otherwise could be neglected or misunderstood in a drawing diagram. While I think I prefer written descriptions, I also found diagrams to be very beneficial as well especially when used for a snapshot of a simple process or a particular process that would be difficult to describe in words. I believe I would prefer a detailed description of complex use case when applicable rather then solely a diagram but I definitely see the how diagrams are beneficial. The use case and activity diagrams were my favorite type of diagrams we have studied. I feel that they are very direct in describing what is occurring and could be interpreted fairly easily by all levels of users. I found the statechart to be the most confusing diagram type so far. Simple statecharts make sense and are easy to understand but I have found that more involved statecharts are difficult for me to draw accurately. I feel I have done a fairly good job at interpreting the statecharts we have gone over so far but I do not have the same degree of confidence in interpreting them as I do for activity or use case diagrams.

Certain diagrams we have studied have specific purposes and in some instances may be required. I believe it is important though to try to understand the different learning styles users or stakeholders may have and when possible adapt diagrams and descriptions accordingly. Creating diagrams and descriptions in way the user understands helps them to better communicate how they want the system to operate and can in turn save the analyst time in the long run.