7 STEPS FOR BUILDING AN INFORMATION SYSTEM By: David Chilcott Outformations, Inc

1. STEPS FOR
BUILDING AN
INFORMATION
SYSTEM
By: David Chilcott Outformations, Inc
By : Sheryle Domingo
DM 216 - Information Technology Management
Masters in Development Management
PSU-Urdaneta Graduate School

2. DEFINITION OF TERMS
Actor – Description of the ROLE with which a
stakeholder interacts with the system. An
object representing an external agent, human
or mechanical, with which the system must
interact.
Analysis – An act of exploring the problem
domain to gain a better understanding of the
problem

3. Controller (MVC) – The goal of the MVC design
pattern is to separate the application object
(model) from the way it is represented to the
user (view) from the way in which the user
controls it (controller)
Design – The mapping of an analysis onto a
selected architecture to create a software
solution to a problem.
Domain – A coherent body of knowledge, rules,
and definitions, related to a particular subject.

4. Domain Model – The collection of “objects” (classes) that
represent the real-world things and concepts related to
the problem domain that the system is being designed to
solve.
Functional Interface Prototypes – An interface mockup
that displays the functional components/objects but not
necessarily using the final “look and feel” or esthetic
design. Used to capture business rules and other design
information such as the order and validation of fields or
the interface behavior required to fulfill a particular use
case.

5. Interface – The point of an interaction or
communication between a computer and any other
entity, such as a printer or human operator.
Interoperability – The ability of two or more systems
or components to exchange information and to use
the information that has been exchanged.
Use Case – Describes a particular, observable, system
behavior from the perspective of the Actor using the
system. A complete “unit” of system functionality
which describes the user’s interaction with the
system with a defined beginning and end.

6. INTRODUCTION:
The Outformations 7-Step Development Process originated
out of a desire to create a simple, clear, and understandable
way for project teams to work together to build information
systems that actually solve the problems they are supposed to
address.
Originally it was based, in large part on thinking done by a
former partner, Kenneth Tyler. At the time we were exploring
the use of CRC cards as a tool for uncovering and exploring
system requirements. Kenneth’s key insight was the step-wise
fashion that information at each level informs the steps above
and below it. In addition, some of the text below comes from
early drafts of this document.

7. CONTEXT:
The following concept and assumptions are important to
understanding our development process. It is believed that any
methodology that integrates these ideas substantially improves
the likelihood of building a successful Information System.
• Assumption/Definitions – Make them as explicit as possible
• Projects – Organize work into chunks to help you manage
them. One of the most important issues is setting the
boundaries of these “chunks”. This is also known as defining
and agreeing on the project’s scope.

8. •Discovery – Should be encouraged and
supported throughout the life of a project. It is
simply not possible to foresee all possibilities
because of the complexities involved.
• Process/Iteration – A process is defined as
a series of actions, changes, or functions bringing
about a result. An iteration is a process or
procedure in which the desired result is
approached through a repeated cycle of
operations, each

9. SCOPE OF PROJECT:
1. Extent of perception,
knowledge,
experience, or ability.
(Does the project team
have what’s necessary to
complete the work?)
2. The area or sphere
in which an activity
takes place.
3. The full extent
covered: within range
of possibilities.
(Do we understand
enough about the
domain in which the
system will operate)
(Will the design of our
system adequately
resolve the issues or
problems?)

10. Assumptions
• Hard Work – IS are hard to build and maintain. Modern
software development is a complex, expensive, and
levels of sophistication.
• Different Points-of-View – people come to the task of
building an IS w/ different perspectives, interests, and
levels of sophistication.
•Models – Use diagrams, charts, maps, and other
artifacts to help understand the world and each other.

11. •Communication, Shared Understanding,
and Agreement – most IS project problem
errors are the result of failures of
communication or a lack of shared
understanding or agreement.
• Conversation – People already have a
very effective mechanism for developing
shared understanding and agreement.

12. THE 7-STEP DEVELOPMENT PROCESS
1. IDENTIFY AND LIST STAKEHOLDERS
2. IDENTIFY AND LIST ACTORS
3. IDENTIFY AND LIST USE CASES
4. IDENTIFY AND LIST SCENARIOS
5. IDENTIFY AND LIST STEPS
6. IDENTIFY AND LIST CLASSES/OBJECTS
7. MANAGE WORK PRODUCTS

13. STEP 1: IDENTIFY AND LIST STAKEHOLDERS
The persons, entities, or systems that participates in
THIS system. Include all the people who have the power
over the system and all the people whose power and
position are affected by the system. Include the people who
will use the system.
Example of Information to capture using CRC card model.
Example of Information to capture using CRC card model.

14. One of the other important early work products that
should be developed here, after identifying stakeholders is
the
Problem Statement. This is a statement of the motivation
for developing the system from the stakeholders’
perspective(s). The Problem Statement provides the
reasons for creating the application, as opposed to what
the application must do functionally. The discussion
fostered by reaching for agreement about the Problem
Statement among stakeholders is useful for uncovering
missing pieces or hidden assumptions about the system in
question.

15. STEP 2: IDENTIFY AND LIST ACTORS
Actors are abstractions that allow you to gather the
system’s stakeholders into convenient groups. Each group is
modeled as wanting to use the system in certain ways. One way of
looking at ACTORS is as a way of describing a set of expectations
of the system. Once you have modeled the Actors and their Use
Cases you can compare these descriptions to what the actual
stakeholders say they want.
Building the model of a set of Actors lets you present to
those stakeholders your idea of exactly what the system will do for
them. It also lets you identify new expectations rapidly when they
arise during the course of development. One value of having an
explicit model of the system’s uses is that it forces many of the
unconscious demands out of hiding.

16. Complete list of Actors would be a concordance of all roles
played by all of the stakeholders who interact directly with
the system.
Example CRC card

17. STEP 3: IDENTIFY AND LIST USE CASES
Description of a complete interaction that an Actor makes with
the system, from start to finish. Each Actor can have one or more
uses they make of the system. A Use Case is a model of a one
complete cycle of interaction between an Actor and the System,
that has a defined beginning and a defined end. Use cases are an
organized way to think about what the system is expected to do for
certain kind of users. It answers the question: “What useful
services does a stakeholder reasonably expect the system to
provide?”
They present a complete view of a system in terms of the
functionality it provides. The descriptions of the use case steps can
be the basis for the user’s manual. Use cases can also be used to
capture future ideas for a system as well as the functions that will
be built into the current version. Use cases also provides a
meaningful way to manage and organize the entire development
effort.

18. THREE PHASES IN THE SYSTEM DEVELOPMENT LIFECYCLE
DISCOVERING
/SCOPING
ANALYSIS
The
emphasis is on
discovering all of the
Stakeholders, Actors, and
Use Cases. This early
discovery and naming is
extremely important. It sets
the context and language
used
throughout
the
remaining
development
effort. Provides with the
materials
needed
to
develop our initial estimate
of development schedule
and cost.
During the analysis pass we
focus on defining and
detailing the business and
system functionality by
listing the Scenarios and
Steps in general. At this
level we’re adding enough
detail to the use cases to
describe the necessary
business rules and highlevel relationships between
system components, but
should be implemented
independently
DESIGN
During the design pass we
cross over into
implementation details and
decisions. Our use case
details may include
references to screen
mockups, robustness
analysis models, or links to
any other design artifact
that communicates
important information. Our
use case model can also be
around each use case or set
of related use cases
(package).

19. STEP 4: IDENTIFY AND LIST SCENARIOS
Description of the sequence of steps needed to complete a Use Case.
Each use case can be broken down into a number of steps that the Actor
goes through to execute it. Most use cases will have more than one pathway
of steps that the Actor can follow to achieve their end. These different ways
that the Use Case can play out are called “Scenarios”. Each use case should
have a normal scenario defined that describes its execution when
everything goes as intended. Any significant exceptions or variations should
have their own scenarios as well.
For example if the use case is creating an invoice for a sales transaction
using a credit card, the if the customer fails the credit check the scenario
may require that the payment be in cash.

20. DISCOVERING
/SCOPING
During the
discovery/scoping pass we
limit our focus to identifying
the primary or “normal”
scenarios and any obviously
significant, important, or
high risk scenarios for each
use case. Our deliverable
would include a scenario
name and a short 1-3
sentences summary or
overview descriptions of
these important variations.
ANALYSIS
During the analysis pass we
focus on providing more
definition and details for
our identified scenarios. We
also add scenarios that have
been identified during the
course of our other
discovery or analysis efforts.
This would be the time to
use refactoring to create
reusable “abstract” or
“utility” scenarios (and use
case)
DESIGN
During the design pass we
focus on defining and
detailing the steps for all of
the currently identified
scenarios.

21. STEP 5: IDENTIFY AND LIST STEPS
Detailed description of the steps needed to
complete a Scenario.
The user’s progress through each scenario is
modeled as a series of steps. As we develop all the
scenarios for each use case in detail we may find that
we need to return to some of them to add, subtract, or
change the order of steps. It is also possible for a
particular step in one use case to call or invoke another
use case.

22. DESIGN
DISCOVERING
/SCOPING
During
the
discovery/scoping pass
we create a preliminary
list of steps for each
scenario. One technique
for validating these
steps is to do a “walkthrough”
of
each
scenario.
ANALYSIS
During the analysis pass
we focus on defining
and
detailing
the
interaction between a
user and the system. We
recapture the sequence
of user actions and
system responses that
together comprise the
steps of the Use Case.
During the design pass
we focus on designing
the functional interface
prototypes and
completing the
Robustness Analysis for
each step. T his is the
activity of analyzing the
narrative text of use
case and identifying a
first-guess set of objects
that will participate in
each USE CASE.
1.Boundary Object
2.Entity Object
3.Control Object

23. STEP 6: IDENTIFY AND CLASSES/OBJECTS
Detailed description AND/OR MODELS OF THE DESIGN AND
IMPLEMENTATION OF THE METHODS AND PROPERTIES NEEDED TO
COMPLETE A STEP. Can be organized into Interface, Controller, and Entity
Classes using diagramming notation.
In order to execute each step in a Use Case the System requires the use
of Internal objects. From the description of the steps and the Robustness
Analysis conducted in the design pass of Step 5 we can derive the properties
and methods of those objects necessary to complete each individual step.
List only the objects necessary for that step and the methods and properties
of those objects that must be revealed for that one step to be completed.

24. DISCOVERING
/SCOPING
During the discovery/scoping
pass we focus on defining
and detailing the Domain
Model. This is the collection
of “objects” that represent
the real-world things and
concepts related to the
problem domain that the
system is being designed to
solve. It is important to
distinguish this type of
“object-model” from other
more formal UML based
object models.
ANALYSIS
During the analysis pass we
focus on defining and detailing
the objects identified during
the Robustness Analysis in the
design phase of the previous
step. We focus on those objects
that are required to actually
implement the Use Cases
identified during discovery. At
this stage we should identify
and begin the process of
detailing a collection of general
“Business Objects”.
These are objects that
can be used throughout
the system
DESIGN
During the design pass we
focus on defining and
detailing the actual classes
and objects for which we will
actually be writing and
implementing in code. At this
stage in the development
effort the design work passes
almost exclusively into the
developer’s purview. The rest
of the project team will be
for testing and validating the
delivered implementations
or prototypes.

25. STEP 6: MANAGE WORK PRODUCTS.
A work product is any planned, concrete result of the development process;
either a final deliverable or an intermediate one. Examples includes source
codes, a design object model, an analysis state model, a Use Case Model,
and a project schedule. The set of all project work products constitute the
project workbook. Work products all have common structure providing
names, dates, description, issues, status, and the like, as well as structure
that is work product-specific, for example, an object model diagram.
A project workbook is a logical book with a predetermined structure
containing all the work products associated w/ a project from requirements
gathering and project management through analysis, design,
implementation, and testing.