Systems Design:Problem Definition

From GSLISWiki

Jump to: navigation, search

Systems Analysis and Design: 1. Problem Definition | 2. Requirements Gathering / Requirements Analysis | Systems Design:Design | Systems Design:Development | Systems Design:Testing | Systems Design:Implementation | Systems Design:Maintenance


Contents

[edit] The Problem Definition Process

Before you can solve a problem, you must know what it is. Therefore the first step in doing Systems Analysis and Design is Problem Definition.

[edit] Understanding the Organization

To understand the problems an organization is having, you must first understand the organization itself.

  • What are the objectives of the organization?
  • How does the organization work?
  • How is it run?
  • What is the organizational culture?
    • Both general culture and major sub-cultures
    • When doing the requirements gathering you will delve more into the details of particular sub-cultures.

[edit] Identify the Problems

Now that you know a bit about the organization you are analyzing, you must identify the problems they are having.

  • Problem recognition occurs when actual outcomes fall below expected or desired outcomes.
    • This does not mean that there is a problem, it simply means that a perception of a problem exists.
  • In the process of Problem Recognition, one must clearly identify desires and expectations, and different people and different groups of stakeholders will have different desires and expectations which will contribute to their ability to perceive or recognize a problem.
    • It is important to keep all viewpoints in account, and to provide a means which different stakeholders can use to communicate with one another, so that a common definition of the problem can be agreed upon by all stakeholders.
    • Note: Facilitating communication is one of the most important things for which Scenario Based Design can be used.
  • How can the objectives of the organization be pursued/met?
  • Make the agreed upon problem recognition explicit in formally stated goals or problem definitions.

[edit] Determine the Cause of the Problems

Now that you know what the perceived problems are, you must figure out what is causing them.

  1. Identify and make explicit the symptoms of the problem.
    • How do you know there is a problem?
    • What is the measured discrepancy between expectations/desires and outcomes?
  2. Identify and make explicit multiple possible causes for the symptoms.
    • The goal is to find as many possible causes as possible.
    • If you have identified only one or two possible causes, you know that you are missing something.
  3. Draw cause and effect diagrams to make the relationships explicit and easy for non-systems analysts to understand. (Davis 1994, pp. 33-37)
  4. Fill in possible explanations for each cause.
    • These possible explanations should be phrased so that they are verifiable (testable or measurable).
  5. Investigate the possible causes and explanations for each cause to see where the problem may lie.
    • It is likely that a problem will have multiple causes, and each cause multiple explanations, so do not stop simply because you have verified a particular cause or explanation for a cause.
    • If you are left with symptoms which are not explained by any causes, or have causes for which you have found no reasonable explanations, it is an indication that you have missed something.
  6. Be ready to challenge a goal or problem definition if it seems to be unreasonable or invalid.

[edit] Outline a Strategy for Solving the Problems

Now that you know what is causing the problems, you need to develop a strategy that will help you figure out how to solve them.

  • Identify objectives which, if met, will solve the problem by addressing the causes and explanations for the causes which were identified.
  • When making objectives explicit, make sure to make them measureable, but avoid the temptation to suggest specific solutions to these objectives. At this point in the process, it is still too early to identify specific solutions with any accuracy.
  • Explicity identify how meeting these objectives will address the causes and the explanations for the causes.

[edit] Summarize the Findings of the Investigation with a Problem Statement

You've defined the problems, and identified what needs to change. Now you must present your data to your customers.

  1. List the symptoms of the problem as explicitly and in as much detail as possible.
  2. List the objectives.
  3. Estimate the scope of the project, and what resources will be required to complete the project.
    • This should be a first order approximation, and you should aim high to try and minimize the effect of any unexpected complications.

[edit] Larger Projects may Require a Feasibility Study

Large projects may be very time and resource intensive--more than what the organization you are trying to help will be able to afford. To figure out whether this is the case or not, so that time and money is not wasted devising a system which could never be implemented, a Feasibility Study is often required.

  • Technical Feasibility
  • Economic Feasibility
  • Operational Feasibility
  • See Davis (1994) page 43-46 for more detail.

[edit] Customer Sign-Off

Now the ball is in the customer's lap.

  • Presentation of the results of the investigation and problem definition to the customer.
  • The customer is the expert at this point in the process, and if they do not understand the problem statement, it is the analyst's fault.
  • Their sign-off is crucial, and is an indication that a shared understanding of the problems and the objectives for solving them have been reached.

[edit] Related Links

Retrieved from "http://www.gslis.org/wiki/Systems_Design:Problem_Definition"
Personal tools