1

SOEN 6461
Software Design Methodologies:
Lect_2
Inception
Understanding Requirements
Use-Case Model: Writing Requirements in Context

Chap: 4,5,6,7
Iteration 1
Iteration 2
Iteration 3
Introduces just those
analysis and design
skills related to
iteration one.
Additional analysis and
design skills introduced.
Likewise.
SOEN6461: Learning path through iterations
Inception
(req. Analysis)
OOA/D and
responsibilities'
assignment to
objects
Object design,
Design Patterns
Architectural
analysis,
framework
design
2
3
Today
Fundamental Understanding
Inception
Understanding Requirements
Use-Case Model: Writing Requirements in
Context


4
Analogy: Architecture of Buildings
We all live in them
(We think) We know how they are built
Requirements
Design (blueprints)
Construction
Use
This is similar (though not identical) to how
we build software
5
Some Obvious Parallels
Satisfaction of customers needs
Specialization of labor
Multiple perspectives of the final product
Intermediate points where plans and
progress are reviewed
6
Deeper Parallels
Architecture is different from, but linked
with the product/structure
Properties of structures are induced by
the design of the architecture
The architect has a distinctive role and
character
7
Deeper Parallels (contd)
Process is not as important as architecture
Design and resulting qualities are at the
forefront
Process is a means, not an end
Architecture has matured over time into a
discipline
Architectural styles as sets of constraints
Styles also as wide range of solutions,
techniques and palettes of compatible
materials, colors, and sizes
8
More about the Architect
A distinctive role and character in a project
Very broad training
Amasses and leverages extensive experience
A keen sense of aesthetics
Deep understanding of the domain
Properties of structures, materials, and
environments
Needs of customers
Even first-rate programming skills are insufficient
for the creation of complex software applications
But are they even necessary?


9
Limitations of the Analogy
We know a lot about buildings, much less about
software
The nature of software is different from that of
building architecture
Software is much more malleable than physical
materials
The two construction industries are very different
Software deployment has no counterpart in building
architecture
Software is a machine; a building is not
10
But Still Very Real Power of Architecture
Giving preeminence to architecture offers
the potential for
Intellectual control
Conceptual integrity
Effective basis for knowledge reuse
Realizing experience, designs, and code
Effective project communication
Management of a set of variant systems
Limited-term focus on architecture will
not yield significant benefits!
11
Fundamental Understanding
Architecture is a set of principal design
decisions about a software system
Three fundamental understandings of
software architecture
Every application has an architecture
Every application has at least one architect
Architecture is not a phase of development


12
Wrong View: Architecture as a Phase
Treating architecture as a phase denies its
foundational role in software development
More than high-level design
Architecture is also represented, e.g., by
object code, source code,


13
Context of Software Architecture
Requirements
Design
Implementation
Analysis and Testing
Evolution
Development Process


14
Requirements Analysis
Traditional SE suggests requirements analysis should
remain unsullied by any consideration for a design
However, without reference to existing architectures
it becomes difficult to assess practicality, schedules,
or costs
In building architecture we talk about specific
rooms
rather than the abstract concept means for
providing shelter
In engineering new products come from the
observation of existing solution and their limitations
15
New Perspective on Requirements Analysis
Existing designs and architectures provide the
solution vocabulary
Our understanding of what works now, and how it
works, affects our wants and perceived needs
The insights from our experiences with existing
systems
helps us imagine what might work and
enables us to assess development time and costs
Requirements analysis and consideration of design
must be pursued at the same time


16
Non-Functional Properties (NFP)
NFPs are the result of architectural choices
NFP questions are raised as the result of
architectural choices
Specification of NFP might require an
architectural framework to even enable their
statement
An architectural framework will be required
for assessment of whether the properties are
achievable

17
The Twin Peaks Model
18
Design and Architecture
Design is an activity that pervades software development
It is an activity that creates part of a systems
architecture
Typically in the traditional Design Phase decisions concern
A systems structure
Identification of its primary components
Their interconnections
Architecture denotes the set of principal design decisions
about a system
That is more than just structure
19
Architecture-Centric Design
Traditional design phase suggests translating the
requirements into algorithms, so a programmer can
implement them
Architecture-centric design
stakeholder issues
decision about use of COTS component
overarching style and structure
package and primary class structure
deployment issues
post implementation/deployment issues


COTS:Commercial off-the-shelf
20
Design Techniques
Basic conceptual tools
Separation of concerns
Abstraction
Modularity

A widely adapted strategy
Object-oriented design




21
Object-Oriented Design (OOD)
Objects
Main abstraction entity in OOD
Encapsulations of state with functions for
accessing and manipulating that state



22
Pros and Cons of OOD
Pros
UML modeling notation
Design patterns
Cons
Provides only
One level of encapsulation (the object)
One notion of interface
One type of explicit connector (procedure call)
Even message passing is realized via procedure calls
OO programming language might dictate important
design decisions
23
Today
Fundamental Understanding
Inception
Understanding Requirements
Use-Case Model: Writing Requirements in
Context


The NextGent POS System (1/2)
A POS system computerized application used to record
sales and handle payments typically used in retail stores.
POS includes:
Hardware components(computer and bar code scanner
Software
POS interfaces to various service application (e.i. Tax
calculator and inventory control)
POS system supports multiple client-side terminals and
interfaces
POS a commercial system for different clients with
disparate needs in terms of business rule processing:
flexibility and customization


24
25
Case Study Focus
Many systems can be divided into 3 layers
User interface
Business logic (application)
Integration (DB & other systems)

Focus is on business layer because
Its design is less technology dependent
OOAD skills can be applied to other layers
More likely to have stable design
The NextGen POS System (2/2)
User Interface
Sale Payment
Logging ... Database Access ...
application
logic layer
other layers or
components
minor focus
explore how to connect to
other layers
primary focus
of case studies
explore how to
design objects
secondary
focus
26
27
Inception
A number of questions need to be explored:
What is the vision and business case for this project?
Is it feasible?
Buy and/or build?
Rough estimate of cost.
Should we proceed or stop?
The intent is to establish some initial common
vision for the objectives of the project,
determine if it is feasible and decide if it is
worth some serious investigation in elaboration.
28
What artifacts may start in
inception? (1/2)
Vision and business case
Describes high-level goals and constraints.
Use Case model
Describes functional requirements and related non-
functional requirements.
Supplementary specification
Describes other requirements
Glossary
Key domain terminology
Risk list and Risk Management Plan
Describes business, technical, resource and schedule
risks and ideas for their mitigation or response.


29
What artifacts may start in
inception? (2/2)
Prototypes and proof-of-concepts
Iteration plan
Describes what to do in the first elaboration iteration
Phase Plan & Software development Plan
Guess for elaboration phase duration. Tools, people,
education and other resources.
Development Case
Description of the customized UP steps and artifacts
for this project.
Artifacts will be partially completed in this phase
and will be refined in later iterations.

30
Today
Fundamental Understanding
Inception
Understanding Requirements
Use-Case Model: Writing Requirements in
Context


31
Introduction to Requirements
Requirements are system capabilities and conditions to which
the system must conform.
Functional requirements
Features and capabilities.
Recorded in the Use Case model (see next), and in the
systems features list of the Vision artifact.
Non-functional (or quality requirements)
Usability (Help, documentation, ), Reliability (Frequency of
failure, recoverability, ), Performance (Response times,
availability, ), Supportability (Adaptability, maintainability,
)
Recorded in the Use Case model or in the Supplementary
Specifications artifact.
The nature of UP supports changing requirements.
Types and Categories of Requirements
Functional: Features, capabilities, security
Usability: human factors, help documentation
Reliability: frequency of failure, recoverability
Performance: response time, accurarcy
Suportability: adaptability, maintainability
Implementation: language, tools, hardware
Interface: interfacing with extern systems
Operations: system management in its oper. setting.
Packaging: example physical box
Legal: licensing
SWEBOK: Software Engineering Body of Knowledge
Writing Effective Use Cases, by Cockburn, A. 2001
32
33
Today
Fundamental Understanding
Inception
Understanding Requirements
Use-Case Model: Writing Requirements in
Context


Use-Case Model
Operation:
enterItem()
Post-conditions:
- . . .
Operation Contracts
Sale
date
. . .
Sales
LineItem
quantity
1..* 1
. . .
. . .
Domain Model
Use-Case Model
Design Model
: Register
enterItem
(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
objects, attributes,
associations
Require-
ments
Business
Modeling
Design
Sample UP Artifact Relationships
: System
enterItem
(id, quantity)
Use Case Text
System Sequence Diagrams
make
NewSale()
system
events
Cashier
Process
Sale
: Cashier
use
case
names
system
operations
Use Case Diagram
Vision
Supplementary
Specification
Glossary
scope, goals,
actors, features
terms, attributes,
validation
non-functional reqs,
quality attributes
requirements
Process Sale
1. Customer
arrives ...
2. Cashier
makes new
sale.
3. ...
34
35
Use cases and adding value
Actor: something with behavior, such as a
person, computer system, or organization,
e.g. a cashier.
Scenario: specific sequence of actions and
interactions between actors and the
system under discussion, e.g. the scenario
of successfully purchasing items with cash.
Use case: a collection of related success
and failure scenarios that describe actors
using a system to support a goal.
The kind of actors
Actors
Primary actor : has user goals: e.g.: cashier)
Supporting actor: provides a service:e.g.
automated payment servise
Offsatge actor: has an interest in the
behavior of the use case but not primary or
supporting a government tax agency
36
37
Use cases and adding value
Handle returns
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
customer and ask for an alternative payment
method.
If item identifier not found in the system, notify
the Cashier and suggest manual entry of the
identifier code.


38
Use cases and adding value
A key point is to focus on the question
how can using the system provide
observable value to the user, or fulfill
their goals?
Use cases mainly constitute functional
requirements.
39
Use case types and formats
Black-box use cases describe system
responsibilities, i.e. define what the system must
do.
Uses cases may be written in three formality
types
Brief: one-paragraph summary, usually of the main
success scenario.
Casual: Informal paragraph format (e.g. Handle returns)
Fully dressed: elaborate. All steps and variations are
written in detail.
40
Fully-dressed example:
Process Sale
Use case UC1: Process Sale
Primary Actor: Cashier
Stakeholders and Interests:
-Cashier: Wants accurate and fast entry, no payment errors,
-Salesperson: Wants sales commissions updated.

Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions):
-Sale is saved. Tax correctly calculated.

Main success scenario (or basic flow): [see next slide]
Extensions (or alternative flows): [see next slide]
Special requirements: Touch screen UI,
Technology and Data Variations List:
-Identifier entered by bar code scanner,
Open issues: What are the tax law variations?
41
Main success scenario (or basic flow):
The Customer arrives at a POS checkout with items to purchase.
The cashier records the identifier for each item. If there is more than
one of the same item, the Cashier can enter the quantity as well.
The system determines the item price and adds the item information to
the running sales transaction. The description and the price of the current
item are presented.
On completion of item entry, the Cashier indicates to the POS system
that item entry is complete.
The System calculates and presents the sale total.
The Cashier tells the customer the total.
The Customer gives a cash payment (cash tendered) possibly greater
than the sale total.

Extensions (or alternative flows):
If invalid identifier entered. Indicate error.
If customer didnt have enough cash, cancel sales transaction.

Fully dressed example:
Process Sale (cont.)
42
Goals and Scope of a Use Case
At what level and scope should use cases be
expressed?
A: Focus on uses cases at the level of
elementary business process (EBP).
EBP: a task performed by one person in one
place at one time which adds measurable
business value and leaves the data in a
consistent state.
Approve credit order - OK.
Negotiate a supplier contract - not OK.
It is usually useful to create separate sub use
cases representing subtasks within a base use
case.
e.g. Paying by credit
43
Finding primary actors, goals and
use cases
Choose the system boundary.
Identify primary actors.
Those that have user goals fulfilled through
using services of the system
For each actor identify their user goals.
Tabulate findings in the Vision artifact.
Define use cases that satisfy user goals;
name them according to their goal.
44
Essential vs. Concrete style
Essential: Focus is on intend.
Avoid making UI decisions
Concrete: UI decisions are embedded in
the use case text.
e.g. Admin enters ID and password in the
dialog box (see picture X)
Concrete style not suitable during early
requirements analysis work.
45
Use Case Diagrams
NextGen
Cashier
Handle returns
Payment
Authorization
Service
Process Rental
<<actor>>
Tax Calculator
Primary actors to
the left: have user goals.
Supporting actors to
the right: they provide
a service.
Alternative notation for
computer system actor
Process Sale
Primary actors and goals at different
system boundaries
Goal: Process sales
Cashier
Customer
POS System
Checkout Service
Goal: Buy items
Enterprise Selling Things
Sales Tax
Agency
Goal: Collect
taxes on sales
Sales Activity
System
Goal: Analyze sales
and performance data
46
Partial use case context diagram
NextGen POS
Manage Users
. . .
Cashier
System
Administrator
actor
use case
communication system boundary
Payment
Authorization
Service
actor
Tax Calculator
actor
Accounting
System
alternate
notation for
a computer
system actor
actor
HR System
Cash In
actor
Sales Activity
System
Manage Security
Analyze Activity
Customer
Manager
Process Sale
Handle Returns
47
Notation suggestions
NextGen
Process Sale
. . .
Cashier
Show computer system actors
with an alternate notation to
human actors.
primary actors on
the left
supporting actors
on the right
For a use case context
diagram, limit the use cases to
user-goal level use cases.
actor
Payment
Authorization
Service
48
Alternative actor notation
NextGen
Process Sale
system
Payment
Authorization
Service
...
actor
Payment
Authorization
Service
Some UML alternatives to
illustrate external actors that
are other computer systems.
The class box style can be
used for any actor, computer or
human. Using it for computer
actors provides visual
distinction.
Payment
Authorization
Service
49
Supplementary Specification: captures other kind of
requirements: reports, documentation, licensing
Glossary: captures terms and definitions, data
dictionary
Business Rules: captures rules and policies
Other requirement artifacts (chap. 7, p 102)
50
51
Today
Fundamental Understanding
Inception
Understanding Requirements
Use-Case Model: Writing Requirements in
Context