Question:
Someone has asked you to define the models nessesary for the System Analysis phase of the process. What Models would you suggest and where would they be created in the methodology we are using.
*Note to protect the innocent I have paraphrased the question.
Response:
For system analysis to succeed we must enter this phase of development with a strong understanding of what the business goals are and edit the phase with a complete understanding on how we are going to achieve that goal in a technology agnostic taxonomy.
A few choose quotes from a former mentor of mine are especially apt here so I am going to paraphrase them before I continue answering this question
- Software development is like asking a question and answering it.
- A complete set of requirements is the question. Without a complete question , you don’t know what you are answering
- Requirements should be unambiguous, understandable and testable. If you can’t test it how do you know you have met the requirement?
-Mentor (not going to use their name on a public site :-P)
System Analysis using our development methodology consists of Requirements analysis and Logical Design. By the time you exit Logical Design deliverables will include Business Data Requirements, Logical Data Model, Business Process Requirements, Logical Process Model, Business & System Interface Requirements and finally Logical Interface Model. But not all of these are models and some may include “mini” models as to support the text in the documents. Below is how I would break down the models across these two phases with more specificity.
Requirements Analysis: This phase will produce mostly documentation and not models, the documentation from this phase will be consumed to produce formal models. However some modeling will help support this documentation and make it easier to be understood.
- Use Case Models: Use Case models are representations at a fairly high level of a requirement. They employ graphics to represent Actors, actions, inputs and outputs.
- Sequence Diagrams: These diagrams can help describe how a process executes. The graphic representation of multiple separate processes and how they communicate and react to each other is the goal of this kind of graphic
- State Diagrams: These can describe the various states of a business entity, interface or process and how that state may change its properties.
Logical Design: The goal of Logical Design is take Business requirements and map them to a system. Maintaining a technology neutral stance these models may have the look and “feel” of what the system will do, they avoid implementation details or making decisions that could limit chooses during Decision Analysis. These models may also leverage more detailed versions of the above mentioned Use Case, Sequence and State models.
- Logical Data Model: This model describes all of the data needs of the application in maps that include field requirements and relationships. Logical Data Models are a lot like a dictionary of what specific business entity is.
- Logical Process Model: This model will be a series of flow charts, use cases models, sequence diagrams and other supporting material that turns business requirements into defined processes. The end result of a Logical Process Model is to define each specific process and describe how that process will flow, and how decisions in that process will change the outcome.
- Logical Interface Model: The interface model will help define how inputs and outputs will be parsed across the application. This will describe where data should be rendered and where it should be required. This may be described in State Diagrams, Screen mockups, and Logical Data Model based interface requirements with external systems.
So while I would have to make my describe these quickly, those 3 Logical Models and three types of supporting models are what I would present as required for the System Analysis of the application.
References
Whitten, Jeffery L., & Bentley, Lonnie D. (2008). Introduction to System Analysis and Design.New York: McGraw-Hill Irwin.
Fowler, Martin & Scott, Kendall (1999).UML Distilled Second Edition, A Brief Guide to the Standard Object Modeling Language. New Jersey: Addison-Wesley.