0% found this document useful (0 votes)
43 views23 pages

4.2.1.2 SECURITY: Security Components: Subsystem Name Data Sensitivity Level Security Control

The document provides details on the design of a library management system. It includes sections on security components, data architecture, system design, and user experience design. The security section lists subsystems and their sensitivity levels. The data architecture section describes data sources, data stores, retention policies, and conversion approaches. The system design section covers application design with common frameworks, subsystems, integration design, and data conversion. The user experience design section includes a sample home page layout with fields and validation.

Uploaded by

Edmon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
43 views23 pages

4.2.1.2 SECURITY: Security Components: Subsystem Name Data Sensitivity Level Security Control

The document provides details on the design of a library management system. It includes sections on security components, data architecture, system design, and user experience design. The security section lists subsystems and their sensitivity levels. The data architecture section describes data sources, data stores, retention policies, and conversion approaches. The system design section covers application design with common frameworks, subsystems, integration design, and data conversion. The user experience design section includes a sample home page layout with fields and validation.

Uploaded by

Edmon
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 23

4.2.1.

2 SECURITY
Security components:
Subsystem Name Data Sensitivity Level Security Control

23
4.2.1.3 INTEGRATION

Client Interface
DOCUMENT
Accounting Interface
MANAGEMENT

SYSTEM

LIBRARY SYSTEM

Client Interface
MOBILE LIBRARY Borrowing record interface
APPLICATION

Mobile library Document management


Library System
application system

JSON JDBC SOAP

Message Bus

24
4.2.2 DATA ARCHITECTURE

4.2.2.1 DATA SOURCE


DATA SOURCE DESCRIPTION TYPE OF DATA FREQUENCY OF
ACCESS
CRM system Centralized CRM Client information Once-off
system of all libraries in
Hong Kong

4.2.2.2 DATA STORE ARCHITECTURE

HK DATA
Master Dataset B

Read-only/Hidden

Master Dataset A

Read/ Writable

Master Dataset B
Master Dataset A
Read-only/Hidden
Read/ Writable
Address

1
* 1 1 *
Restriction Client Enquiry History

Core data entities:


Entity Entity Description
Client Personal information including DOR,HKID, gender
Address Correspondence / residential/ Work address of Client

4.2.2.3 DATA RETENTION AND ARCHIVE


Data retention and archive:
Data Element to be Archive Method and Data Retention Policy
retained and archive Frequency
Client record Annually Xx0000_policy_description

4.2.2.4 DATA CONVERSION ARCHITECTURE


Data conversion:
Data Source Target Anticipated
Volume

Client information e.g CRM system Library System 10GB


Database
*Baseline* application Data migration *Target” application
Components technology components

Customer
Relationship Source Transformation Target Library
Management staging and Data Quality Staging System
System

27
4.3 SYSTEM DESIGN
4.3.1 Application

Common Client

Document
management
system
Borrow
Engine

Item

28
4.3.1.1 DESIGN APPLICATION
4.3.1.1.1 DESCRIBE COMMON FRAMEWORKS
Spring Controller

Common
Entity
Controller

29
SECURITY  Support two-factor authentication
 HTTPS encryption
 Use parameterized Authentication
SQL queries
VALIDATION  Input validation at the presentation layer using
validation controls
 Business rule validation logic in domain object
TRANSACTION  Use multiple active result sets to allow
multiple queries to be executed using the
same connection Exception
Handling

Logging
 Implement compensating methods to revert
the data store to its previous state in case an
operation within then transaction fails.
LOGGING  Use Log4j for implementing logging
 No sensitive information in logs
 All logged message are times-stamped and
tagged with the name of the generating
controller
EXCEPTION HANDLING  Retry process for operations where data
source errors or timeouts occur
 Exceptions also posted in the windows event
logs
REFERENCE TABLE  Reference table for list of countries that can
be maintained
 Use Address Data Infrastructure
INTERNATIONALISATION  Support for Hong Kong Chinese Character Set
SAMPLE CODE ARTEFACT Nil

4.3.1.1.2 DESCRIBE EACH SUBSYSTEM INTO COMPONENTS

30

Borrow Engine

Borrow
Borrow Read
Controller 1

Common Library Member


Controller
-String code -Integer ID
*

1 *

Common
1
*

Items

31
32
33
Business rules description:
Rule# Rule Rule Rule Rule Rule Rule Depende
Attributes Conditions Actions Priority Validity ncy
<Input <Input name <Document the <Describe <input <Input the <Input the <Describe
Number defined> attributes and the
>
actions priority of constraint the
operation conditions
> the rule> s under dependen
performed> that the rule
checks> which the cy on
rule is another
valid> rule>

1 Book_issu User.ID Book.Issue Perfor 1 Rule is N/A


ed No.Book.Issu d=”Max m applicable
ed quota check only after
exceeded” wether Nov 2014
No.Boo
k.1

34
4.3.1.2 DESIGN INTERGRATION
4.3.1.2.1 DESIGN THE INETRGRATION DESIGN
Interface Interface Actors Context Preconditions Post
Name Frequency Involved goal conditions
Type

4.3.1.2.2 INCLUDE DATA MAPPING AND TRANSFORMATION RULES


Data control description:
<Source Required <Target Required (Y/N) Mapping logic
System> (Y/N) System> Data
Data Element Element

4.3.1.2.3 DESCRIBE DESIGN OF INTEGRATION SUB-SYSTEM.

4.3.1.3 DESIGN DATA CONVERSION

Source Source Destination Target Transformation/ Notes


Data Data Cleansing Rules
Entity Entity

4.3.1.4 USER EXPERIENCE DESIGN


35
Sample:
Element presented (if
applicable) : Home

Field Name in Table Name, Data Type Validation Comments


Mock-up Column Name
<Input> <Input> <Input> <Iput> <Input>
Keyword
About N/A Text Using No
the special N/A
Search
library

Borrow,
Search by
News Renew,
Title
Reserve

Advanced 37
Events FAQ
Search

Screen actions (if applicable):


Type Label Action Comments
Locations
<Input> <Input> <Input> Accessibility <Input>
Services
Button Search Search the database for N/A
Matching book titles

Messages (if applicable):


Message ID Description Type Triggering Event
<Input> <Input> <Input> <Input>
Error1 Display warning when Warning Search
No keyword is entered

38
4.3.2 DATA MODEL
4.3.2.1. LOGICAL DATA MODEL
Logical data entity description:
LOGICAL DATA ENTITY LOGICAL DATA ENTIY DESCRIPTION

<Include a Logical Data Model diagram that depicts the following:


 Logical Data Entity Groupings – a logical data entity grouping is a collection of
logically grouped attributes that are related to one another based on
characteristics of those attributes. This may include but is not limited to:
people, places, things, and concepts of interest to the business.

 Attributes – an attributes is a representation of a single elementary unit of


business information.

 Relationship – a relationship show how the logical data entity groupings are
related, including cardinality (one-to-one, one-to-many, many-to-many). In
relational logical models, many-to-many relationships must be resolved.>

39
4.3.2.2 PHYSICAL DATA MODEL
<Include the details of entities:
 Table Name: provide name of the table
 Field Name: provide name of the field
 Field Format: define the logical format of the field, e.g. Integer, Char
 Description: provide a brief description of the field (e.g. Date book was issued
to user)
 Mandatory: specify if the field is mandatory
 Primary Key: specify whether the field is used as primary key
 Foreign Key: specify the field name of another table for foreign key>
Physical data entity description:
Table Field Field Field Description Mandatory Primary Foreign
Name Name Format Length Key Key

40
41
5 TECHNICAL SYSTEM OPTION
5.1 TECHNICAL SYSTEM ARCHITECTURE
5.1.1 NETWORK ARCHITECTURE
42
5.1.2 STORAGE ARCHITECTURE
5.1.3 PLATFORM ARCHITECTURE
Environment Description:
Environmen Machine Hardware Description Software Quantity
t

43
5.2 SIZING MODEL
 Data storage
 Transaction Rate
 Data Access
 Server Sizing
 Network Sizing

44
5.3 COST / BENEFIT EVALUATION
5.4 IMPACT ANALYSIS
 Summary on system change/enhancements.
Provide a summary of system change/enhancements.
 Effect on organization and staffing levels
For each recommended initiative (as stated in the section above), highlight the
impact they may cause on the respective aspects.
 Significant changes in user operating procedures
From User’s perspective, highlight operational changes and potential challenges
they may face.
 Implementation considerations
Elaborate on the impact system may have on the organization, and measures to
resolve the mentioned issues. Implementation considerations range from
training to effects on inexperienced staff at service level.
 Saving on replaced equipment and associated costs
A set of estimated calculations on saving that may be achieved through
replacing existing system/ equipment and associated costs.
 Risk Analysis
List out a preliminary set of foreseeable risks in term of Project Management,
Staffing and Resource Change Management from implementing and introducing
the proposal system.

49
5.5 IMPLEMENTATION PLAN
 Implementation Strategy
Describes the implementation approach that will be adopted during the
implementation of the proposed system, based on a desire to minimize
dependencies or interfacing requirement, costs and organizational changes.
 Implementation Schedule
Implementation Timeline of the proposed system should take the following
activities into account and add appropriate buffer:
 Requirements
 Analysis and Design
 Development
 Testing
 Deployment
 Documentation
 Meeting and Review

 Activities
Describe each of the activities identified in detail. The document should also
highlight contingency plan for critical applications.

52

You might also like