dss 12 s4 03 requirementspecificationv0.9
TRANSCRIPT
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 1/20
School of Computer Science & Software Engineering
Bachelor of Computer Science (Digital Systems Security)
CSCI321- Project
Requirement Specification10 December 2012
Group: SS12/4B
Khoo Jun Xiang 4000766 [email protected]
Ang Wencan Stephen 4194032 [email protected]
Goh Kheng Siang Joel 4187490 [email protected]
Lim Sing Hui 4185948 [email protected]
Low Jia Hui 4186448 [email protected]
Supervisor: Mr Sionggo Jappit
Assessor: Mr Tan Kheng Teck
Document ControlTitle: Requirement Specification
Document Name: Software Requirement Specification
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 2/20
Requirement Specification [SS12/4B]
Page 2 of 20
Owner Current VersionLast Change on
Approved byDate Time
Khoo JunXiang V0.9 10-Dec-2012 8pm Project Manager
Distribution List
Name Title/Role Where
Mr Sionggo Jappit Supervisor SIM-UOWMr Tan Kheng Teck Accessor SIM-UOWKhoo Jun Xiang Project Manager SIM-UOWLow Jia Hui Software Architect SIM-UOWGoh Kheng Siang Joel Test Designer SIM-UOWLim Sing Hui UI Designer SIM-UOWStephen Ang Database Designer SIM-UOW
Record of Revision
Revision Date Description Section Affected Changes Made byVersion after
Revision
23/11/2012 Introduction & Glossary Introduction/Glossary Low JiaHui V0.1
7/12/2012 Update of Introduction & Glossary Introduction/Glossary Khoo JunXiang V0.2
7/12/2012 Added General Description General Description Khoo JunXiang V0.3
7/12/2012 Identification of Use Cases and
Actors
Functional
requirements
Low JiaHui, Khoo
JunXiang
V0.4
8/12/2012 Update and finalize use case diagram Functional
requirements
Low JiaHui, Khoo
JunXiang
V0.5
9/12/2012 Added textual description for use
cases
Functional
requirements
Low JiaHui, Khoo
JunXiang
V0.6
10/12/2012 Identify and added non-functional
requirements
Non-functional
requirements
Khoo JunXiang V0.7
10/12/2012 Identify and added other
requirements and constraints
Other requirements,
constraints
Khoo JunXiang V0.8
10/12/2012 Checking and finalizing document All Khoo JunXiang,
Low JiaHui
V0.9
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 3/20
Requirement Specification [SS12/4B]
Page 3 of 20
Contents
Document Control....................................................................................................................................1
1. Introduction.......................................................................................................................................4
1.1 Purpose ............................................................................................................................................ 4
1.2 Scope ............................................................................................................................................... 4
1.3 Approach ......................................................................................................................................... 4
2. Glossary.............................................................................................................................................5
3. General Description...........................................................................................................................6
3.1 Main Product Functions .................................................................................................................. 6
3.2 Software Functions ......................................................................................................................... 6
3.3 Hardware Functions ........................................................................................................................ 6
4. Requirements Definition...................................................................................................................7
4.1 Functional Requirements ................................................................................................................ 7
4.2 Non-functional Requirements ....................................................................................................... 17
4.3 Other Requirements ...................................................................................................................... 19
5. Main Constraints.............................................................................................................................20
6. Appendix.........................................................................................................................................20
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 4/20
Requirement Specification [SS12/4B]
Page 4 of 20
1. Introduction
1.1 Purpose
Software Requirements Specification (SRS) is at the Inception phrase of the RUP projects. Continuous
development of SRS can also be done In Elaboration phrase. This Software Requirement Specification states the
detailed requirements and specification of developing the DB-Wrapper, a database wrapper that protects against
inference attacks on statistical database. It describes the functionality and features of the Database Wrapper with
much consideration on the interface design, design constraints and other constraints such as performance and
consistency. This document is required to help to identify the Functional, Non-Functional and Other
requirements that are essential to developing the DB-Wrapper.
This requires several processes such as Requirement Gathering, Requirement Analysis and Requirement
Specification before separating them into different categories like Functional requirement, non-functional
requirement and other requirements. Requirement Gathering uses the different methods retrieve information of what the stakeholder expects from the database wrapper.
Requirement Analysis includes the process of pre-processing the requirements gathered and determine if the
requirement is achievable, measureable, testable, practical and applicable to the need of the system, if the
requirement does not meet the criteria mention above it will be consider to be dropped or prioritized differently.
1.2 Scope
The DS-Wrapper is intended to work as a query-filter like process process filter of queries that are not allowed.
The wrapper will act as a inference protection mechanism to protect the statistical database against disclosure of
confidential and sensitive information and applicable on ORACLE-express edition 10G. As part of the project,
the wrapper will provide Query Restrictions, Systematic Rounding, Query set-size control and Auditing to
prevent inferences attack. This will provide data confidentiality and integrity to the database.
1.3 Approach
Our group used the Requirements Elicitation Approaches to gather requirements and identify key system
functionality including use cases, role-playing, stakeholders, team meeting and prototyping. Meeting between
team members are held to brainstorm and do an analysis on the requirements. Detailed key actors and use cases
are being drafted so that all stakeholders can easily understand them the illustrations and our members can use
them as direct input for our the different components that we have to do.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 5/20
Requirement Specification [SS12/4B]
Page 5 of 20
2. GlossaryEXPLANATION
Requirements
Elicitation Approaches
Requirements elicitation itself is a very complex process involving many activities,
with multiple techniques available to perform these activities. The multi-disciplinary
nature of requirements elicitation only adds to this complexity. The term elicitation is
used in books and research to raise the fact that good requirements cannot just be
collected from the stakeholder. Requirements elicitation practices include interviews,
questionnaires, user observation, workshops, brainstorming, use-cases and role-
playing.
Inference Attack Inference Attack is a data mining technique performed by analyzing data in order to
illegitimately gain knowledge about a subject or database. Attackers derive sensitive
data using queries that pose to reveal only non-sensitive data.
DB-Wrapper The product this document is specifying. DB-Wrapper acts as a filtering wrapper
around the database which provides inference protection.
SRS Software Requirement Specification
SQL Database transaction language
Oracle XE 10g Oracle Database 10g Express Edition is a free version of relational database. An
intuitive, browser-based interface, to administer the database, create tables, views,
and other database objects, import, export, and view table data, run queries and SQL
scripts, generate reports, etc
DBA Database Administrator
SQL*Plus Oracle utility, basic command-line interface which helps users, administrators and
programmers to access data
Use case A list of steps which define the interactions between a role and a system to achieve a
function.
Use Case diagram Graphical representation of a user’s interaction with the system and depicting the
specifications of a use case.
Functional
requirements
Defines the capabilities and functions that a system be able to perform.
Non-Functional
requirements
Criteria used to judge the operation of a system, rather than specific behavior.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 6/20
Requirement Specification [SS12/4B]
Page 6 of 20
3. General Description
3.1 Main Product Functions
1. Query Restriction – Filter results of every user queries. Display those results which will not cause an
inference attack in statistical database.
• Only allow aggregate queries: SUM, COUNT, AVG, etc.
• Do not allow overly selective queries
: SELECT … WHERE income = “2500”
• Only return the range it belongs to rather than exact values for sensitive data
: Income ($2000-$3000): 100-150 records found
2.
Systematic Rounding – Round query result, to the nearest multiple of a certain base b, beforedisplaying it to the user.
3. Query set size control – Allows only those queries that is within a certain bound size. The lower andupper bound is set based on the properties of the database and on the preferences fixed by the source
code implementer, after discussion with the database administrator.
4. Auditing – Keeping up-to-date logs of all queries made by each user and constantly checking for possible disclosures of sensitive information to unauthorized personnel, whenever a new query is
issued.
5. There will be 2 LOGFILES, ‘ERROR LOGFILES” and “SUCCESS LOGFILES” used to store error
queries and success queries respectively. Administrator able to open log files in a new window byentering command “OPEN Error LOGFILE” or “OPEN Success LOGFILE” in SQL *PLUS.
6. Administrator able to update upper and lower bound size for “Query set size control’ by entering
command “SET UPPER BOUND = ____” or “SET LOWER BOUND = ____”. – DB Wrapper willopen update the upper or lower bound respectively.
3.2 Software Functions
DB-wrapper must at the minimum be able to be configured and integrated into Oracle Database Express Edition
10g. Users are able to use SQL *Plus to as command line interface to access the Oracle database and executequeries commands.
3.3 Hardware Functions
Although it configuration and integration of DB-wrapper must be at all platform that is able to install and run
Oracle database, the minimum requirement is to run DB-wrapper in Window operating system. User PC musthave the capabilities to install and run Oracle.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 7/20
Requirement Specification [SS12/4B]
Page 7 of 20
4. Requirements Definition
4.1 Functional Requirements
Functional Requirements define all the services provided by DB-Wrapper to its users. The functional
requirements will be described in use-case diagrams, which is essential in requirements elicitation. Use casemodeling provides a clear view of the real system needs to its stakeholders. It shows clearly different
interactions that can take place between a user and a system. Narrative text used in use case textual descriptionwill allow stakeholders to easily understand the functions. Use case diagrams also ease the development team
when they are trying to spot what might go wrong.
Use Case Diagram:
The above use case diagram shows the functions provided by an oracle database system that is integrated with aDB-Wrapper. Red color use cases are the functions of DB-Wrapper . Reason behind choosing the product
boundary to be “Oracle DB integrated with “DB-Wrapper” instead of just “DB-Wrapper” is to let end-users have
a clear view of what improvements the products will provide to the user after integration.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 8/20
Requirement Specification [SS12/4B]
Page 8 of 20
Actor Description:
User: All users of the database system.
Administrator: Having the privileges to view LOGFILES and update bound size for “Query Set-Sizecontrol”. Default username is “admin”. Default password is “password123”.
Use Case Textual Description:
Use Case: Login
Primary Actor: User, Administrator
Description: This use case handles login for the user. Authentication will be done so that if adminentered an invalid username and password, error message will be displayed. System will
recognized user as administrator or normal user based on the login ID after successfully
logged in.
Pre-condition: NIL
Main Success Scenario:1. Open command prompt and type in SQL *Plus. - System will ask for username and password
2. If already has an account, then enter username and password.3. System will authenticate login information. If the username and password is valid, error logged in message
will be displayed.4. Login details will be redirected from DB-Wrapper to Oracle database so that DB-Wrapper will be able to
identify the user.
Extensions2a. Do not have an account.
2a1. Request for username and password from the administrator. Administrator will create new login detailsfor the user in the database. Use case resume in step 1 of main success scenario.3a. Invalid login information
3a1. System prompts again for login information. Use case resume in step 2 of main success scenario.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 9/20
Requirement Specification [SS12/4B]
Page 9 of 20
Use Case: Authentication
Primary Actor: User, Administrator Description: Authenticate login details inputs.
Pre-condition: User must be logged in.
Main Success Scenario:1. Reject/Accept users based on the login details.
Extensions NIL
Use Case: Redirect login
Primary Actor: User, Administrator Description: Login details will be redirected
Pre-condition: User must be logged in.
Main Success Scenario:1. Login details will be redirected from DB-Wrapper to Oracle database.
2. DB-Wrapper will be able to identify the user.
Extensions NIL
Use Case: Make Query
Primary Actor: User
Description: This use case handles submitting of query request for the user. Error messages will bedisplayed if SQL statement is not valid.
Pre-condition: User is successfully login to the system
Main Success Scenario:
1. User login to the system.2. User enters the SQL queries. System will verify if it is a valid SQL statement.
Extensions
1a. Do not have an account.1a Request for username and password from the administrator. Administrator will create new login details
for the user in the database. Use case resumes in step 2 of Main Success Scenario.
1b. Invalid login information1b1. System prompts again for login information. Use case resumes in step 2 of Main Success Scenario.
2a. Input is not a valid SQL statement
2a1 System will prompt that the input is a non-SQL statement. Use case ended.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 10/20
Requirement Specification [SS12/4B]
Page 10 of 20
Use Case: Query Filter
Primary Actor: User Description: This use case handles all the verification of query request for the user to determine if the
query made is legal. Error message will be displayed if the query is illegal after checking. Queries will be logged if legal.Pre-condition: Query is submitted to process for results
Main Success Scenario:
1. User login to the system. System wait for query input.2. User submits the query.
3. Various checks will be executed by DB-Wrapper if SQL statement is valid and does not contain anysyntax error.
4. DB-wrapper ensures the query is not overly -Selective. (Use case: “Check Overly – Selective”)
5. DB-wrapper ensures the query is Non-aggregation (Use case: “Check Non-Aggregation”)
6. DB-wrapper ensures that the result of query set – size is within the lower and upper bound limit.
(Use case: “Check Set-size”)7. DB-wrapper checks against Log records that nothing can be infer from the query.
(Use case: “Check log”)
8. Query is legal. Proceed to log query in logfiles.
Extensions3a Query is invalid and contains syntax error.3a1 Error message is displayed. Use case resumes in Step 2 and Main Success Scenario.
8a Query is illegal.
8a1. Reject query and display error message. Recorded into the “error logfiles” if query is valid but illegal.
Notes:
• Valid query is a proper SQL statement.
• Invalid query is unrecognizable SQL statement with syntax errors.
• Illegal query is proper SQL statement that does not pass the 4 checks indicated in Step 4 to 7 of Main Success Scenario.
• Legal query is proper SQL statement that passes the 4 checks indicated above.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 11/20
Requirement Specification [SS12/4B]
Page 11 of 20
Use Case: Check Overly - Selective
Primary Actor: User Description: This use case handles all the verification of query request for the user to determine if the
query made will result in having a overly – selective result. Query will be rejected if so.Error message will be displayed.Pre-condition: Query is submitted to process for results
Main Success Scenario:
1. User login to the system.2. Query is made and submitted for verification
3. Ensure the query is not overly -Selective.
Extensions
3a. The query is identified with overly – selective query results
3a1 The query will be rejected and log into the “error logfiles” for further uses. Use case ended.
Use Case: Check Non-aggregations
Primary Actor: User.
Description: This use case handles all the verification of query request for the user to determine if thequery made consist of non-aggregation SQL function calls. Query will be rejected if so.
Error message will be displayed.
Pre-condition: Query is submitted to process for results
Main Success Scenario:
1.
User login to the system.2. Query is made and submitted for verification3. Ensure the query does not contain non-aggregation functions
Extensions3a. The query is identified to contain non-aggregation query.
3a1 The query will be rejected and log into the “error logfiles” for further uses. Use case ended.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 12/20
Requirement Specification [SS12/4B]
Page 12 of 20
Use Case: Check Set-size
Primary Actor: User.Description: This use case handles all the verification of query request for the user to determine if the
query made will return a result that is less than the lower bound set size or more than theupper bound set size. Query will be rejected if so. Error message will be displayed.Pre-condition: Query is submitted to process for results
Main Success Scenario:
1. User login to the system.2. Query is made and submitted for verification
3. Ensure the query will not return a query result that is out of the range of the upper and lower bounddeclared in the set size.
Extensions
3a. Result of query is more than the upper bound or less than the lower bound size.
3a1 The query will be rejected and log into the “error logfiles” for further uses. Use case ended.
Use Case: Check Log
Primary Actor: User.
Description: This use case handles all the verification of query request from the user. It determine
whether the query made when compared with other information of previous queriesshow signs of inference attack
Pre-condition: Query is submitted to process for results
Main Success Scenario:1. User login to the system.
2. Query is made and submitted for verification
3. Ensure the query will not return a query result which can be use to infer information with multiple pastqueries
Extensions3a The query that result in returning a result which will compromise the security by inference attack when
use along with previous queries3a1 The query will be rejected and log into the logfiles for further uses. Use case ended.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 13/20
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 14/20
Requirement Specification [SS12/4B]
Page 14 of 20
Use Case: Display Query Result
Primary Actor: NILDescription: System will generate result from a query made by a user. Result returned might be in a
range or might be rounded up.Pre-condition: A query must be made. System must determine whether to round up the result valuedisplay a range where the result will be in.
Main Success Scenario:
1. User enter an SQL query through SQL *Plus interface.2. System randomly selects whether to display range value of result or rounded up value of result.
3. System display result to the SQL *Plus interface terminal.
Extensions
2a. Query made is deemed to be rejected which will be indicated by the DB-Wrapper.
2a1. System display “result rejected” messages instead of the original result. Use case ended.
Use Case: Return range value
Primary Actor: NILDescription: System will display a range where the result will be in.Pre-condition: A query must be made. System must select to return the range value where the result
will be in instead of systematic rounding.
Main Success Scenario:1. DB-Wrapper received SQL query from user input. SQL query is not rejected.
2. DB-Wrapper generated results and randomly selected to display a range where the result will be in.
3. DB-Wrapper generates the range.4. DB-Wrapper display the range value to the SQL *Plus interface terminal.
Extensions
2a. Query made is deemed to be rejected which will be indicated by the DB-Wrapper.2a1. System display “result rejected” messages instead of the original result. Use case ended.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 15/20
Requirement Specification [SS12/4B]
Page 15 of 20
Use Case: Systematic Rounding
Primary Actor: NILDescription: System will round up the result value.
Pre-condition: A query must be made. System must select to do systematic rounding instead of selecting to return the range value where the result will be in.
Main Success Scenario:
1. DB-Wrapper received SQL query from user input. SQL query is not rejected.2. DB-Wrapper generated results and randomly selected to display a range where the result will be in.
3. DB-Wrapper generates the range.4. DB-Wrapper display the range value to the SQL *Plus interface terminal.
Extensions
2a. Query made is deemed to be rejected which will be indicated by the DB-Wrapper.
2a1. System display “result rejected” messages instead of the original result. Use case ended.
Use Case: View LogFiles
Primary Actor: Administrator Description: This use case handles auditing and viewing of log files by the administrator.
Administrator need to view log files for maintenance and identify any indication of
inherence attack that is not identified by the system. Follow-up actions such as improvethe DB-Wrapper functionality then can be done accordingly.
Pre-condition: Administrator must be logged in as admin.
Main Success Scenario:
1. Administrator login to the system as admin.
2. Administrator enters command “OPEN Error LOGFILE” or “OPEN Success LOGFILE”. – DB Wrapper willopen the respective log files in a new window.3. Administrator view log file.
Extensions NIL
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 16/20
Requirement Specification [SS12/4B]
Page 16 of 20
Use Case: Set bound size
Primary Actor: Administrator Description:
Pre-condition: Administrator must be logged in as admin.
Main Success Scenario:1. Administrator login to the system as admin.
2. Administrator enters command “SET UPPER BOUND = ____” or “SET LOWER BOUND = ____”. – DB
Wrapper will open update the upper or lower bound respectively.
Extensions NIL
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 17/20
Requirement Specification [SS12/4B]
Page 17 of 20
4.2 Non-functional Requirements
Non-functional requirements are critical for the products as it specified criteria used to judge the
operation of a system. Those criteria will determine the quality of the system as well as the amount of
assurances provided for users.
S/N Non-Functional
Requirements
Explanation
1 Operational requirements DB-wrapper must be fully operational and will always be
available when users access the oracle database to do
queries. It is expected to at least operate fully in Window
platform. DB-wrapper must not malfunction and display
information that will lead to a success in inference attack from attackers. Deficiencies during the developing and
implementing process must be noted down and be solved
before releasing/submitting the product. All mission
performance assumptions must be documented to assist in
solving current faults and future maintenance.
Requirement elicitation approach is used to identify what
the system must accomplish and how well. Critical and
desired user performance must be established and agreed
by system stakeholders.
2 Performance requirements DB-wrapper needs to be able to support significant
amount of users. Response time should be as short as
possible and variation should be kept to the minimum.
Response time requirement should be meet as the
workload scales. DB-wrapper is integrated into the oracle
database and will not consume much memory space.
3 Interface requirements There won’t be much user interface for the user as DB-
wrapper will only sit on top of its Oracle Database and
filter results or user queries. The main interface will comefrom the Oracle Database itself using SQL *Plus utility.
Integrate steps should be clear and simple for users with
no technical knowledge to set up. User should be assumed
to have no technical knowledge and able to use the
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 18/20
Requirement Specification [SS12/4B]
Page 18 of 20
program without any special training.
4 Safety requirements Safety standards must be designed during the
development process to ensure safety of products, and/or processes. Necessary activities must be well-described in
the standard.
5 Security requirements DB-wrapper should be as robust as possible. Development
and implementation teams should develop the system with
good architectural principles and good practices standard.
Escalation of privileges from unauthorized personnel
should not be possible. All critical-level functions will be
protected against and verified in security testing. Audit
log must be verbose and clear.
6 Portability requirements DB-wrapper can be integrated into any window PC
provided that Oracle Database is installed in the terminal.
DB-wrapper and its source code must be available in the
PC in order to do so. DB-wrapper and its source code can
be transferred to different terminal through the internet or
external storage devices.
7 Authorization requirements No unauthorized personnel are able to view source code
of DB-wrapper. They are also not able to obtain the actual product and its configuration files. Users can request the
source code from the administrator or the development
team.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 19/20
Requirement Specification [SS12/4B]
Page 19 of 20
4.3 Other Requirements
S/N Other Requirements Explanation
1 Documentation requirements All documents required stated in the timeline of the
project will be completed. Table of contents of all
documents must be clearly defined. Various kinds of
documentation will be used. For example, diagram (use
case) is used in this requirement specification document.
Comments and other notations will be included in the
source during implementation as a form of documentation.
There will be PowerPoint slides for all presentation.
7/30/2019 DSS 12 S4 03 RequirementSpecificationv0.9
http://slidepdf.com/reader/full/dss-12-s4-03-requirementspecificationv09 20/20
Requirement Specification [SS12/4B]
Page 20 of 20
5. Main Constraints1. DB-Wrapper is implemented to integrate only into Oracle Database.
2. Checking of inference and data filtering should be as fast as possible.
3. Although it configuration and integration of DB-wrapper must be at all platform that is able to
install and run Oracle database, the minimum requirement is to run DB-wrapper in Window
operating system DB-Wrapper must run on all platforms that can install Oracle Database.
4. SQL *Plus must be pre-installed in user terminal.
5. A database script needs to be designed, with all its tables and data, and implemented into the
database to test up DB-wrapper functionalities.
6. Constant review, analyses and measurement of database data must be done to measure the amount
of protection needed for each attributes.
7. Severe restriction might occur and causes the database to be deemed as useless. Users will not be
able to get the most amount of information from their queries.
6. Appendix None