SOFTWARE
ARCHITECTURE AND
DESIGN
DOCUMENTATION
TEAM 3 – K15T1
Hanh Luong – Leader – T095095
Hao Tran – T094442
Huy Nguyen – T094016
Hieu Le – T093798
Quang Nguyen – T094193
Copyright © Team 3 – K15T1
Final project
Version 2
Revision history
Issue
1.0
Change
Status
Summary
First
I.
version
II.
III.
IV.
V.
VI.
VII.
VIII.
IX.
X.
2.0
Second
version
Writer(s)
Execute overview
Purpose
Project overview
Architecture
driver
overview
Functional requirement
Quality
attribute
requirement
Constraints
Prioritization
Minimal
acceptable
delivery
Reference
Update VI.
requriement
Team 3 – K15T1 – VLU
quality
Date
I.
Hao
Tran,
Quang May 25, 2012
Nguyen
II.
Hao Tran
III.
Hao
Tran,
Quang
Nguyen
IV.
Hao Tran, Hanh Luong,
Quang Nguyen
V.
Hao Tran, Hanh Luong,
Quang Nguyen, Hieu Le
VI.
Hao Tran, Hanh Luong,
Quang Nguyen, Hieu Le
VII.
Hao Tran, Hanh Luong,
Quang Nguyen, Hieu Le
VIII. Hao Tran, Hanh Luong,
Quang Nguyen, Hieu Le
IX.
Hao Tran, Hanh Luong,
Quang Nguyen, Hieu Le
X.
Hanh Luong, Quang
Nguyen
attribute Quang Nguyen
May 29, 2012
Hao Tran
1
Version 2
Contents
Executive Overview .............................................................................................................................. 5
I.
II.
Purpose ............................................................................................................................................. 5
III.
Project Overview .............................................................................................................................. 5
IV.
Architectural Drivers Overview ....................................................................................................... 6
1)
Architecture driver overview and their relative influence .............................................................. 6
2)
Elicitation & Analysis process and Stakeholders............................................................................ 6
a.
Process .......................................................................................................................................... 6
b.
Stakeholders ................................................................................................................................. 7
Functional Requirements .................................................................................................................... 8
V.
1)
Use case model ................................................................................................................................. 8
2)
Use case description ...................................................................................................................... 14
3)
Entity description .......................................................................................................................... 16
Quality Attribute Requirements ..................................................................................................... 20
VI.
1)
Performance .................................................................................................................................. 20
2)
Availability..................................................................................................................................... 21
3)
Security .......................................................................................................................................... 22
4)
Usability ......................................................................................................................................... 23
VII.
Constraints ..................................................................................................................................... 24
VIII.
IX.
X.
Prioritization............................................................................................................................... 24
Minimal Acceptable Delivery ......................................................................................................... 27
Reference ............................................................................................................................................ 27
Team 3 – K15T1 – VLU
2
Version 2
List of figures
Figure IV.2.a 1) Elicitation process .............................................................................................................. 6
Figure IV.2.a 2) Analysis process ................................................................................................................. 7
Figure V.1 1) Overview of use case in Sale system of a retail chain using loyalty card point system ......... 8
Figure V.1 2) Use case of Manage member information .............................................................................. 9
Figure V.1 3) Use case of Manage staff’s account information in system ................................................... 9
Figure V.1 4) Use case of Manage store product .......................................................................................... 9
Figure V.1 5) Use case of Manage product ................................................................................................ 10
Figure V.1 6) Use case of Manage product type......................................................................................... 10
Figure V.1 7) Use case of Manage store ..................................................................................................... 11
Figure V.1 8) Manage system log ............................................................................................................... 11
List of table
Table V.1 1) Use case note ......................................................................................................................... 12
Table V.1 2) Architecture driver: High functional requirement................................................................. 13
Table V.1 3) Entity table ............................................................................................................................. 14
Table V.2 1) Use case description: Use case UC3.1 Manage sale ............................................................ 16
Table V.2 2) Use case description: Use case UC11.1 Manage company statistic ..................................... 16
Table V.3 1) Entity E1 Head office administrator description ................................................................... 17
Table V.3 2) Entity E2 Cashier description ................................................................................................ 17
Table V.3 3) Entity E4 Member manager description ................................................................................ 18
Table V.3 4) Entity E5 Product manager description ................................................................................ 19
Table V.3 5) Entity E7 Company manager description .............................................................................. 19
Table VI 1) Architecture driver: Quality attribute ..................................................................................... 20
Table VI.1 1) Quality attribute Performance description: QP1 ................................................................. 20
Table VI.1 2) Quality attribute Performance description: QP2 ................................................................. 20
Table VI.1 3) Quality attribute Performance description: QP2 ................................................................. 21
Table VI.2 1) Quality attribute Availability description: QA1 ................................................................... 21
Table VI.2 2) Quality attribute Availability description: QA2 ................................................................... 21
Table VI.2 3) Quality attribute Availability description: QA3 ................................................................... 22
Table VI.3 1) Quality attributes Security description: QS1 ....................................................................... 22
Table VI.3 2) Quality attributes Security description: QS2 ....................................................................... 22
Table VI.3 3) Quality attributes Security description: QS3 ....................................................................... 23
Team 3 – K15T1 – VLU
3
Version 2
Table VI.4 1) Quality attributes Usability description: QU1 ..................................................................... 23
Table VI.4 2) Quality attributes Usability description: QU2 ..................................................................... 23
Table VI.4 3) Quality attributes Usability description: QU3 ..................................................................... 24
Table VII.3 1) Architecture driver: Business Constraints .......................................................................... 24
Table VII.3 2) Architecture driver: Technical Constraints ........................................................................ 24
Table VIII 1) Use case ranking................................................................................................................... 25
Table VIII 2) Quality attribute scenario ranking ....................................................................................... 26
Table VIII 3) Business constraints ranking................................................................................................. 26
Table VIII 4) Technical constraint ranking................................................................................................. 26
Team 3 – K15T1 – VLU
4
Version 2
I.
Executive Overview
1.
Project description
The general project goal is to develop the architecture design of a realistic software system.
A key objective of this project is practice key principles presented in the course and to foster deeper
thinking about what motivates architectural design decisions, practice architectural reasoning, and
architectural documentation
2.
Architecture drivers specification description:
This documentation focuses on 9 parts. All reader should read:

Part II: Purpose, to understand overview about the meaning of this documentation.

Part III: Project Overview, to understand overview about the project.

Part IV: Architecture Drivers Overview, to understand overview about architecture driver and
elicitation & analysis process that is used to elicit the raw architecture driver.

Part V: Functional Requirements, to get more information about architecture driver: High
functional requirement and know how the functional requirements are articulated in terms of use
cases from information provided by the stakeholder community.

Part VI: Quality Attribute Requirements, to get more information about architecture driver:
Quality attribute requirement and know how they are articulated in terms of use case scenarios
from information provided by the stakeholder community.

Part VII: Constraints, to get more information about architecture driver: Constraints and know
how they are premade design decisions, differences between business constraints and technical
constraints and describe their relative impact on the system or product design.

Part VIII: Prioritization, to know clearly how architecture driver is prioritized.

Part IX: Minimal Acceptable Delivery, to know what acceptable deliverable must be delivery
at the end of the project

Part X: Reference, to know more information about reference of this documentation.
3.
Overview of architectural drivers:
Architectural drivers are not all of the requirements for a system, but they are the requirements that have
architectural impact and significance. Architectural drivers consist of coarse-grained or high-level
functional requirements; technical constraints, business constraints and quality attribute requirements.
4.
Summary description of key functionality, quality attributes requirements, and constraints
(focus on the highest-priority architectural drivers)
Key Functionality: Manage sale and Statistic (Detail at part V. Functional requirement)
Key Quality attributes requirements: Performance and Availability (Detail at part VI. Quality attribute
requirement)
Key Constraints: Time do deliver and framework. (Detail at part VII. Constraints)
II.
Purpose
The purpose of this document is to describe Project overview, the architecture drivers in POST system
and how Architecture design team elicit and analyze them. Besides, there’s the priority of architecture
drivers and the minimal acceptable delivery.
III.
Project Overview
Reference to K15T1_Team3_FinalProject_MasterDesignPlan.docx (Part III: Project description)
Team 3 – K15T1 – VLU
5
Version 2
IV.
Architectural Drivers Overview
1) Architecture driver overview and their relative influence
According to part I.3 Overview of architecture driver, architectural drivers consist of high-level functional
requirements; technical constraints, business constraints and quality attribute requirements.
High-level functionality is an obvious architectural driver and refers to those general requirements for
what the system must do.
Technical and business constraints are fixed premade decisions that are in place before design begins.
Quality attribute requirements are properties that the system must possess, such as availability, security,
high performance, and so forth.
2) Elicitation & Analysis process and Stakeholders
a. Process
Elicitation process
Project
overview
Stakeholders
Join
Plan for
stage
Review
System
Identify
Functionality
Create Initial
Master
Design Plan
Architecture Driver
Specification
Master Design
Plan
Identify
Quality
Attribute
Requirements
Identify
Technical
Constraints
Identify
Business
Constraints
Stage 2
Notation
Entity
File/Database
Process
Flow
Data I/O
Figure IV.2.a 1) Elicitation process
Elicitation process description
This Data Flow diagram describes how to elicit architectural drivers by Architecture team. First, PM will
plan for activities which take place in this stage. These activities are:
 Review system: Team will review project overview document to understand the system
 Create Master Design Plan: PM creates initial Master Design plan which is input for stage 2.
 Identify Functionality, Quality attribute, Technical and Business constraints: Architecture
team will identify architectural drivers which are input for stage 2.
Team 3 – K15T1 – VLU
6
Version 2
Analysis process
Architecture Driver
Specification
Stage 1
Plan for
Stage
If have problems
Analyze and
Specify raw
architecture
driver
Update
Master
Design Plan
Master Design Plan
Reviews
Update
Master
Design Plan
Stage 3
Notation
File/Database
Flow
Process
Data I/O
Figure IV.2.a 2) Analysis process
Analysis process description
This diagram describes how to analyze and specify architectural drivers. PM will plan for this stage.
Team will analyze and specify raw architecture driver, then they update architecture driver specification.
If there are some problems, team will return to stage 1 again. Otherwise, team will review architecture
driver specification to update Master Design Plan and come to stage 3.





b. Stakeholders
Hanh Luong – Managing engineer, Chief architect Requirements engineer, Quality process engineer.
Hao Tran - Chief architect, Requirements engineer, Production engineers, Quality process engineer.
Hieu Le - Chief architect, Requirements engineer, Production engineers:
Huy Nguyen - Chief architect, Requirements engineer, Chief scientist, Production engineers
Quang Nguyen – Support engineer, Requirements engineer, Chief architect, Production engineers
Team 3 – K15T1 – VLU
7
Version 2
V.
Functional Requirements
1) Use case model
Figure V.1 1) Overview of use case in Sale system of a retail chain using loyalty card point system
Team 3 – K15T1 – VLU
8
Version 2
Figure V.1 2) Use case of Manage member information
Figure V.1 3) Use case of Manage staff’s account information in system
Figure V.1 4) Use case of Manage store product
Team 3 – K15T1 – VLU
9
Version 2
Figure V.1 5) Use case of Manage product
Figure V.1 6) Use case of Manage product type
Team 3 – K15T1 – VLU
10
Version 2
Figure V.1 7) Use case of Manage store
Figure V.1 8) Manage system log
Note:
1. Actor
2. Use case
3. Boundary of the system
4. Use
5. Extend
Team 3 – K15T1 – VLU
11
Version 2
6. Generalization
Table V.1 1) Use case note
Use cases table:
Use case ID
Use case name
Actor
Member manager
Cashier
Head office administrator
Product manager
Company manager
Member manager
Cashier
Head office administrator
Product manager
Company manager
Member manager
Cashier
Head office administrator
Product manager
Company manager
UC1.1
Log in
UC1.2
Change pass
UC1.3
Log out
UC2.0
Manage member info
Member manager
UC2.1
View list member
Member manager
UC2.2
Create new member information
Member manager
UC2.3
Modify member information
Member manager
UC2.4
View detail member information
Member manager
UC2.5
Enable/Disable member information
Member manager
UC3.1
Manage sale
Cashier
UC3.2
Print bill
Cashier
UC4.0
Manage staff’s account information in system
Head office administrator
UC4.1
View list user group
Head office administrator
UC4.2
Add new account (to group)
Head office administrator
UC4.3
Modify user group information
Head office administrator
UC4.4
Assign access right
Head office administrator
UC4.5
Enable/Disable user group information
Head office administrator
UC4.6
View detail user group information
Head office administrator
UC4.7
View detail account information
Head office administrator
UC4.8
Enable/Disable account information
Head office administrator
UC4.9
Reset pass
Head office administrator
UC4.10
Add new group
Head office administrator
Team 3 – K15T1 – VLU
12
Version 2
UC4.11
Modify account information
Head office administrator
UC5.0
Manage store product
Product manager
UC5.1
View list store product
Product manager
UC5.2
Create new store product
Product manager
UC5.3
View detail store product
Product manager
UC5.4
Modify store product
Product manager
UC5.5
Enable/Disable store product
Product manager
UC5.6
Set retail price
Product manager
UC7.0
Manage product
Product manager
UC7.1
View list product
Product manager
UC7.2
Create new product
Product manager
UC7.3
View detail product
Product manager
UC7.4
Modify product
Product manager
UC7.5
Enable/Disable product
Product manager
UC8.0
Manage product type
Product manager
UC8.1
View list product type
Product manager
UC8.2
Create new product type
Product manager
UC8.3
View detail product type
Product manager
UC8.4
Modify product type
Product manager
UC8.5
Enable/Disable product type
Product manager
UC9.0
Manage store
Company manger
UC9.1
View list store categories
Company manger
UC9.2
Create new store categories
Company manger
UC9.3
View detail store categories
Company manger
UC9.4
Modify store categories
Company manger
UC9.5
Enable/Disable store categories
Company manger
UC11.1
UC12.0
UC12.1
Manage company statistic
Company manger
Mange system log
Head office administrator
View log
Head office administrator
Table V.1 2) Architecture driver: High functional requirement
Entity table
ID
E1
Entity
Head office administrator
E2
E4
E5
E7
Cashier
Member manager
Product manager
Company manager
Team 3 – K15T1 – VLU
Description
Manage staff’s account information in system
Manage system log
Manage sale
Manage member information
Manage product, product type
Manage company statistic
Manage store
13
Version 2
Table V.1 3) Entity table
2) Use case description
Use Case Title: Manage sale
Use Case ID: UC3.1
General Use Case Description: Describe sale process
Entities Involved: Cashier
Preconditions:
Log in with Cashier account successfully.
The system connected to Web server.
The system connected to Store database.
Primary Use Case Flow of Events: Customer don’t have member card and choose paying by cash
1
Cashier scan product bar code
2
System display product’s info: Name, Cost
3
Cashier input quantity of product being scan
4
System determines and displays total cost
…
Loop [1-4]
5
Cashier chooses paying by cash
6
System display textbox to input money
7
Cashier inputs money
8
System calculates
9
System display residual cash
10
System saves the sale records
Primary Use Case Post Conditions: System saved the sale records
Alternative Use Case #1 Flow of Events: Customer have member card and choose paying by cash
(Sequence of Primary Use Case Flow of Events from step 1 to step 4)
Cashier inputs member ID
5
6
System display member information
7
Cashier chooses paying by cash
8
System display textbox to input money
9
Cashier inputs money
10
System calculates
11
System display residual cash and accrued point
12
System saves the sale records
Alternative Use Case #1 Post Conditions: System saved the sale records and determined saved
point for member
Team 3 – K15T1 – VLU
14
Version 2
Alternative Use Case #2 Flow of Events: Customer have member card and choose paying by saved
point (Sequence of Primary Use Case Flow of Events from step 1 to step 4)
Cashier inputs member ID
5
6
System display member information
7
Cashier chooses paying by saved point
8
System calculates
9
System subtracts points from the number of saved point by the member
10
System saves the sale records
11
System display member point
Alternative Use Case #2 Post Conditions: System saved the sale records and determined saved
point for customer
Alternative Use Case #3 Flow of Events: Customer have member card and choose paying by saved
point with cash (Sequence of Primary Use Case Flow of Events from step 1 to step 4)
Cashier inputs member ID
5
6
System display member information
7
Cashier chooses paying by saved point with cash
Cashier chooses paying rate (50:50, 25:75, 75:25)
10
System calculates how many point, money customer need to pay and saved point and display
(Member has enough points)
Cashier inputs money
11
System calculates
12
System display residual cash
13
System saves accrued point.
14
System saves the sale records
Alternative Use Case #3 Post Conditions: System saved the sale records and determined saved
point for customer
Alternative Use Case #4 Flow of Events: Cashier doesn’t scan bar code product and customer
paying by cash
Cashier import the bar codes of the products being purchased
1
2
Cashier input quantity of products
3
System determines and displays total cost
…
Loop [1-3]
4
Cashier chooses paying by cash
5
Cashier inputs money
Team 3 – K15T1 – VLU
15
Version 2
6
System calculates
7
System display residual cash
8
System saves the sale records
Alternative Use Case #4 Post Conditions: System saved the sale records
Table V.2 1) Use case description: Use case UC3.1 Manage sale
Use Case ID: UC11.1
Use Case Title: Manage company statistic
General Use Case Description: Describe statistic process
Entities Involved: Company manager
Preconditions: Log in with Company manager account successfully.
The system connected to Web server.
The system connected to Head office database.
Primary Use Case Flow of Events: Company manager want to see revenues
1
Company manager chooses statistic revenues
2
System displays combo-box to choose month
3
Company manager choose month
4
System displays total sales revenues in month
Primary Use Case Post Conditions: System displays total sales revenues in month
Alternative Use Case #1 Flow of Events: Company manager want to see best-selling products.
1
Company manager chooses statistic best-selling products
2
System displays combo-box to choose month and top X best-selling product
3
Company manager choose month and top X best-selling product
4
System displays list best-selling products in month
Alternative Use Case #1 Post Conditions: System displays list best-selling products in month
Table V.2 2) Use case description: Use case UC11.1 Manage company statistic
3) Entity description
Entity name: Head office administrator
Entity ID: E1
Description:
The role this entity in the system is to manage staff’s account information in system and manage system
log
Provides assumption:
This entity will provide user group and account information for staffs who work in the system.
Require assumption:
When the system begin to work, this entity need an default account to log in to the system with the
following account information
Team 3 – K15T1 – VLU
16
Version 2
Account name: Administrator
Password: Administrator
This entity can manage its account information by itself.
Identified use case
Use case ID
Use case name
UC1.1
UC1.2
UC1.3
UC4.0
UC4.1
UC4.2
UC4.3
UC4.4
UC4.5
UC4.6
UC4.7
UC4.8
UC4.9
UC4.10
UC4.11
UC12.0
UC12.1
Log in
Change pass
Log out
Manage staff’s account information in system
View list user group
Add new account (to group)
Modify user group information
Assign access right
Enable/Disable user group information
View detail user group information
View detail account information
Enable/Disable account information
Reset pass
Add new group
Modify account information
Manage system log
View log
Table V.3 1) Entity E1 Head office administrator description
Entity name: Cashier
Entity ID: E2
Description:
The role of this entity is to manage sale operations in the system
Provides assumption:
This entity will provide information about payment what member purchase, print bill, product
information and member information for the system
Require assumption:
This entity need a fixed account to log in to the system, work and can change its password by itself.
Identified use case
Use case ID
Use case name
UC1.1
UC1.2
UC1.3
UC3.1
UC3.2
Log in
Change pass
Log out
Manage sale
Print bill
Table V.3 2) Entity E2 Cashier description
Team 3 – K15T1 – VLU
17
Version 2
Entity name: Member manager
Entity ID: E4
Description:
The role of this entity is to manage member information in the system
Provides assumption:
This entity will provide member’s information, who was registered to be the member in the business
system. Include some basic info: Full name, address, phone number, saved point
Require assumption:
This entity need a fixed account to log in to the system, work and can change its password by itself.
Identified use case
Use case ID
Use case name
Log in
Change pass
Log out
Manage member information
View list member
Create new member information
Modify member information
View detail member information
Enable/Disable member information
UC1.1
UC1.2
UC1.3
UC2.0
UC2.1
UC2.2
UC2.3
UC2.4
UC2.5
Table V.3 3) Entity E4 Member manager description
Entity name: Product manager
Entity ID: E5
Description: The role of this entity is to Manage product, product type, manage store product in the
system of each store
Provides assumption:
This entity will be providing information about product and store and have the highest access at store
Require assumption:
This entity need a fixed account to log in to the system, work and can change its password by itself.
Identified use case
Use case ID
Use case name
UC1.1
Log in
UC1.2
Change pass
UC1.3
Log out
UC5.0
Manage store product
UC5.1
View list store product
UC5.2
Create new store product
UC5.3
View detail store product
UC5.4
Modify store product
UC5.5
Enable/Disable store product
UC5.6
Set retail price
UC7.0
Manage product
Team 3 – K15T1 – VLU
18
Version 2
UC7.1
View list product
UC7.2
Create new product
UC7.3
View detail product
UC7.4
UC7.5
Modify product
Enable/Disable product
UC8.0
Manage product type
UC8.1
UC8.2
View list product type
Create new product type
UC8.3
View detail product type
UC8.4
UC8.5
Modify product type
Enable/Disable product type
Table V.3 4) Entity E5 Product manager description
Entity name: Company manager
Entity ID: E7
Description:
The role of this entity is to manage company statistic and manage store
Provides assumption:
This entity will provide information about store categories
Require assumption:
This entity need a fixed account to log in to the system, work and can change its password by itself.
Identified use case
Use case ID
Use case name
UC1.1
UC1.2
UC1.3
UC9.0
UC9.1
UC9.2
UC9.3
UC9.4
UC9.5
UC11.1
Log in
Change pass
Log out
Manage store
View list store categories
Create new store categories
View detail store categories
Modify store categories
Enable/Disable store categories
Manage company statistic
Table V.3 5) Entity E7 Company manager description
Team 3 – K15T1 – VLU
19
Version 2
VI.
Quality Attribute Requirements
According to part IV.1) Architecture driver overview and their relative influence, quality attribute
requirements are properties that the system must possess, such as availability, security, high performance,
and so forth.
The information about quality attributes requirement of this project is showed as the following:
ID
Quality attribute
Reference to use case
UC2.1, UC3.1, UC11.1
QP Performance
UC3.1, UC11.1
QA Availability
UC1.1, UC1.2
QS Security
UC2.1, UC3.1, UC11.1
QU Usability
Table VI 1) Architecture driver: Quality attribute
1) Performance
Context: Member manager tries to view member list from the system at Head office in normal mode. The
system responds within 2s.
Scenario
ID
QP01
Member manager
Source
Display member list
Stimulate
System (Head office)
Artifact
Normal mode
Environment
Load member list from Database
Response
within 2s
Response Measure
Table VI.1 1) Quality attribute Performance description: QP1
Context: Cashier tries to implement a payment for member by point at store in environment normal
mode. The system responds within 1s.
Scenario
ID
QP02
Cashier
Source
Display member point
Stimulate
System (POS terminal)
Artifact
Normal mode
Environment
Load member point from Database
Response
within 1s
Response Measure
Table VI.1 2) Quality attribute Performance description: QP2
Context: Company manager tries to view revenue statistic from the system at Head office in environment
normal mode. The system responds within 3s.
Scenario
ID
QP03
Source
Team 3 – K15T1 – VLU
Company manager
20
Version 2
Display revenue statistic
Stimulate
System (Head office)
Artifact
Normal mode
Environment
Analyze data and display revenue statistic
Response
within 3s
Response Measure
Table VI.1 3) Quality attribute Performance description: QP2
2) Availability
Context: Cashier tries to implement a payment for member by point at store in when connection to head
office is error. The system shows error message within 1s.
Scenario
ID
QA01
Source
Internal to the system
Stimulate
Cashier choose: Pay by point
Artifact
Sale process
Environment
Response
Degrade mode (Connection to Head office is
error)
Show error message
Response Measure
Within 1s
Table VI.2 1) Quality attribute Availability description: QA1
Context: When network of store is failed, other store still normally.
Scenario
ID
QA02
Source
Internal to the system
Stimulate
Artifact
Fail
Network at store
Environment
Response
Degrade mode (network of 1 store is failed)
Other store still normally
Response Measure
No downtime
Table VI.2 2) Quality attribute Availability description: QA2
Context: The system update price for each store product when store products have no available retail
price within 2s.
Scenario
ID
QA03
Source
Internal to the system
Stimulate
System update price for each store product
Artifact
Persistent storage
Environment
Normal mode (No available retail price)
Response
System save standard price of each store
product
Team 3 – K15T1 – VLU
21
Version 2
Response Measure
Within 2s
Table VI.2 3) Quality attribute Availability description: QA3
3) Security
Context: User login failed 3 times within 5 minutes when system connects to database. The system will
lock user account in 15 minutes.
Scenario
ID
QS01
Source
Users
Stimulate
Try to login
Artifact
System services
Environment
Response
System connects to Database, Users login
failed 3 times within 5 minutes.
System locks user account
Response Measure
15 minutes
Table VI.3 1) Quality attribute Security description: QS1
Context: User changes password 3 times within 1 day. To ensure security, the system will lock the user
account within 24 hours.
Scenario:
ID
QS02
Source
Users
Stimulate
Try to change password
Artifact
System services
Environment
Response
System connect to Database, user change
password 3 times within 1 day
System locks user account
Response Measure
24 hours
Table VI.3 2) Quality attribute Security description: QS2
Context: User tries to login with account which is being used by another user in normal mode. To ensure
security, the system uses will prevent this and show error messenger in 1s.
Scenario
ID
QS03
Source
Users
Stimulate
Try to login with used account
Artifact
System services
Environment
Response
Normal mode (Account is used by another
user)
Show message “Access denied”
Response Measure
1s
Team 3 – K15T1 – VLU
22
Version 2
Table VI.3 3) Quality attributes Security description: QS3
4) Usability
Context: Cashier inputs invalid barcode into the system at POS terminal in normal mode. The system
shows notice about that error and barcode format within 1s.
Scenario
ID
QU01
Source
Cashier
Stimulate
Input invalid barcode
Artifact
System (POS terminal)
Environment
Normal mode
Response
Show notice about that error and barcode
format
Response Measure
Within 1s
Table VI.4 1) Quality attributes Usability description: QU1
Context: Member manager search member information easily in the system at Head office in normal
mode. The system will provide 3 search options: Member ID, Member name, Address.
Scenario
ID
QU02
Source
Member Manager
Stimulate
Search member information easily
Artifact
System (Head Office)
Environment
Normal mode
Response
Provide 3 search options: Member ID, Member
name, Address
Response Measure
3 ways
Table VI.4 2) Quality attributes Usability description: QU2
Context: Company manager selects way to present company statistic in the system in normal mode. The
system provides 2 statistic options: Overview (all store) and Detail (Each store)
Scenario
ID
QU03
Source
Company Manager
Stimulate
Select way to present company statistic
Artifact
System
Environment
Normal mode
Response
Provide 2 statistic options: Overview (all
stores) and Detail (each store)
Response Measure
2 ways
Team 3 – K15T1 – VLU
23
Version 2
Table VI.4 3) Quality attributes Usability description: QU3
VII.
Constraints
1) General description
According to part IV.1) Architecture overview, technical and business constraints are fixed premade
decisions that are in place before design begins.
Business constraints are indirect, premade design decisions with dramatic impact to the design and can
severely limit the permissible design choices available to the architect.
Technical constraints are direct, premade design decisions that become like load-bearing walls in the
design space that can have dramatic impact on the permissible design choices that the architect can make
when designing a system
2) Differentiate and their relative impact
Business constraints have indirect influence on the design, although the impact can be as deep as any
technical constraint. Business constraints can include schedule, cost, and procedural demands that will
impact how the system is designed or implemented or influence the design decisions that an architect
makes.
Technical constraints have direct influence on the design because they specify that a particular product,
tool, language, OS, platform, network, protocol, algorithm, and so forth must be used in the system. They
are design decisions that are made before the system design commences.
3) Constraint list
ID
Business constraint
B1
Deploy the architecture system in 10 weeks (Draft report: June-25-2012 and Final report: July-52012)
Human resource: 5 team members
B2
Table VII.3 1) Architecture driver: Business Constraints
ID
Technical constraint
T1
The system consists of a head office server, located at the head office, and the POS terminals
placed at store cashiers
The head office server and the store are connected to each other via a network
T2
T3
Company A decided to choose the Web solution using ASP.NET MVC 3 framework, only Web
browser, no local Database needed for any POS terminal.
Table VII.3 2) Architecture driver: Technical Constraints
VIII. Prioritization
Levels of stakeholder priority:
- Low: Nice to have
- Medium: Should have
- High: Must have
Team 3 – K15T1 – VLU
24
Version 2
Levels of difficulty ranking:
- Easy: Satisfying the architectural driver presents little scientific or engineering challenges or
unknowns. The architecture design team clearly understands how to satisfy this architectural
driver. This is a routine requirement or constraint, and copious scientific and technical
information exists about how to satisfy it. The team has extensive experience and expertise with
the domain or problem to satisfy the architectural driver.
-
Challenging: Satisfying the architectural driver presents some scientific or engineering
challenges and unknowns. Although challenging, the architecture design team generally understands how to satisfy this architectural driver. They understand the associated difficulties. There
exists sufficient scientific and technical information about how to satisfy the architectural driver,
or the team has sufficient experience and expertise with the domain or problem to satisfy the
architectural driver.
-
Difficulty: Satisfying the architectural driver presents significant scientific or engineering
challenges and unknowns. The architecture design team is unsure about how to satisfy this
architectural driver or if they can satisfy it. They have little or no experience or expertise with the
problem or domain. Little or no information exists about how to satisfy the architectural driver
Title: Use case
ID
UC1.1
Stakeholder Priority
Medium
Difficulty Ranking
Easy
Comments
Prototype
UC1.2
Medium
Easy
Prototype
UC1.3
Medium
Easy
Prototype
UC2.0
High
Challenging
UC3.1
High
Difficulty
UC4.0
Medium
Challenging
UC5.0
Medium
Challenging
UC7.0
Medium
Easy
UC8.0
Medium
Easy
UC9.0
Low
Easy
UC11.1
High
Challenging
UC12.0
Low
Easy
Prototype
Prototype
Table VIII 1) Use case ranking
Title: Quality attribute scenario
ID
Stakeholder Priority
Difficulty Ranking
QP01
Medium
Easy
QP02
Medium
Easy
QP03
High
Challenging
Prototype
QA01
High
Challenging
Prototype
QA02
High
Challenging
Prototype
Team 3 – K15T1 – VLU
Comments
25
Version 2
QA03
High
Challenging
Prototype
QS01
Low
Easy
Prototype
QS02
Low
Easy
QS03
Low
Easy
QU01
Medium
Easy
QU02
Low
Easy
QU03
Low
Easy
Prototype
Table VIII 2) Quality attribute scenario ranking
Constraints are not prioritized in terms of importance—by definition, constraints are inflexible and are the
highest priority (They are all assumed to be must-haves in the system context). So, constraint is prioritizes
by difficulty ranking
Title: Business Constrains
Description
Difficulty Ranking
Comments
Deploy the architecture system in 11 weeks High
(Draft report: June-25-2012 and Final
report: July-10-2012)
Human resource: 5 team members
Medium
Table VIII 3) Business constraints ranking
Title: Technical Constrains
Description
Difficulty Ranking
The system consists of a head office server, Medium
located at the head office, and the POS
terminals placed at store cashiers
The head office server and the store are Low
connected to each other via a network
Comments
Company A decided to choose the Web High
solution using ASP.NET MVC 3
framework, only Web browser, no local
Database needed for any POS terminal.
Table VIII 4) Technical constraint ranking
Team 3 – K15T1 – VLU
26
Version 2
IX.
Minimal Acceptable Delivery
Reference to K15T1_Team3_FinalProject_MasterDesignPlan, part III.4.b) Deliverables
X.
Reference
(Anthony J.Lattanze book)
Architecting.Software.Intensive.Systems.A.Practitioners.Guide.Nov.2008.eBook-DDU
[Page 231]
K15T1_Team3_FinalProject_MasterDesignPlan.docx
Team 3 – K15T1 – VLU
27