Chapter 3 Understanding Requirements






Requirements
Vision
Use-Case Modeling
Software Requirements Specification
Requirements Management
Case Study and Project
Object Oriented Analysis and Design
1
Requirements
Object Oriented Analysis and Design
2
3.1 Requirements
 What is Requirements
 Types of Requirements
 Requirements Documents
Object Oriented Analysis and Design
3
What is requirement?
 Requirements are capabilities and conditions to
which the system (and more broadly, the project)
must conform. [JBR99].
 The purpose of Requirements is:
 To provide system developers with a better understanding
of the system requirements.
 To define the boundaries of (delimit) the system.
 To provide a basis for planning the technical contents of
iterations.
 To provide a basis for estimating cost and time to develop
the system.
 To define a user-interface for the system, focusing on the
needs and goals of the users.
Object Oriented Analysis and Design
4
Requirements
 Factors on challenged software projects
 37% of factors related to problems with requirements,
Object Oriented Analysis and Design
5
Requirements Management
 Requirements management is a systematic
approach to
 eliciting, organizing, and documenting the requirements
of the system
 establishing and maintaining agreement between the
customer and the project team on the changing
requirements of the system.
 Keys to effective requirements management
include
 maintaining a clear statement of the requirements,
along with applicable attributes for each requirement
type
 traceability to other requirements and other project
artifacts.
Object Oriented Analysis and Design
6
Types of Requirements – FURPS+
 Functional
 features, capabilities, security.
 Usability
 human factors, help, documentation.
 Reliability
 frequency of failure, recoverability, predictability.
 Performance
 response times, throughput, accuracy, availability, resource
usage.
 Supportability
 adaptability, maintainability, internationalization,
configurability.
Object Oriented Analysis and Design
7
Types of Requirements – FURPS+
 The "+" in FURPS+ indicates ancillary and subfactors, such as:
 Implementation
• resource limitations, languages and tools,
hardware, ...
 Interface
• constraints imposed by interfacing with
external systems.
 Operations
• system management in its operational setting.
 Packaging
 Legal
• licensing and so forth.
Object Oriented Analysis and Design
8
Types of Requirements – RUP
 Requirements are categorized as functional
(behavioral) or non-functional (everything else);
 Functional Requirements
 Functional requirements are explored and recorded in
• the Use-Case Model
• the system features list of the Vision artifact.
 Non-functional Requirements
 Other requirements can be recorded in the use cases they
relate to, or in the Supplementary Specifications artifact.
Object Oriented Analysis and Design
9
Requirement Documents
 Vision
 The Vision artifact summarizes high-level requirements that
are elaborated in these other documents.
 The Vision is a general vision of the core project's
requirements, and provides the contractual basis for the
more detailed technical requirements.
 Include:
• Problem Statement
• User or Stakeholder Descriptions
• Product Overview
• Features
• Constraints
Object Oriented Analysis and Design
10
Requirement Documents
 SRS (Software Requirements Specification)
 Functional requirements
• Use case Model
 Non-functional requirements
• Supplementary Specification
 Glossary
• records and clarifies terms used in the requirements.
• also encompasses the concept of the data dictionary,
which records requirements related to data, such as
validation rules, acceptable values, and so forth
 User-Interface Prototype
Prototypes are a mechanism to clarify what is wanted or
possible.
Object Oriented Analysis and Design
11
Requirement Artifacts in UP
Object Oriented Analysis and Design
12
Vision
Object Oriented Analysis and Design
13
3.2 Vision
 Introduction
 Template
 Example
 How to develop Vision
Object Oriented Analysis and Design
14
Vision - Introduction
 The Vision document provides
 a complete vision for the software system under development and
supports the contract between the funding authority and the
development organization.
 The vision document is
 written from the customers' perspective,
 focusing on the essential features of the system and acceptable levels
of quality.
 The Vision should include
 a description of what features will be included as well as those
considered but not included.
 It should also specify operational capacities (volumes, response times,
accuracies), user profiles (who will be using the system), and interoperational interfaces with entities outside the system boundary, where
applicable.
 The Vision document provides the contractual basis for
the requirements visible to the stakeholders.
Object Oriented Analysis and Design
15
Vision - Introduction
 The Vision document
 is created early in the inception phase, and
 it is used as a basis for the Business Case and the
first draft of the Risk List
 The Vision document
 serves as input to use-case modeling, and
 is updated and maintained as a separate artifact
throughout the project.
Object Oriented Analysis and Design
16
Vision - Introduction
 Purpose of Vision
 Gain agreement on what problems need to be
solved.
 Identify stakeholders to the system.
 Define the boundaries of the system.
 Describe primary features of the system.
Object Oriented Analysis and Design
17
Vision - Template for small project
 1. Introduction
 2. Positioning


2.1
2.2
Problem Statement
Product Position Statement
 3. Stakeholder and User Descriptions



3.1
3.2
3.3


3.4
3.5
Object Oriented Analysis and Design
Stakeholder Summary
User Summary
Key High-Level Goals and Problems of the
Stakeholders
User-Level Goals
User environment
18
Vision - Template for small project
 4. Product Overview


4.1
4.2
Product Perspective
Assumptions and Dependencies
 5. Product Features


5.1
5.2
<aFeature>
<anotherFeature>
 6. Other Requirements and
Constraints
Object Oriented Analysis and Design
19
Vision - Commentary to Template

Problem Statement

Provide a statement summarizing the problem being
solved by this project.
 The following format may be used:
The problem of
[describe the problem]
affects
[the stakeholders affected by the
problem]
the impact of which is [what is the impact of the problem?]
a successful solution
would be
Object Oriented Analysis and Design
[list some key benefits of a successful
solution]
20
Vision - Commentary to Template

Product Position Statement


Provide an overall statement summarizing, at the highest level, the
unique position the product intends to fill in the marketplace.
The following format may be used:
For
[target customer]
Who
[statement of the need or opportunity]
The (product name)
is a [product category]
That
Unlike
[statement of key benefit; that is, the
compelling reason to buy]
[primary competitive alternative]
Our product
[statement of primary differentiation]
Object Oriented Analysis and Design
21
Vision - Commentary to Template

User Summary


Name
Present a summary list of all identified users.
The following format may be used:
Description Responsibilities
[Name [Briefly
the user describe
type.]
what they
represent
with respect
to the
system.]
Object Oriented Analysis and Design
[List the user’s key
responsibilities with
regard to the system
being developed; for
example:
captures details
produces reports
coordinates work
and so on]
22
Stakeholder
[If the user is not
directly
represented,
identify which
stakeholder is
responsible for
representing the
user’s interest.]
Vision - Commentary to Template

Product Perspective
 This subsection puts the product in perspective
to other related products and the user’s
environment.
 If the product is independent and totally selfcontained, state it here.
 If the product is a component of a larger system,
then this subsection needs to relate how these
systems interact and needs to identify the
relevant interfaces between the systems.
 One easy way to display the major components
of the larger system, interconnections, and
external interfaces is with a block diagram.
• System context diagram
• High-level deployment diagram
Object Oriented Analysis and Design
23
Vision - Commentary to Template
 Product Features






Use cases are not necessarily the only way one needs to express
functional requirements.
An alternative, a complementary way to express system functions is
with features, or more specifically in this context, system features,
System features are high-level, terse statements summarizing
system functions.
A system feature is "an externally observable service provided by the
system which directly fulfills a stakeholder need" [Kruchten00].
Features are things a system can do.
The point of system features in the Vision is
•
•

to summarize the functionality,
not decompose it into a long list of fine-grained elements.
Keep feature descriptions at a general level.
•
Focus on capabilities needed and why (not how) they should be
implemented.
•
Avoid design.
• and Design
It is common to organize
a two-level hierarchy
Object Oriented Analysis
24
Vision - Commentary to Template
 Other Requirements in the Vision


In the Vision, system features briefly summarize
functional requirements expressed in detail in the use
cases.
Likewise, the Vision can summarize other requirements
(for example, reliability and usability) that are detailed
in the Special Requirements sections of use cases, and
in the Supplementary Specification (SS).
Object Oriented Analysis and Design
25
Vision - Example

Course Registration System example


Vision 1
NextGen example
Object Oriented Analysis and Design
26
Vision - How to develop Vision







Gain agreement on the problem being solved
Identify stakeholders
Define the system boundaries
Identify constraints to be imposed on the system
Formulate problem statement
Define features of the system
Evaluate your results
Object Oriented Analysis and Design
27
Vision - Checkpoints










Have you fully explored what the "problem behind the
problem" is?
Is the problem statement correctly formulated?
Is the list of stakeholders complete and correct?
Does everyone agree on the definition of the system
boundaries?
If system boundaries have been expressed using actors,
have all actors been defined and correctly described?
Have you sufficiently explored constraints to be put on the
system?
Have you covered all kinds of constraints - for example
political, economic, and environmental.
Have all key features of the system been identified and
defined?
Will the features solve the problems that are identified?
Are the features consistent with constraints that are identified?
Object Oriented Analysis and Design
28
3.3 Use-Case Modeling
 Key Concepts
 Use-Case Diagram
 Use-Case Specification
 Relationship between Use-case
 Checkpoints
Object Oriented Analysis and Design
29
Key Concepts
Object Oriented Analysis and Design
30
What Is System Behavior?
 System behavior is how a system acts and
reacts.
 It is the outwardly visible and testable activity of
a system
 System behavior is captured in use cases.
 Use cases describe the system, its environment,
and the relationship between the system and its
environment.
Object Oriented Analysis and Design
31
What Is a Use-Case Model?
 A model that describes a
system’s functional
requirements in terms of
use cases
 A model of the system’s
intended functionality
(use cases) and its
environment (actors)
View Report
Card
Student
Register for
Courses
Login
Object Oriented Analysis and Design
32
What Are the Benefits of a Use-Case Model?
 Used to communicate with the end users and
domain experts
 Provides buy-in at an early stage of system
development
 Insures a mutual understanding of the requirements
 Used to identify
 Who interacts with the system and what the system
should do
 The interfaces the system should have
 Used to verify
 All requirements have been captured
 The development team understands the requirements
Object Oriented Analysis and Design
33
Major Concepts in Use-Case Modeling
 An actor represents anything
that interacts with the system.
 A use case is a sequence of
actions a system performs that
yields an observable result of
value to a particular actor.
Actor
Use Case
Object Oriented Analysis and Design
34
What Is an Actor?
 Actors are not part of the system.
 Actors represent roles a user of the
system can play.
 They can represent a human, a
machine, or another system.
 They can actively interchange
information with the system.
 They can be a giver of information.
 They can be a passive recipient of
information.
Actors are EXTERNAL.
Object Oriented Analysis and Design
35
Actor
Useful Questions in Finding Actors?
 Who will supply, use, or remove information?
 Who will use this functionality?
 Who is interested in a certain requirement?
 Where in the organization is the system used?
 Who will support and maintain the system?
 What are the system’s external resources?
 What other systems will need to interact with
this one?
Actor
Object Oriented Analysis and Design
36
Focus on the Roles
 An actor
represents a role
that a human,
hardware device,
or another system
can play.
?
Object Oriented Analysis and Design
37
A User May Have Different Roles
Charlie as
student
Charlie
Student
Charlie as
professor
Professor
Object Oriented Analysis and Design
38
Practice: Find the Actors
 In the Course Registration System
Requirements document, read the Problem
Statement for the Course Registration case
study.
 As a group, identify the following
 Actors
 Description of the actor
Object Oriented Analysis and Design
39
Practice: Solution
Billing System
The external system
responsible for student
billing
Student
A person who is
teaching classes at the
University
Course Catalog
Professor
Registrar
The person who is
responsible for the
maintenance of the
course registration
system
Object Oriented Analysis and Design
40
A person who is
registered to take
courses at the
University
The unabridged
catalog of all courses
offered by the
University
What Is a Use Case?
A sequence of actions a system performs that
yields an observable result of value to a
particular actor
Use Case
Object Oriented Analysis and Design
41
Use Cases and Actors
 A use case models a dialog between actors
and the system.
 A use case is initiated by an actor to invoke a
certain functionality in the system.
Use Case
Actor
Communicates Association
Object Oriented Analysis and Design
42
How to Find Use Cases
 Answer the following questions to
find use cases.
 For each actor you have identified,
what are the tasks the system would
be involved in?
 Does the actor need to be informed
about certain occurrences in the
system?
 Will the actor need to inform the
system about sudden, external
changes?
 What information must be modified or
created in the system?
Object Oriented Analysis and Design
43
Naming the Use Case
Register for
Courses
 The name indicates what is
achieved by its interactions
with the actor(s).
 The name may be several
words in length.
 No two use cases should
have the same name.
Login
Maintain Student
Information
Object Oriented Analysis and Design
44
Use-Case Diagram
Object Oriented Analysis and Design
45
Use case diagram
 Captures system functionality as seen by
users
 Built in early stages of development
 Purpose
 Specify the context of a system
 Capture the requirements of a system
 Validate a system’s architecture
 Drive implementation and generate test cases
 Developed by analysts and domain experts
Object Oriented Analysis and Design
46
How Would You Read This Diagram?
View Report Card
Student
Maintain Professor Information
Register for Courses
Course Catalog
Login
Maintain Student Information
Select Courses to Teach
Registrar
Professor
Submit Grades
Close Registration
Billing System
Object Oriented Analysis and Design
47
Use Case Diagram - Example
Project Management
Normal User
Project Manager
Query
Development Manager
Administrator
Object Oriented Analysis and Design
User Authentication
User Management
System Configuration
48
Use-Case Specification
Object Oriented Analysis and Design
49
Use-Case Specifications










Name
Brief description
Flows of Events
Relationships
Activity diagrams
Use-Case diagrams
Special requirements
Pre-conditions
Post-conditions
Other diagrams
Use-Case Model
Actors
Use Cases
...
Use-Case Specifications
Object Oriented Analysis and Design
50
Use-Case Specifications - Flow of Events
• A use case describes what a system (or a subsystem,
class, or interface) does but it does not specify how
it does it.
• You can specify the behavior of a use case by
describing a flow of event in text clearly enough for
outsider to understand it easily.
• When you write this flow of events, you should
include how and when the use case starts and ends,
when the use case interacts with the actors and
what objects are exchanged, and the basic flow and
alternative flow of the behavior.
Object Oriented Analysis and Design
51
Use-Case Flow of Events
Has one normal, basic flow
Several alternative flows
Regular variants
Odd cases
Exceptional flows handling error situations
Object Oriented Analysis and Design
52
Use-Case Specifications - Scenarios
• A use case actually describes a set of sequences in
which each sequence in the set represents one
possible flow through all those variations.
• A scenario is a specific sequence of actions that
illustrates behavior.
• Scenarios are to use cases as instances are to
classes, meaning that a scenario is basically one
instance of a use case.
Object Oriented Analysis and Design
53
What Are Scenarios ?
 A scenario is an instance of a use case
Object Oriented Analysis and Design
54
What Is an Activity Diagram?
 An activity diagram in the use-case model can be
used to capture the activities in a use case.
 It is essentially a flow chart, showing flow of control
from activity to activity.
Flow of Events
This use case starts when the Registrar requests
that the system close registration.
1. The system checks to see if registration is in
progress. If it is, then a message is displayed to
the Registrar and the use case terminates. The
Close Registration processing cannot be
performed if registration is in progress.
2. For each course offering, the system checks if
a professor has signed up to teach the course
offering and at least three students have
registered. If so, the system commits the course
offering for each schedule that contains it.
Object Oriented Analysis and Design
55
Example: Activity Diagram
[ delete course ]
Decision
[ add course ]
Select
Course
Concurrent threads
Synchronization Bar (Fork)
Check
Schedule
Delete Course
Activity State
Check
Pre-requisites
Guard Condition
Transition
Synchronization Bar (Join)
[ checks completed ]
[ checks failed ]
Resolve
conflicts
Assign to
course
[ student added to the course ]
Update
schedule
Object Oriented Analysis and Design
56
Use-Case Specifications - Example
- User Management
1. Brief Description
This use case is for adding and deleting users. When adding user, the privilege of the
user will be assigned.
2. Basic Flow
B1. Start of use case
Actor chooses User Management in main screen.
B2. Prompt welcome screen
System shall prompt actor the user management welcome screen.
A1. Choose delete user
B3. Choose add user
Actor chooses Add User.
B4. Prompt add user screen
System shall prompt actor the add user screen which needs actor to input some
information.
These information include: User Name, User ID, User Password, User Role.
B5. Submit
Actor inputs the information and submits the screen.
E1. User ID already exists
E2. Not enough information
B6. Prompt success
Object Oriented
Analysis
and Design
57
System
shall
prompt actor success information.
Use-Case Specifications - Example
3. Alternative Flows
A1. Choose Delete User
From B2. Prompt welcome screen
A1.1 Choose delete
Actor chooses delete user.
A1.2 Prompt delete user screen
System shall prompt actor the delete user screen.
In this screen, system shall lists all the user ID stored in system.
A1.3 Choose user to delete
Actor chooses the user ID to delete and submit this screen.
E3. No user ID chosen
A1.4 Prompt success
System shall prompt actor success information.
4. Exception Flows
E1. User ID already exists
From B5. Submit, The User ID actor inputs has already existed in the system. The
system shall prompt actor to try another User ID。
E2. Not enough information
From B5. Submit, If actor does not input all the information, system can not add a user.
The system shall prompt actor to input all the information.
E3. No user ID chosen
From A1.3 Choose user to delete, If actor does not choose a user to delete before
submitting the screen, the system shall prompt actor an error that he/she should choose a
Object Oriented Analysis and Design
58
user to delete.
Relationship between Use-Case
Object Oriented Analysis and Design
59
Relationship between Use-case (optional)
 include
 extend
 generalization
Object Oriented Analysis and Design
60
Relationship between Use-cases - include
• <<include>> – An include relationship from use
case A to use case B indicates that an instance of
the use case A will also contain the behavior as
specified by B. The behavior is included at the
location which defined in A.
Submit
request
a
Offer a line of
credit
load
<<include>>
<<include>>
Perform
credit check
Object Oriented Analysis and Design
61
Relationship between Use-cases - include
<<include>>: Functional Decomposition
Problem:
 A function in the original problem statement is too complex to be solvable
immediately
Solution:
 Describe the function as the aggregation of a set of simpler functions. The
associated use case is decomposed into smaller use cases
<<include>>
<<include>>
ManageIncident
<<include>>
CloseIncident
CreateIncident
HandleIncident
Object Oriented Analysis and Design
62
Relationship between Use-cases - include
<<include>>: Reuse of Existing Functionality
Problem:
 There are already existing functions. How can we reuse them?
Solution:

The include association from a use case A to a use case B indicates that an instance of the use
case A performs all the behavior described in the use case B (“A delegates to B”)
Example:
 The use case “ViewMap” describes behavior that can be used by the use case
“OpenIncident” (“ViewMap” is factored out)
Note :
 The base case cannot exist alone. It is always called with the supplier use case
<<include>>
Base Usecase
OpenIncident
<<include>>
AllocateResources
Object Oriented Analysis and Design
63
Supplier Usecase
ViewMap
Relationship between Use-cases - extend
<<extend>>– An extend relationship from use
case A to use case B indicates that an instance of
use case B may be augmented (subject to specific
conditions specified in the extension) by the
behavior specified by A. The behavior is inserted
at the location defined by the extension point in B
which is referenced by the extend relationship.
Request additional
credit information
<<extend>>
Evaluate loan
request
Refer loan request
to loan committee
<<extend>>
Object Oriented Analysis and Design
64
Relationship between Use-cases - extend
Problem:
 The functionality in the original problem statement needs to be extended.
Solution:
 An extend association from a use case A to a use case B indicates that use case B is
an extension of use case A.
Example:
 The use case “ReportEmergency” is complete by itself , but can be extended by the
use case “getHelp” for a specific scenario in which the user requires help
Note :
 In an extend assocation, the base use case can be executed without the use case extensio
<<extend>>
FieldOfficer ReportEmergency
Object Oriented Analysis and Design
65
getHelp
Relationship between Use-cases - Generalization
 With the introduction of UML 1.3, a new
relationship between use cases was introduced generalization
 Generalization – A generalization from use case A
to use case B indicates that A is a specialization of
B.
Withdraw
funds
Withdraw
from
savings
Object Oriented Analysis and Design
Withdraw
from
checking
66
Request
credit card
advance
Relationship between Use-cases - Generalization
Problem:
 You have common behavior among use cases and want to factor this out.
Solution:
 The generalization association among use cases factors out common behavior. The
child use cases inherit the behavior and meaning of the parent use case and add or
override some behavior.
Example:
 Consider the use case “ValidateUser”, responsible for verifying the identity of the
user. The customer might require two realizations: “CheckPassword” and
“CheckFingerprint”
Parent usecase
CheckPassword
ValidateUser
CheckFingerprint
Object Oriented Analysis and Design
67
Child usecase
Checkpoints
Object Oriented Analysis and Design
68
Checkpoints: Requirements: Use-Case Model
 Is the use-case model understandable?
 By studying the use-case model, can
you form a clear idea of the system's
functions and how they are related?
 Have all functional requirements been
met?
 Does the use-case model contain any
superfluous behavior?
 Is the division of the model into usecase packages appropriate?
Object Oriented Analysis and Design
69
Checkpoints: Requirements: Actors
 Have all the actors been identified?
 Is each actor involved with at least one
use case?
 Is each actor really a role? Should any
be merged or split?
 Do two actors play the same role in
relation to a use case?
 Do the actors have intuitive and
descriptive names? Can both users
and customers understand the names?
Object Oriented Analysis and Design
70
Checkpoints: Requirements: Use-Cases
 Is each use case involved with at least
one actor?
 Is each use case independent of the
others?
 Do any use cases have very similar
behaviors or flows of events?
 Do the use cases have unique,
intuitive, and explanatory names so
that they cannot be mixed up at a later
stage?
 Do customers and users alike
understand the names and
descriptions of the use cases?
Object Oriented Analysis and Design
71
Checkpoints: Requirements: Use-Case Specifications
 Is it clear who wishes to perform a usecase?
 Is the purpose of the use-case also
clear?
 Does the brief description give a true
picture of the use-case?
 Is it clear how and when the use-case's
flow of events starts and ends?
 Does the communication sequence
between actor and use-case conform
to the user's expectations?
 Are the actor interactions and
exchanged information clear?
 Are any use-cases overly complex?
Object Oriented Analysis and Design
72
Review: Requirements Overview





What are the main artifacts of Requirements?
What are the Requirements artifacts used for?
What is a use-case model?
What is an actor?
What is a use case? List examples of use case
properties.
 What is the difference between a use-case and a
scenario?
 What is a supplementary specification and what
does it include?
 What is a glossary and what does it include?
Object Oriented Analysis and Design
73
3.4 Software Requirements Specification
 Identifying other requirements
 Supplementary Specifications
 Glossary
Object Oriented Analysis and Design
74
Supplementary Specifications
Object Oriented Analysis and Design
75
Supplementary Specification
 Functionality
 Usability
 Reliability
 Performance
 Supportability
 Design constraints
Object Oriented Analysis and Design
Supplementary
Specification
76
Supplementary Specification - Example
 Review the Supplementary Specification
provided in the Course Registration
Requirements Document
Object Oriented Analysis and Design
77
Glossary
Object Oriented Analysis and Design
78
Glossary
Course Registration System Glossary
1.
Introduction
This document is used to define terminology specific to the problem domain,
explaining terms, which may be unfamiliar to the reader of the use-case
descriptions or other project documents. Often, this document can be used as an
informal data dictionary, capturing data definitions so that use-case descriptions
and other project documents can focus on what the system must do with the
information.
2.
Definitions
The glossary contains the working definitions for the key concepts in the Course
Registration System.
2.1
Glossary
Course:
A class offered by the university.
2.2
Course Offering: A specific delivery of the course for a specific semester –
you could run the same course in parallel sessions in the semester. Includes the
days of the week and times it is offered.
2.3
Course Catalog: The unabridged catalog of all courses offered by the
university.
Object Oriented Analysis and Design
79
Glossary - Example
 Review through the Glossary provided in the
Course Registration Requirements Document
Object Oriented Analysis and Design
80
3.5 Requirements Management
Making sure you
 Solve the right problem
 Build the right system
By taking a systematic approach to
 eliciting
 organizing
 documenting
 and managing
the changing requirements of a software
application.
Object Oriented Analysis and Design
81
Aspects of Requirements Management
 Analyze the Problem
 Understand User Needs
 Define the System
 Manage Scope
 Refine the System Definition
 Build the Right System
Object Oriented Analysis and Design
82
Map of the Territory
Problem
Problem
Space
Needs
Solution
Space
Features
The
Product
To Be
Built
Use Cases and
Software
Requirements
Test Procedures
Object Oriented Analysis and Design
Design
83
User
Docs
3.6 Case Study and Project
 Inception Phase
 Case Study - CRS
 Project - Inception Phase
Object Oriented Analysis and Design
84
Inception Phase
Object Oriented Analysis and Design
85
Inception Phase
 Inception Phase :
Define the scope of the project and develop business case
 The primary objectives of the inception phase include:
 Establishing the project's software scope and boundary
conditions, including an operational vision, acceptance
criteria and what is intended to be in the product and what
is not.
 Discriminating the critical use cases of the system, the
primary scenarios of operation that will drive the major
design trade-offs.
 Exhibiting, and maybe demonstrating, at least one
candidate architecture against some of the primary
scenarios
 Estimating the overall cost and schedule for the entire
project.
 Estimating potential risks.
 Preparing the supporting environment for the project.
Object Oriented Analysis and Design
86
What Artifacts May Start in Inception?
Artifact
Comment
Vision and Business Case
Describes the high-level goals and constraints, the business
case, and provides an executive summary.
Use-Case Model
Describes the functional requirements, and related nonfunctional requirements.
Supplementary
Specification
Describes other requirements.
Glossary
Key domain terminology.
Risk List & Risk
Management Plan
Describes the business, technical, resource, schedule risks, and
ideas for their mitigation or response.
Prototypes and proof-ofconcepts
To clarify the vision, and validate technical ideas.
Iteration Plan
Describes what to do in the first elaboration iteration.
Phase Plan & Software
Development Plan
Low-precision guess for elaboration phase duration and effort.
Tools, people, education, and other resources.
Development Case
A description of the customized UP steps and artifacts for this
project. In the UP, one always customizes it for the project.
Object Oriented Analysis and Design
87
Inception Phase - a suggested sequence
 1. Write a brief first draft of the Vision.
 2. Identify user goals and the supporting
use cases.
 3. Write some use cases and start the
Supplementary Specification.
 4. Refine the Vision, summarizing
information from these.
Object Oriented Analysis and Design
88
Checkpoint: What Happened in Inception?
 Inception is a short step
 to determine basic feasibility, risk, and scope.
 Some likely activities and artifacts in inception include:
 a short requirements workshop
 most actors, goals, and use cases named
 most use cases written in brief format; 10-20% of the use cases are written
in fully dressed detail to improve understanding of the scope and
complexity.
 most influential and risky quality requirements identified
 version one of the Vision and Supplementary Specification written
 risk list
 technical proof-of-concept prototypes and other investigations to explore
the technical feasibility of special requirements
 user interface-oriented prototypes to clarify the vision of functional
requirements
 recommendations on what components to buy/build/reuse, to be refined in
elaboration
 high-level candidate architecture and components proposed
 plan for the first iteration
Object Oriented
Analysis and Design tools list
89
 candidate
Sample requirements effort across the early iterations
Object Oriented Analysis and Design
90
Case Study (Covered in GCIS501)
Object Oriented Analysis and Design
91
Case Study - Course Registration System




Vision
SRS - Use Case Model
SRS - Supplementary Specification
SRS - Glossary
Object Oriented Analysis and Design
92
Project – Inception Phase
Object Oriented Analysis and Design
93
Project - Requirements
 Work as a team (max 3 person)
 Select topic
 Write the following Requirements artifacts:
 Vision
 SRS
• Use-case model
(Use-case diagram, Use-case specification,
Activity Diagram)
• Supplementary specification
• Glossary
• User Interface (optional)
Object Oriented Analysis and Design
94