Chapter 11

System Conception
 System Conception deals with the genesis of an
application.
 The purpose of System conception is to defer details and
understand the big picture.
 What need does the proposed system meet, can it be
developed at a reasonable cost, and will the demand for the
result justify the cost of building it?
 Devising a System Concept
 Most ideas for new systems are extensions of existing
ideas.
 For Ex: a human relations department may have a database
of employee benefit choices and require that a clerk enter
changes. An obvious extension is to allow employees to
view and enter their own changes.
 Occasionally, a new system is a radical departure from the
past. An online auction automates the ancient idea of
buyers bidding against each other for products.
 Here are some ways to find a new system concepts
 New functionality: Add functionality to an existing
system.
 Streamlining: Remove restrictions or generalize the way
a system works.
 Simplification: Let ordinary persons perform tasks
previously assigned to specialists.
 Automation: automate manual process.
 Integration: Combine functionality from different
systems.
 Analogies : Look for analogies in other problem domains
and see if they have useful ideas.
 Globalization : Travel to other countries and observe
their cultural and business practices.
 Elaborating a concept
 Good system concept must answer the following
questions
 Who is the application for?
 We should clearly understand which persons and
organizations are stakeholders of the new system.
 Two of the most important kinds of stake holders are the
financial sponsors and end users.
 The financial sponsor are very important because they are
paying for the new system.
 The users are stakeholders, but in another sense.
 What problems will it solve?
 We must clearly bound the size of the effort and establish
its scope. We should determine which features will be in
the new system and which will not.
 Where will it be used?
 At
the early stage, it is helpful to get a general idea of
where the new system will be used.
 We must determine if the new system is mission-critical
software for the organization, experimental software, or a
new capability that we can deploy.
 We should have a rough idea about how the new system
will complement the existing systems.
 When is it needed?
 Two aspects of time are important. The first is the feasible
time, the time in which the system can be developed
within the constraints of cost and available resources.
 Theother is the required time, when the system is needed
to meet business goals.
 Why is it needed?
 We may need to prepare a business case for the new
system if someone has not done already. The business
case contains financial justification for the new system
including the cost, tangible benefits etc,.
 We must be sure that we clearly understand the motivation
for the new system.
 Thebusiness case will give insight into what stakeholders
expect, roughly indicating the scope.
 How will it work?
 We should brainstorm about the feasibility of the problem.
For large systems we should consider the merits of
different architectures.
 The purpose of this speculation is not to choose a solution,
but to increase confidence that the problem can be solved
reasonably.
 The ATM case study
 Thefigure lists the original system concept for an
Automated Teller Machine(ATM).
 Who is the application for?
A number of companies provide ATM products. Only a
vendor or a large financial company could possibly justify
the cost and effort of building ATM software.
A vendor would be competing for customers in an
established market. A large vendor could certainly enter
such a market, but might it advantageous to partner with
or acquire an existing supplier.
A small vendor would need some special feature to
differentiate itself from the crowd and attract attention.
 If a financial company wanted special features, after
developing ATM software, it could partner with a vendor.
 Or it might decide to create a separate organizations that
would build the software, sell it to the sponsoring
company, and then market it to others.
 What problems will it solve?
 The ATM software is intended to serve both the bank and
the customer. For the bank, ATM software increases
automation and reduces manual handling of routine
paperwork.
 For the customer, the ATM is always available, handling
routine transactions whenever the customer desires.
 ATM software must be easy to use and convenient so that
customers will use it in preference to bank tellers. It must be
reliable and secure since it will be handling money.
 Where it will be used?
 ATM software has become essential to financial institutions.
Customers take it for granted that a bank will have an ATM
machine.
 ATM machines are available at many stores, sporting
events, and other locations throughout the world
 When is it needed?
 Any software development effort is a financial
proposition. The investment in development ultimately
leads to a revenue system.
 From an economic perspective, it is desirable to minimize
the investment, maximize the revenue, and realize
revenue as soon as possible.
 Why is it needed?
 There are many reasons why a vendor might decide to
build a software product.
 If other companies are making money with similar
products, there is a economic incentive to participate.
 If other companies are making money with similar
products, there is an economic incentive to participate.
A novel product could outflank competitors and lead to
premium pricing. Business commission internal efforts
for technology that is difficult to buy and critical to them.
 How will it work?
 We will adopt a three-tier architecture to separate the user
interface from programming logic, and programming
logic from the database.
 Inreality, the architecture is n-tier, because there can be
any number of intermediate programming levels
communicating with each other.
 Preparing a problem Statement
 Once the raw idea is taken by answering the high-level
questions, we are ready to write requirements statement
that outlines the goals and general approach of the
desired system.
 Throughout the document, we should distinguish among
requirements, design, and implementation.
 Requirements describe how a system behaves from the
user’s point of view. The system is considered as a black
box- all we care about is its external behavior.
 For Ex: some requirements for a car are that when we
press on the accelerator pedal, the car goes faster, and
when we step on the brake, the car slows down.
 Design decisions are engineering choices that provide the
behavior specified by the requirements.
 For Ex: some design decisions are how the internal
linkages are routed, how the engine controlled, and what
kinds of brake pads are on the wheels.
 Implementation deals with the ultimate realization in
programming code.
 Frequently customer mix true requirements with design
decisions. Usually this is a bad idea. If we separate
requirements from design decisions, we preserve the
freedom to change a design.
A system concept document may include an example
implementation. The purpose is to show how the system
could be implemented using current technology at a
reasonable cost.
 Itis a “proof of existence” statement. Make it clear that
the sample implementation could be done differently in
the final system.
 For Ex: when the Apollo program to put a man on the
moon in the 1960’s was first proposed, the plan was to
place a rocket in earth orbit, then launch a landing vehicle
directly to the moon’s surface.
 In the final successful program, the rocket was launched
directly into a lunar orbit, from which the lander was
launched to the moon’s surface.
 Itwas not a bad thing to make the first proposal, however
as this gave confidence that there was a feasible approach.
 Fig below shows the problem statement should state what
is to be done and not how it is to be implemented. It
should be statement of needs, not a proposal for a system
architecture.
 The requestor should avoid describing system internals, as
this restricts development flexibility. Performance
specifications and protocols for interaction with external
systems are legitimate requirements.
A problem statement may have more or less detail. A
requirement for a conventional product, such as a payroll
program or a building system, may have considerable
detail.
 A requirement for a research effort in a new area may lack
details. Most problem statements are ambiguous,
incomplete, or even inconsistent.
 The problem statement is just a starting point for
understanding the problem, not an immutable document.
 The purpose of subsequent analysis is to fully understand
the problem and its implementations.
 The ATM Case Study
 Fig below shows a problem statement for an automated
teller machine(ATM) network.
 Design the software to support a computerized banking
network including both human cashiers and automatic
teller machines (ATMs)to be shared by a consortium of
banks. Each bank provides its own computer to maintain
own accounts and process transactions against them.
Cashier stations are owned by individual banks and
communicate directly with their own bank’s computers.
Human cashiers enter account and transaction data.
 ATM machines communicate with a central computer that
clears transactions with the appropriate banks.
 An ATM accepts a cash card, interacts with the user,
communicates with the central system to carry out the
transaction, dispenses cash, and prints receipts. The
system requires appropriate recordkeeping and security
provisions. The system must handle concurrent accesses
to the same account correctly.
 The banks will provide their own software for their
computers; you are to design the software for the ATMs
and the network. The cost of the shared system will be
apportioned to the banks according to the number of
customers with cash cards.