Page 127 - DCAP308_OBJECT_ORIENTED_ANALYSIS_AND_DESIGN

Unit 10: System Conception

10.2 Preparing a Problem Statement Notes

A problem statement is a clear concise description of the issues that need to be addressed by a
problem solving team and should be presented to them (or created by them) before they try to
solve the problem. When bringing together a team to achieve a particular purpose efficiently
provide them with a problem statement. A good problem statement should answer these
questions:
1. What is the problem? This should explain why the team is needed.

2. Who has the problem or who is the client/customer? This should explain who needs the
solution and who will decide the problem has been solved.
3. What form can the resolution be? What is the scope and limitations (in time, money,
resources, and technologies) that can be used to solve the problem? Does the client want a
white paper? A web-tool? A new feature for a product? A brainstorming on a topic?
The primary purpose of a problem statement is to focus the attention of the problem solving
team. However, if the focus of the problem is too narrow or the scope of the solution too limited
the creativity and innovation of the solution can be stifling.
The development of a software system is usually just a part of finding a solution to a larger
problem. The larger problem may entail the development of an overall system involving
software, hardware, procedures, and organizations. Object oriented programming languages
provide a powerful tool for building flexible and extensible software components. However,
maximum benefits are gained only if the software is appropriately designed. The choice of
classes, and the distribution of tasks between the objects, is of crucial importance.

Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a
conceptual model of the information that exists in the area being analyzed. Analysis models do
not consider any implementation constraints that might exist, such as concurrency, distribution,
persistence, or how the system is to be built. Implementation constraints are dealt with during
object-oriented design (OOD). Analysis is done before the Design.
OOA specifies the structure and the behaviour of the object that comprise the requirements of
that specific object. Different types of models are required to specify the requirements of the
objects. These object models contain the definition of objects in the system, which includes: the
object name, the object attributes, and the objects relationships to other objects. As you know, an
object is a representation of a real-life entity, or an abstraction.
For example, objects in a flight reservation system might include: an airplane, an airline flight,
an icon on a screen, or even a full screen with which a travel agent interacts.
The sources for the analysis can be a written requirements statement, a formal vision document,
and interviews with stakeholders or other interested parties. A system may be divided into
multiple domains, representing different business, technological, or other areas of interest, each
of which are analyzed separately.
The result of object-oriented analysis is a description of what the system is functionally required
to do, in the form of a conceptual model. That will typically be presented as a set of use cases, one
or more UML class diagrams, and a number of interaction diagrams. It may also include some
kind of user interface mock-up.
Many project teams make the mistake of trying to the analysis and design for all the system
usage scenarios before and coding begins. This if often referred to as “big design up front” or
BDUF. The problem with BDUF is that in any product design process there is a chance you will
get it wrong. Without meaningful testing and feedback, your ultimate design is likely to be very

LOVELY PROFESSIONAL UNIVERSITY 121