sysanal
Investing time and money into a computer or information system without a clear course of action can be expensive and wasteful. By taking some time to fully consider the issue at hand and pursue a disciplined approach to finding a practical solution, you greatly increase your odds of success and decrease costs. We call this process Systems Analysis.
Systems analysis is an important part of an overall approach to systems development.
The life of an information system follows a cycle. The classic development model is called the Systems Development Life Cycle, or SDLC.[1]
The Planning phase defines the primary issue (problem or goal) and performs a feasibility study. Here, you clarify the project scope, compare your best options, and come up with a plan.
The Analysis phase focusses on the issue, defined previously, and studies its role in the current (or proposed) system. The system is explored, piece by piece, in light of the project goals, to determine system requirements.
In the Design phase, a detailed model of the proposed system is created. Various components or modules address each of the requirements identified earlier.
During the Implementation phase, a working system is built from the design and put into use.
The Maintenance phase includes ongoing updates and evaluation. As changes are needed, the cycle repeats with more planning, analysis, and so on. We will take a closer look at the systems analysis phase next.
Essentially, in Systems analysis we answer the question, "What will you need to reach your goal?" In other words, "What are your requirements?"
A primary goal of this course is to help you develop your skills in requirements analysis.
Systems analysis helps you clarify your project needs and plan ahead in order to obtain and allocate critical resources.
The main idea here is …
If you don’t know what you need, how can you ask for it?
After completing an initial feasibility study to "determine if creating a new or improved system is a viable solution", proposing the project, and gaining approval from stakeholders, you may then conduct a systems analysis.
Systems analysis will involve …
breaking down the system in different pieces to analyze the situation, analyzing project goals, breaking down what needs to be created and attempting to engage users so that definite requirements can be defined.[2]
So, what, exactly, is "Systems Analysis"?
Putting these two ideas together, we have:
Systems analysis is a problem solving technique that decomposes a system into its component pieces for the purpose of the studying how well those component parts work and interact to accomplish their purpose.[5]
Systems Analysis and Design for the Global Enterprise
We perform this analysis by working through a series of five phases.
Systems Analysis[6] has its own series of phases. We will look at each of these one by one.
During Scope definition, we establish our system boundaries. In our Problem analysis phase, we identify the symptoms and causes. Our Requirements analysis determines our system goals. The Logical design phase models relationships within the system. And our Decision analysis evaluates the various alternatives.
So, do we mean by scope?[7]
Scope involves getting information required to start a project, and the features the product would need to have in order to meet its stakeholders requirements.
Scope (project_management)
Put another way, project scope defines the work to be done whereas product scope is concerned with the desired features and functions.
By being careful to define scope early on, we can be more watchful for scope creep.[8]
Scope creep is […] the incremental expansion of the scope of a project […], while nevertheless failing to adjust the schedule and budget.
Scope (project_management)
Problem analysis is critical. When we say, problem, we can also think goal, research question, or issue. If you don’t get this right, you can waste a lot of time and money solving the wrong problem or address a non-issue.
We can summarize the key points of problem analysis[9] as:
-
Define and clarify the problem (or issue)
-
What exactly are we trying to solve?
-
-
Determine the problem’s importance
-
How much does it matter?
-
-
Assess the feasibility of solving the problem
-
Do we have the resources we need?
-
-
Consider any negative impacts (unintended consequences)
-
What could go wrong?
-
-
Prioritize problems to solve (bottlenecks? low-hanging fruit?)
-
What are the most critical issues?
-
-
Answer: what, why, who, when, where, and how much?
-
Drill down into the problem with all kinds of questions to expose dependencies.
-
-
Find causes (especially root cause) and symptoms (effects)
-
What is really going on here?
-
There are several methods of root cause analysis, but one simple one is "Ask Why Five Times" …
… where you keep asking "Why? But, why? But, Why?" over and over again until there is a clear root cause that you can actually do something about.
A real example is mentioned in Ask Why 5 Times, Business Analysis Guidebook/Root Cause Analysis (wikibooks.org), where the US National Park Service was able to slow the rate of deterioration of the Jefferson memorial simply by changing the lighting schedule.[10]
This method may also be used in Requirements Analysis.
-
System and project requirements
EAR Analysis is all about listening.
Gather requirements by interviewing stakeholders. Observe how people currently do their work or use the system. Make sure the requirements are detailed, clear, unambigious, and comprehensive. Document the requirements as a list, in diagrams, or narratives.[11]
As an example, in Spring 2014, we held a meeting with our graduate students and asked them about what sort of computing needs they had. We had a discussion, listened to what they had to say, summarized the main concerns, and documented them.
-
Further elucidate Measurable goals
By continuing to ask questions like "Why? … Why? … Why? …", get more specific until the goals become quantifiable. Measured goals are easier to meet since you can measure your progress in achieving them.
Mission objectives determine the goals. Compare the stated goals against mission objectives to produce a small set of critical, measured goals.
-
Output: Requirements specification
This document will be used in the logical design phase to model the relationships within the system. So, it should be clear and thorough. The more specific and unambiguous this specification is, the easier it will be to design the system to meet the requirements.
One way to be more clear is to organize the requirements by type.
You may categorize requirements according to several important types:
Operational requirements are the utility, effectiveness, and deployment needs, with repect to practical use of the system within the overall operation. These are the customer Requirements.
Functional requirements are specific things the system must do.
Non-functional requirements are specific things the system must provide.
Architectural requirements define how the system must be structured, in other words, how the components must interrelate.
Behavioral requirements describe how users and other systems will interact with the system and how the system will respond.
Performance requirements define how well the systems needs to do things, measured in terms of quantity, quality, coverage, timeliness or readiness.
While there are other ways to group requirements, these are the most significant categories.
Another way to make requirements clear is through requirements modeling. Here is an example of modeling behavioral requirements with a Use Case Diagram.
Survey Data System
The behavioral requirements are stated in role goal format.
-
Researcher uploads survey.
-
Subject takes survey.
-
Subject uploads results.
-
Researcher downloads results.
Gramatically speaking, the role is the subject and the goal is stated as a verb and its object. Each of these requirements form the basis of a use case.
The Use Case Diagram is a standard means of showing these requirements pictorially.
Here, human actors are depicted as stick figures. These are the roles. The goal is the line connecting the role to a system activity or function, shown as an oval. In this example, the system is drawn as a box with the actors outside the box. The reason is that the system’s product scope was defined to be the electronic data system. The human actors interact with that system. The information flowing to and from an actor, as well as data flows within a system, will be modeled in the logical design.
Once system behaviours have been modeled from the perspective of user interaction, we can begin to model the internal workings of the system with the logical design.[12] The logical part means that this is an abstract representation of the system. Therefore, the system is modeled in terms of abstractions such as data flows, entities, and relationships. We model how the system will satisfy functional requirements such as inputs and outputs. To make the abstract more concrete, we make use of Graphical modeling techniques to produce graphics such as the Data Flow Diagram (DFD) and Entity Relationship Diagram (ERD).
For example, let’s consider a system which records the playlists of musical performances at a local pub. You will want to store which artist performs which song. The relationship between an artist and a song can be shown in a simple Entity Relationship Diagram. We start with the behavioral use case written as Artist performs Song. Then, using a standard set of symbols, we can produce this diagram.
The boxes represent entities and the line connecting them is the relationship. Here, the symbols indicate that there is a one-to-many relationship. This diagram is saying that exactly one artist performs one or more songs, (or doesn’t perform any).
Since this "system" describes only solo performers, you would want to model it differently to include groups of artists that perform more than one song. You would want a many-to-many relationship as well as other entities to represent the musical groups. Since there will by many performances, you will also want an entity to represent the performances.
The value of this type of diagram is that complex relationships can be mapped to a great level of detail. In fact, they can be used to automatically generate database schemas.
Several examples of these diagrams can be found in the Systems Analysis and Design turorial.
This tutorial[13] (PDF, HTML, MP4) provides several examples from a fictitious public health research study.
You will find several other real-world examples from actual public health research projects in that course repository.
These models and diagrams will help you make a very important decision. Before you go further in the system design process, you need to decide whether to buy a system or build one. Or you may consider building a system of components, some of which you might buy and others might be custom built. You will want to come up with a few of the best alternatives and present them to your stakeholders. In your case that might be your lab manager, principal investigator, or funding agency.
Your presentation will also include a Decision analysis to weigh the pros and cons of the various options against the requirements in order to help the stakeholders with their decision. You should conclude your analysis with a recommendation of your top choice and explain why this choice is the most compelling. Then you will want to get a decision, and the approval to continue, before you invest any more time on further analysis.[14]
The system development life cycle (SDLC) continues on to other phases, which we do not have time to cover here. However, we hope that this glimpse at the systems analysis phase has demonstrated the value of this approach in gathering and clarifying requirements that can be used to design and build an information system.