Object Oriented Analysis

and Design
DEPARTMENT OF INFORMATION TECHNOLOGY
GOVT. GORDON COLLEGE RAWALPINDI

Fall 2019 Semester

BS Course: IT-325 OOA/D
Course Instructor: Mubashra Rabbani
Lecture 5
INCEPTION
Inception Phase

 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?
Requirement Analysis
 A requirement is a statement that describes:
 An aspect of what the proposed system must do i.e., the
task system must accomplish.
 A constraint on the system’s development
 It must contribute towards adequately solving the
customer’s problem.
 Requirements state WHAT, not HOW
 Focus is on customer and the problem, not the
solution.
 Not implementation specific
 The set of requirements as a whole represents a
negotiated agreement among all stakeholders
Requirement Analysis

Requirements can be divided into

two major types:
Functional Requirements
Non-Functional Requirements
Functional Requirements
 Functional Requirements describe what the
system should do. They describe the services
provided for the users and for other systems.
 Functional requirement discuss the functionality
required by the users from the system.
 Functional requirements should include:
 Everything that a user of the system would need
to know regarding what the system does.
 Everything that would concern any other system
that has to interface to this system. Details that
go any deeper into how the requirements are
implemented should be left out.
Functional Requirements
 Functional requirements can be categorized as follows:
 What Inputs the system should accept, and under what
conditions. This includes data and commands both from
the users and from other systems.
 What Outputs system should produce and under what
conditions. Output can be on screen and it can be in
printed form. It may also be transmitted to other systems.
Data which is stored for the exclusive use of this system.
e.g. the specifics of a file format used to temporarily back
up some data.
 What Computations the system should perform. The
computations should be described at a level that all
readers can understand .
 The Timing & synchronization of the above. Not all systems
involve timing and synchronization – this category is of most
importance in hard real-time systems. e.g. systems that run
automobiles and airplanes, systems that control power plants
or factories.
Non Functional Requirements
 A non- functional requirement is a statement of
HOW a system must behave; it is a constraint of
how a system must behave; it is a constraint upon
system’s behavior.
 Non-functional requirements can be categorized
as:
 Quality constraint
 Performance constraint
 Design constraint
 Environmental/platform constraint
 Process constraint
Non Functional Requirements
Quality Constraint reflects the quality attributes. These
quality requirements constrain the design to meet
specified levels of quality.
Following are some quality attributes:
 Maintainability and Enhancement: In order to ensure
that the system can be adapted in the future, you should
describe changes that are anticipated for subsequent
releases. This constrains design and improves quality
without adding explicit new functional requirements.
 Reusability is the likelihood a segment of source code
that can be used again to add new functionalities with
slight or no modification. Reusability reduces
implementation time as reusable model is already tested.
 Reliability is specified by using mean time to failure. It is
the ability of a system to perform its functions under stated
conditions for a specified period of tie.
Non Functional Requirements
 Performance Constraints:
 Response time is time system take to compute
the result.
 Throughput it is number of computation or
transactions per unit time. Some systems take
long time for processing or some systems are
continually responding to clients, it is necessary
to consider throughput.
 Utilization is resources consumed by the system.
Utilization of resources such as memory or
network bandwidth are specified. E.g. system
should not use more than 20MBPS f bandwidth.
Non Functional Requirements
 Design Constraints
 Availability measure the amount of time that a
server is running and available to respond to
users. E.g. system should not be down for more
than 5 minutes
 Recovery from failure if the hardware or
software crashes , or the power fails, then the
system will be able to recover within a certain
amount of time, and with a certain minimal loss
of data.
Non Functional Requirements
 Environmental / Platform Constraint
 Platformspecifies the hardware and operating
system used for developing system. E.g. Linux
operating system with 2GB RAM.
 Technology to be used: It signifies the
programming language (framework) used to
develop a system. Sometimes client places
constraint on programming language to be used
for developing system. E.g. system should be
developed by using java language.
Non Functional Requirements
 Process Constraint:
 Development process to be used: In order
to ensure quality, some requirements documents
specify that certain processes be followed. E.g.
particular approaches to testing
 Cost
 Delivery date.
FURPS+
FURPS is an acronym representing a model for classifying
software quality attributes (functional and non-functional
requirements)
 Functional (features, capabilities, security)
 Usability (human factors, help, documents)
 Reliability (failures, recovery, predictable)
 Performance (response times, throughput, accuracy,
availability, resource
usage)

 Supportability (adaptability, maintainability, internationalization,

configurability)

 + ancillary and sub-factors

Implementation (includes limitations), Interface, Operations,
Packaging, Legal Requirements
Use Case Model
 The use case model is the set of all use cases – a model of the
system’s functionality and environment.

 Use cases are widely used mechanism to discover and record

requirements (specially functional)

 Idea of using use cases to describe functional requirements

was introduced in 1986 by Ivar Jacobsons

 Use cases (cases of use) are stories of using a system to meet

goals - A description of domain processes (simple and
understandable for all stakeholders)
Use Case Model
 Informally, a use case is a collection of related success and
failure scenarios that describe actors using a system to support
a goal.

 A use-case is a sequence of actions a system performs that

yields an observable result of value to a particular actor.

 A key attitude in use case work is to focus on the question

“How can using the system provide observable value to the
user, or fulfill their goals?”

 Use cases are text documents, not diagrams, and use case
modeling is primarily an act of writing, not drawing. However,
the UML defines a use case diagram to illustrate the names of
use cases and actors, and their relationships.
Use Case Model (contd…)
 Actor
 is something with behavior, such as a person (identified by role),
computer system, or organization; for example, a cashier.
 Scenario
 is a specific sequence of actions and interactions between
actors and the system under discussion.
 a use case instance.
 a path through use case
 Use case
 is a collection of related success and failure scenarios that
describe actors using a system to support a goal.
 Use cases are requirements (though not all)
Use Case Formats
 Brief Format
Process Sale: A customer arrives at a checkout
with items to purchase. The cashier uses the POS
system to record each purchased item. The system
presents a running total and line-item details. The
customer enters payment information, which the
system validates and records. The system updates
inventory. The customer receives a receipt from
the system and then leaves with the items.
Use Case Formats (contd…)
 Casual Format
 Main Success Scenario:
A customer arrives at a checkout with items to return. The
cashier uses the POS system to record each returned item
...
 Alternate Scenarios:
If the credit authorization is reject, inform the
customer and ask for an alternate payment method.
If the item identifier is not found in the system, notify
the Cashier and suggest manual entry of the
identifier code (perhaps it is corrupted).
If the system detects failure to communicate with
the external tax calculator system, ...
Use Case Formats (contd…)
 Black-Box Use Case:
Black-box use cases are the most common and
recommended kind; they do not describe the internal
workings of the system, its components, or design.
Rather, the system is described as having responsibilities
Use Case Formats (contd…)
 Use cases are written in different formats, depending on need.
There are varying degrees of formality:
 Brief—terse one-paragraph summary, usually of the main
success scenario. This Process Sale example is brief.

 Casual—informal paragraph format. Multiple paragraphs that

cover various scenarios.
Use Case Formats (contd…)
 The Handle Returns example is casual.
Use Case Formats (contd…)

 Fully Dressed—the most elaborate. All steps and

variations are written in detail, and there are supporting
sections, such as preconditions and success guarantees.
 Fully dressed use cases show more detail and are
structured; they are useful in order to obtain a deep
understanding of the goals, tasks, and requirements.
 Various format templates re available for fully dressed
use cases. However, the most widely used and shared
format is the following template
 The following example illustrates this style.
Use Case Formats (contd…)
Use Case Formats (contd…)
Use Case Formats (contd…)
Use Case Formats (contd…)
Use Case Formats (contd…)
  The two column-variation
Use Case Formats
Some prefer the two-column or conversational format,
which emphasizes the fact that there is an interaction
going on between the actors and the system.
(contd…)
What format should we use?
 There is no one best format. It is just your
personal preference based on your
practice and experience.

 The key thing is to write the details of the

main success scenario and its extensions in
some form.
Sections of Use Case
 Primary Actor: The principal actor that calls upon system
services to fulfill a goal. (Only place elements at the start
which are important to read before the main success
scenario)

 Supporting Actor: Provides a service (for example,

Information) to the SuD. The automated payment
authorization service is an example. Often a computer system,
but could be an organization or person.

 Offstage Actor: has an interest in the behavior of the use case,

but is not primary or supporting; for example, a government
tax agency.
 Why identify? To ensure that all necessary interests are identified
and satisfied. Offstage actor interests are sometimes subtle or
easy to miss unless these actors are explicitly named.
Sections of Use Case
 Stakeholders and Interests List:
 Since the use case, as the contract for behavior, captures all
and only the behaviors related to satisfying the stakeholders’
interests, so we start with the stakeholders and their interests.
 The stakeholder interest viewpoint provides a thorough
procedure for discovering and recording all the required
behaviors.
 Preconditions and Success Guarantees:
 Preconditions state what must always be true before
beginning a scenario in the use case
 These are noteworthy assumptions or conditions that are
assumed to be true before process starts
 It may imply the success scenario of previous successfully
completed use case
 There are some conditions that are true but are of no
practical value to write, such as “the system has power”
Sections of Use Case
 Success guarantees (postconditions) state what must be true
on successful completion of the use case—either the main
success scenario or some alternate path.
The guarantee should meet the needs of all stakeholders.

 Main Success Scenario and Steps (or Basic Flow) (Happy Path)
It describes the typical success path that satisfies the interests
of the stakeholders.
 Note that it often does not include any conditions or
branching.
 Itis suggested to defer all conditional handling to the
Extensions section.
Sections of Use Case
 The success scenario records the steps, of which there are
three kinds:
1. An interaction between actors.
2. A validation (usually by the system).
3. A state change by the system (for example, recording or
modifying something).
 Step one of a use case indicates the trigger event that starts
the scenario.
 It is a common practice to always capitalize the actors’
names for ease of identification.
 Note that the system under discussion itself should be
considered an actor when it plays an actor role collaborating
with other systems.
Sections of Use Case
Extensions (or Alternate Flows)
 Extensions indicate all the scenarios or branches other than
main success scenario, both success and failure.
 The Extensions section is expected to be considerably longer
and more complex than the Main Success Scenario section
 A combination of the happy path and extension scenarios
satisfies “nearly” all the interests of the stakeholders.
 Extension scenarios are branches from the main success
scenario, and so can be notated with respect to it. Such as,
for Step 3 of the main success scenario An extension is labeled
“3a”; it first identifies the condition and then the response.
Alternate extensions at Step 3 are labeled “3b” and so forth.
Sections of Use Case
Extensions (or Alternate Flows)
 An extension has two parts: the condition and the handling.
 Write the condition as something that can be detected by the
system or an actor. To contrast:
5a. System detects failure to communicate with external tax
calculation system service:
5a. External tax calculation system not working:
The former style is preferred because this is something the system
can detect; the latter is an inference.

 Extension handling can be summarized in one step, or include a

sequence.
 At the end of extension handling, by default the scenario merges
back with the main success scenario, unless the extension
indicates otherwise (such as by halting the system).
Sections of Use Case
 Special Requirements
 If a non-functional requirement, quality attribute, or constraint relates
specifically to a use case, record it with the use case. These include
qualities such as performance, reliability, and usability, and design
constraints (often in I/O devices) that have been mandated or
considered likely.
 Technology and Data Variations List
 Often there are technical variations in how something must be done, but
not what, and it is noteworthy to record this in the use case.
 A common example is a technical constraint imposed by a stakeholder
regarding input or output technologies.
 For example, a stakeholder might say, “The POS system must support
credit account input using a card reader and the keyboard.” Note that
these are examples of early design decisions or constraints; in general, it is
skillful to avoid premature design decisions, but sometimes they are
obvious or unavoidable, especially concerning input/output
technologies.
 This list is the place to record such variations. It is also useful to record
variations in the data that may be captured at a particular step.