CHAPTER 3

INCEPTION PHASE
 2
OBJECTIVES

◼ The definition of the Inception phase.

◼ How long the Inception phase is.
◼ Feasibility Study
◼ Preliminary Investigation
 WHAT IS INCEPTION? 3

It will include an analysis of perhaps 10% of the use cases, an

analysis of the critical non-functional requirement, the creation
of a business case, and preparation of the development
environment so that programming can start in the following
elaboration phase.

Most projects require a short initial step in which the following

kinds of questions are explored:
◼ What is the vision and business case for this project?

◼ Is the project feasible?

◼ Should you buy and/or build?

◼ Rough estimate of cost: Is it $10K-100K or in the millions?

◼ Should we proceed or stop?

 4

INCEPTION IN ONE SENTENCE:

Envision the product scope, vision,
and business case.

The main problem solved in one sentence:

Do the stakeholders have basic
agreement on the vision of the project,
and is it worth investing in serious
investigation?
 5

◼ The preceding inception phase is akin to a

feasibility study to decide if it is even worth investing
in exploratory drilling.
◼ Only after exploration (elaboration), do we have the
data and insight to make somewhat believable
estimates and plans.
◼ Therefore, in iterative development and the UP, plans,
and estimates are not to be considered reliable in the
inception phase.
◼ They merely provide an order-of-magnitude sense of
the level of effort, to aid the decision to continue or
not.
 6
WHAT ARTIFACTS MAY START IN
INCEPTION?
◼ A key insight regarding iterative development
is to appreciate that these are only partially
completed in this phase, will be refined in later
iterations, and should not even be created
unless it is deemed likely they will add real
practical value.
◼ And since it is inception, the investigation and
artifact content should be light.
 7
ISN’T THAT A LOT OF DOCUMENTATION?

◼ Recall that artifacts should be considered optional.

◼ Choose to create only those that really add value to
the project, and drop them if their worth is not proven.
◼ The point of an artifact is not the document or
diagram itself, but the thinking, analysis, and
proactive readiness.
 8

◼ You believe that the proper sequence of work

should be:
1) define the requirements
2) design the architecture
3) implement.
◼ There is no Business Case or Vision artifact.
◼ All the use cases were written in detail.
◼ None of the use cases were written in detail;
rather, 10~20% should be written in detail to
obtain some realistic insight into the scope of the
problem.
 9
EVALUATION OF SYSTEMS REQUESTS

◼ Systems Review Committees

◼ Most large companies use a
systems review committee to
evaluate systems requests
◼ Many smaller companies rely on
one person to evaluate systems
requests instead of a committee
◼ The goal is to evaluate the requests
and set priorities
 10
OVERVIEW OF FEASIBILITY
◼ A systems request must
pass several tests,
called a feasibility
study, to see whether it
is worthwhile to
proceed further
◼ Operational Feasibility
◼ Depends on several
vital issues.
◼ Estimates how
much time the
project will take to
complete.
 11
OVERVIEW OF FEASIBILITY
◼ Technical Feasibility - focuses on the technical
resources available to the organization, and
involves evaluation of the hardware,
software, and other technology requirements
of the proposed system.

◼ Economic Feasibility - involves a cost/ benefits

analysis of the project, helping organizations
determine the viability, cost, and benefits
associated with a project before financial
resources are allocated.
 12
OVERVIEW OF FEASIBILITY

◼ Schedule Feasibility - involves undertaking a study

to analyze and determine whether - and how
well – the organization’s needs can be met by
completing the project, and analyzing how a
project plan satisfies the requirements.

◼ Political Feasibility - Governments implement

policies, and governments are subject to a
variety of political constraints.
 13
EVALUATING FEASIBILITY

◼ The first step in evaluating feasibility is to

identify and weed out system requests
that are not feasible
◼ Even if the request is feasible, it might
not be necessary
◼ Feasibility analysis is an ongoing task that
must be performed throughout the
systems development process
 14
SETTING PRIORITIES

◼ Factors that Affect Priority

◼ Will the proposed system reduce costs?
Where? When? How? How much?
◼ Will the system increase revenue for the
company? Where? When? How? How much?
◼ Will the systems project result in more information
or produce better results? How? Are the results
measurable?
◼ Will the system serve customers better?
◼ Will the system serve the organization better?
 15
SETTING PRIORITIES

◼ Factors that Affect Priority

◼ Can the project be implemented in a
reasonable time period? How long will the
results last?
◼ Are the necessary financial, human,
and technical resources available?
◼ Whenever possible, the analyst should
evaluate a proposed project based on
tangible costs and benefits that represent
actual (or approximate) dollar values
 16
SYSTEM REQUIREMENTS
◼ System requirements – all of the capabilities that the
new system must have and the constraints that the
new system must meet
◼ System requirements fall into two categories
◼ Functional – activities/processes that the system must
perform
◼ Directly related to use cases
◼ Documented in graphical and textual models
◼ Non-functional – characteristics of the system to
improve
the efficiency or performance.
◼ Technical, performance, usability, reliability
and security
◼ Documented in narrative descriptions to models
 17
NON-FUNCTIONAL REQUIREMENTS

◼ Technical – describes an operational characteristics related to

the environment, hardware, and software of the organization.

◼ Performance – describes operational characteristics related to the

measure of system workload, such as throughput and response time.

◼ Usability – describes operational characteristics related to user

interfaces, work procedures, online help, and documentation.

◼ Reliability – describes the dependability of the system, accounting for

events such as incorrect processing, error detection, and recovery

◼ Security – describes which users can perform which system functions

under what conditions.

◼ Cultural & Political – The system should be able to distinguish between

United States and European currencies. The system shall comply with
insurance industry standards. an operational characteristic
 18
PRELIMINARY INVESTIGATION

◼ Interaction with Managers and Users

◼ Let people know about the investigation and
explain your role
◼ Employee attitudes and reactions are
important and must be considered
◼ Be careful in your use of the word problem
◼ Question users about additional
capabilities they would like to have
 19

PRELIMINARY INVESTIGATION

◼ Planning the Preliminary Investigation

◼ During a preliminary investigation, a systems
analyst typically follows a series of steps
◼ The exact procedure depends on the
nature of the request, the size of the
project, and the degree of urgency
 20
PRELIMINARY INVESTIGATION

◼ Step 1: Understand the Problem or

Opportunity
◼ A popular technique for investigating
causes and effects is called a fishbone
diagram, or Ishikawa diagram
 21
FISHBONE OR ISHIKAWA DIAGRAM
 22
PRELIMINARY INVESTIGATION
◼ Step 2: Define the Project Scope and Constraints
◼ Project scope
◼ Project creep
◼ Constraint
◼ Present versus future
◼ Internal versus external
◼ Mandatory versus desirable
◼ Regardless of the type, all constraints should be
identified as early as possible to avoid future
problems and surprises
 23
PRELIMINARY INVESTIGATION
◼ Step 3: Perform Fact-Finding
◼ Fact-finding involves various techniques
◼ Depending on what information is needed to
investigate the systems request, fact-finding might
consume several hours, days, or weeks
◼ Analyze Organization Charts
◼ Obtain organization charts to understand how the
department functions and identify individuals you
might want to interview
 24
PRELIMINARY INVESTIGATION
◼ Step 3: Perform Fact- Finding
◼ Conduct interviews
◼ Review documentation
◼ Observe operations
(Observation)
◼ Conduct a user survey
(questionnaires)
◼ Research
 25
PRELIMINARY INVESTIGATION
◼ Step 4: Analyze Project Usability, Cost, Benefit, and
Schedule Data
◼ Before you can evaluate the feasibility, you must
analyze this data carefully
◼ What information must you obtain, and how will you
gather and analyze the information?
◼ What sources of information will you use, and what
difficulties will you encounter in obtaining
information?
◼ Will you conduct interviews? How many people will
you interview, and how much time will you need to
meet with the people and summarize their
responses?
 26
PRELIMINARY INVESTIGATION

◼ Step 4: Analyze Project Usability, Cost, Benefit, and

Schedule Data
◼ Will you conduct a survey? Who will be involved? How
much time will it take people to complete it? How much
time will it take to prepare it and tabulate the results?
◼ How much will it cost to analyze the information
gathered and to prepare a report with findings and
recommendations?
 27
PRELIMINARY INVESTIGATION

◼ Step 5: Evaluate Feasibility

◼ Start by reviewing the answers to the
questions you asked
◼ Operational feasibility
◼ Technical feasibility
◼ Economic feasibility
◼ Schedule feasibility
 28
PRELIMINARY INVESTIGATION
◼ Step 6: Present Results and
Recommendations to Management
◼ The final task in the preliminary investigation is to
prepare a report to management
◼ The format of the preliminary investigation report
varies from one company to another
◼ Introduction

◼ Systems request summary

◼ Findings

◼ Case for action

◼ Project Roles

◼ Time & cost estimates

◼ Expected benefits

◼ Appendix