Roles and Activities > Analyst Role Set > System Analyst > Develop Vision
One of the simplest ways to gain agreement on the definition of the problem, is to write it down and see if everyone agrees.
Ask the group: What is the problem?
Then ask the group again: What is the problem, really?
Donít accept the first statement of a problem. Continue to ask "why?" to find out what the problem "really" is.
Sometimes the group can be so focused on an envisioned solution that it is hard to get them to formulate what the underlying problem actually is. In such cases, it can be beneficial to explore the benefits of the solution, and then try to find the problems being solved by those benefits. You can then explore whether or not those problems are "real" problems in the organization. Common techniques used to find the problem behind the problem are brainstorming, fishbone diagrams and Pareto diagrams.
Depending on the domain expertise of the development team, identifying the stakeholders may be a trivial or a nontrivial step. Often, this simply involves interviewing decision-makers, potential users and other interested parties. The following questions are helpful:
Start to develop profiles of potential (or actual) users of the system. These will map to the roles of the human actors of the system being developed. Initial information on key users and their environment should be documented in the Vision document. If Business Modeling is being done as part of this project, or as a precursor to this project, the Business Use-Case Model and Business Object Model will provide valuable information in this area.
The system boundary defines the border between the solution and the real world that surrounds the solution. In other words, the system boundary describes an envelope in which the solution system is contained. Information, in the form of inputs and outputs, is passed back and forth from the system to the users that live outside of the system. All interactions with the system occur via interfaces between the system and the external world.
In many cases, the boundaries of the system are obvious. For example, the boundaries of a single user, shrink-wrap personal contact manager that runs on Microsoft Windowsģ are relatively well defined. There is only one user and one platform. The interfaces between the user and the application consist of the user interface dialogs that the user accesses to enter information into the system, and any output reports and communication paths that the system uses to document or transmit the resulting information.
It is usually very effective to use actors to define and describe the boundaries of the system. See Activity: Find Actors and Use Cases. Again, the Business Use-Case Model and Business Object Model may provide valuable information in this area if Business Modeling has been done.
There are a variety of sources of constraints to be considered. Much of this information may be documented in the Business Rules artifact. Following is a list of potential sources and questions to ask:
The information gathered here will be the initial input to the design constraints defined in the Supplementary Specifications.
With the whole group, work on easel charts and fill in the following template for each problem you have identified:
The problem of <describe the problem>
The purpose of this template is to help you distinguish solutions/answers from problems/questions.
The problem of: untimely and improper resolution of
customer service issues
Based on the benefits listed in your problems statements, develop a list of features you want in the system. Describe them briefly, and give them attributes to help define their general state and priority in the project (for more on attributes, see Activity: Manage Dependencies).
You should check the Vision at this stage to verify that your work is on track, but not review it in detail. Consider the checkpoints for the Vision document in Activity: Review Requirements.
Rational Unified Process