HPIMS_SRS v1.03

8/2/2019 HPIMS_SRS v1.03

1/24

Software RequirementsSpecification

For

HMC POI Inspection &Management System

Version 1.02

Prepared by 4WDICU-CMU MSE Studio Project Team

Feb 15, 2005

8/2/2019 HPIMS_SRS v1.03

2/24

Table of Contents

1. Introduction ....................................................................................... 1

1.1 Purpose ..........................................................................................................11.2 Scope ..............................................................................................................11.3 Definitions, acronyms, and abbreviations .......................................................1

1.3.1 Definition ..................................................................................................11.3.2 Acronym ....................................................................................................1

1.4 References .......................................................................................................21.5 Overview .........................................................................................................2

2. Overall Description ............................................................................. 3

2.1 Product Perspective .........................................................................................32.2 Product Features ..............................................................................................32.3 User Classes and Characteristics .....................................................................42.4 Operating Environment ...................................................................................4

2.5 Design and Implementation Constraints .........................................................42.6 User Documentation ........................................................................................42.7 Assumptions and Dependencies .....................................................................4

2.7.1 Assumptions ..............................................................................................4

3. Specific Requirement .......................................................................... 5

3.1 External Interface Requirements .....................................................................53.1.1 User Interfaces ..........................................................................................53.1.2 Hardware Interfaces ................................................................................113.1.3 Software Interfaces .................................................................................113.1.4 Communications Interfaces ....................................................................11

3.2 System Features ............................................................................................113.2.1 Data Inspection .......................................................................................11

3.2.2 Data Cleansing ........................................................................................123.2.3 Data Analysis ..........................................................................................123.2.4 Rule Configuration function ....................................................................133.2.5 Use case and Domain Object Model........................................................ 14

3.3 Software Quality Attributes ...........................................................................193.3.1 Performance Requirements .....................................................................193.3.2 Integrity Requirements ............................................................................193.3.3 Security Requirements ............................................................................193.3.4 Usability Requirements ...........................................................................193.3.5 Portability Requirements .........................................................................193.3.6 Other Requirements ................................................................................19

Appendix A: Rule Definition ................................................................. 20

Appendix B: Requirement Tracking Sheet ............................................. 21

ii

8/2/2019 HPIMS_SRS v1.03

3/24

Revision History

Name Date Reason For Changes VersionJonggul Park 21 Oct 20 04 Draft 0.10

Jaeha Song 17 Nov 2004 Refinement of draft 0.11Changki Kim 25 Nov 2004 Update Use Case, Data Model, some otherpart

0.12

Kuyul Noh 14 Dec 2004 Add description to Conceptual Model 0.13Jaeha Song 14 Dec 2004 Add description to Rule Configuration

function0.14

Jonggul Park 14 Dec 2004 Add User interface Prototype 0.15Changki Kim 14 Dec 2004 Add Rule definition Appendix 1.00Jonggul Park 15 Feb 2005 Refine System features 1.02Jonggul Park 2 May 2005 Add Analysis features 1.03

iii

8/2/2019 HPIMS_SRS v1.03

4/24

HMC POI Inspection & Management System Development Date: May 2,2004

Software Requirement Specification

1. Introduction

1.1 Purpose

The SRS document created by the 4WD team provides both the functional and non-functional requirements of the POI data management system (HPIMS). Thisdocument also includes definitions, specifications, and other information that willbe helpful for the customer, Hyundai Motor Company (HMC) and for the 4WD teamto have a clear understanding of the system to be developed.

From this document, the customer will be able to understand our teamscomprehension of the requirements. This document can be updated or revisedwhen required by the customer as we consider our customers demands importantfor our project. This document will evolve according to the requirement.

1.2 ScopeHMC Point of Interest (POI) Inspection & Management System (HPIMS) will handlethe original POI data provided by HMC. The original data shall be handled so thatthe errors such as duplication, logical inconsistency, etc., will be detected andcorrected according to the rules. The system allows rules to be defined. The outputof the system is also available as POI data in Microsoft Access database file format(*.mdb). This has the same database schema as that of the input POI data file. Inaddition to the database file output, the system will report the status of theinspection and modifications present.The system does not convert the POI data to its compressed form.

1.3 Definitions, acronyms, and abbreviations

1.3.1 Definition

Term DefinitionPoint of Interest

This is the data that will be used as location information

1.3.2 Acronym

CMU Carnegie Mellon UniversityDB DatabaseCVS Concurrent Versions SystemCSV Comma separated values. A file format in which lines of

comma separated texts is used to represent the POI data.

Microsoft Excel can read it into a worksheet.GUI Graphical User InterfaceHMC Hyundai Motor CompanyHPIMS Hyundai Motor Company Point of Interest Inspection &

Management SystemMDB Microsoft Access Database file or its file extension nameICU Information and Communication UniversityPOI Point of InterestSOW Statement of WorkSPMP Software Project Management PlanSRS Software Requirements Specification

Team name: 4WD ICU-CMU MSE Studio Project, 2012 Page 1 of 22

8/2/2019 HPIMS_SRS v1.03

5/24



1.4 References

Karl E. Wiegers SOFTWARE REQUIREMENTS, 2003 Microsoft

IEEE Guide to Software Requirement Specifications (ANSI/IEEE Std 830-1984)

1.5 Overview

In section 2, the project overview is described. We have also given information onwhat and how we will handle the project. In section 3, the detailed functional andnon-functional requirement is described in a way that no ambiguous aspects areleft. Section 4 describes the other requirement that is not described in section 3.


8/2/2019 HPIMS_SRS v1.03

6/24



2. Overall Description

2.1 Product Perspective

HMC manages around 2 million POI data every 6 months. It gets the original POIdata from third party content provider(s) who in turn get the POI data from the realinvestigation or telephone data. This collected POI data, is refined by HMC intoclean POI data which will be sent to the commercialization process.Commercialization process is a method by which the refined POI data iscompressed so that various forms of car navigation information can be developed

such as CD, DVD, etc. To get highly qualified POI data, it is necessary to apply a series of complexfunctions of data manipulation in the refinement process, such as removing theduplication, finding and removing logical inconsistency, and free editing of dataitems. Figure 1 shows the overall process of the POI data refinement. POI Inspection& Management System support refinement process from original collected data torefined DB with inspection and cleansing. How we inspect and cleanse the POI datais analyzed for the purpose of checking the quality of the data source. The analysisof the data itself is also a key function of the HPIMS.

2.2 Product Features

HPIMS consists of three functional parts. Data Inspection Function, Data Cleansing


Figure 2-1: Overall description of POI DB refinement process

CollectedPOI DB

RawPOI DB

real

survey

telephonedata Raw

POI DB

POI DataInspectionPOI DataCleansing

POI Data Analysis

gathering commercialization

RefinedPOI DB

refinement

8/2/2019 HPIMS_SRS v1.03

7/24



Function and Analysis Function: This program also provides Graphical UserInterface (GUI) for the user. The three major functions are as follows- Data Inspection Function: Duplication check, multimedia data file check, andlogical inconsistency inspection- Data Cleansing Function: Duplication, logical inconsistency elimination- Data analysis function: Statistical representation of raw POI data, errors found byinspection, numbers, and history of them.In addition to the three main functions, import function from CSV file (*.csv) andexport function to CSV file (*.csv) will be provided for the convenience of theuser.Rules for POI data inspection and cleansing will be supported in a pluggable way incase there is a possibility to add more enhanced rules for inspection and cleansingin the future without significant change on the system structure.

2.3 User Classes and Characteristics

There is only one type of user: the HMC inspector of the POI data provided by third

party. The user has superior knowledge on the POI data.

2.4 Operating Environment

The target system is a standalone application in a PC environment on MS WindowsXP with Microsoft Access DB. The system will be developed using platform-independent Java language, so the underlying operating environment can bechanged with little cost.Since the target system deals with voluminous data, large size of main memory isnecessary: Giga Bytes of Main Memory or more.

2.5 Design and Implementation Constraints

All codes shall be written in Java-family language.

2.6 User Documentation

The lists of document delivered to the user along with the software are as follows.- For project management artifacts, standard format we developed is used: SOW,SRS, SPMP.- Product (the system) definition document- Product user manual- For final Report, ICU format is used.

2.7 Assumptions and Dependencies

2.7.1 Assumptions

2.7.1.1 Number of maximum POI data item

The number of maximum POI data item does not exceed 500 million.


8/2/2019 HPIMS_SRS v1.03

8/24



3. Specific Requirement

3.1 External Interface Requirements

3.1.1 User Interfaces

This user interface is prototype made after discussion among 4wd team. This willhelp the client to see the user interface of our final program artifact in this project.The contents and appearance can be changed or refined based on the usersrequirement and technical constraints.

3.1.1.1 User interface architecture

This is the overall architecture of HPIMS prototypical user interface. The userinterface is divided into four, mainly based on the functions of HPIMS.

Figure 3-1 User interface architecture

3.1.1.2 Rule Group Manager

The Rule group manager function is composed of 4 functions: Rule group creation,Rule group change, Rule group deletion, Rule description inquiry. The rule configured with this interface shall be used in the inspection and

cleansing. The rule can be managed with the group that has the rule the systemalready has. With the combination of the rules, you can have various inspectionsdepending on the criteria of your inspection.The groups of rules are managed through files and they can be changed by addingor deleting rules through the panel below.The description of the rule with the rule description inquiry is shown in figure 3-3.


8/2/2019 HPIMS_SRS v1.03

9/24



Figure 3-2 Rule Group Manager - Selection

Figure 3-3 Rule Group Manager - Rule Inquiry

3.1.1.3 Inspection Manager

This function is the key function of the HPIMS. With the rule group defined in theRule Group Manager panel, you can inspect the data as Figure 3-4.


8/2/2019 HPIMS_SRS v1.03

10/24



Figure 3-4 Inspection Manager - Inspection Condition Selection

The result of the inspection execution will be shown as follows.

Figure 3-5 Inspection Manager - Inspection Summary Report

By clicking the Detail Inquiry button in the right-most column of the inspectionresult will provide detailed information on the error. The history of each inspectionreport is shown in the inspection history as Figure 3-7.


8/2/2019 HPIMS_SRS v1.03

11/24



Figure 3-6 Inspection Manager - Detail Inspection Report

Figure 3-7 Inspection Manager - Inspection History

3.1.1.4 Cleansing Manager

The cleansing activity can be done in two ways such as manually or through batchoperation. The first method is manual work with the output from the inspection.The correction or deletion can be done with this output of the inspection execution.The second way is batch operation with the rule configured in the Rule GroupManagement panel. The batch cleansing execution, the result of the execution, andthe history of the cleansing operation is shown in Figure 3-8, Figure 3-9, and Figure3-10.


8/2/2019 HPIMS_SRS v1.03

12/24



Figure 3-8 Cleansing Manager - Batch Operation

Figure 3-9 Cleansing Manager - Cleansing Report


8/2/2019 HPIMS_SRS v1.03

13/24



Figure 3-10 Cleansing Manager - Cleansing History

3.1.1.5 Analysis Manager

The analysis manager consists of two parts: the analysis about the data itself andthe analysis on inspection or cleansing data. The analysis of data itself includes thenumber of data in each region, the number of the data in each kind, and thecombination of those. The history of the updated data is shown to track the trendof update. (Figure 3-11). The analysis of the inspection or cleansing work is alsodisplayed in Figure 3-12. As for inspection, it includes the number of inspection

results in each region and kind. As for cleansing, it includes the number ofcleansing results in each region and kind. Also, history of cleansing is tracked.

Figure 3-11 Analysis Manager - Changed Data History


8/2/2019 HPIMS_SRS v1.03

14/24



Figure 3-12 Analysis Manager - Inspection and Cleansing Analysis

3.1.2 Hardware Interfaces

N/A

3.1.3 Software Interfaces

MS Access DB will be accessed through JDBC interface in java program

3.1.4 Communications InterfacesN/A

3.2 System Features

3.2.1 Data Inspection

3.2.1.1 Introduction/Purpose of feature

The original POI data collected and delivered by POI content providers can havesome errors such as data duplication, logical inconsistency, missing multimedia.The system will find all the erroneous data according to the rules defined.

3.2.1.2 Stimulus/Response Sequences

3.2.1.2.1 The input is POI data and defined rules. The system shall let the userconfigure the criteria for the rules and specify the MS Access DB file.

3.2.1.2.2 The data that matches the defined rules will show up on the screen asproblematic items, and the system shall save the findings for the purpose of using it inthe data cleansing function when the user wants to do so.

3.2.1.2.3 After completing inspection, the user can get the result in a convenientform as a report or can export it to the CSV file so as to open it in MS Excelapplication.


8/2/2019 HPIMS_SRS v1.03

15/24



3.2.1.3 Associated functional requirement

3.2.1.3.1 The system shall provide the addition of rules function. The system

shall support pluggable rule addition or deletion. When the user has found someadvanced rules for inspection or cleansing, they can program it into java componentwith interfaces predefined by the system. Then, the system can load the newly addedrules from the predefined location in the file system.

However, the system does not support dynamic building of rule in combinationwith existing rules or scripting of elementary operations. In addition, the systemdoes not support dynamic load or unload of new rules: it needs to restart in orderto load or to unload rules.

3.2.1.3.2 The system shall provide a user interface to let the user select the rulesamong the loaded ones and configure the parameters for each selected rules.

3.2.1.3.3 The system shall provide a user interface to let the user edit, modify,

and delete POI data items directly. With this functionality, the user can deal witherroneous data detected but unable to cleanse automatically.

3.2.1.3.4 The result of inspection shall be analyzed in terms of datacharacteristics and inspection history. This function is described in 3.2.3.

3.2.2 Data Cleansing


The system shall repair the errors in the POI data using defined rules.


3.2.2.2.1 The input is the POI data and the defined rules. The system shall let auser open POI DB file and select the rules for cleansing. The data items that matchthe selected rules shall be corrected based on those rules.

3.2.2.2.2 Data cleansing shall be executed after the data inspection or beexecuted independently.

3.2.2.2.3 The system shall store the result of data cleansing in another AccessDB file.

The result of data cleansing can be exported to the CSV file with some importantcolumns encrypted.


3.2.2.3.1 After data cleansing function, the related information of changed datashall be saved in a new MDB file for future analytical use.

3.2.3 Data Analysis


The POI data and result of inspection and cleansing shall be analyzed to show thestatistical results. The result of inspection and cleansing shall be stored andmanaged so that the trend of error and change is clearly shown. The user wouldlike to know how many POI data there are in each region, or in each kind among

total POI data, and the user would like to know how many duplicated data there


8/2/2019 HPIMS_SRS v1.03

16/24



are. Also, the user wants to know history and statistical information of changeddata. The changed history can give some insight about what kind of data should bemanaged as core POI data that is important and doesnt change much.


3.2.3.2.1 The input is the POI data. The system shall enable a user to view thenumber of current POI data in each region or in each kind. This shows the status ofthe current data. The change of this number shall be tracked for historical analysis.

3.2.3.2.2 The input is the result of inspection. The system shall let the user seethe number of the errors found during inspection in each region or in each kind. Thechange of this number shall be tracked for historical analysis.

3.2.3.2.3 The output of analysis function shall be text, bar graph or chart graphwhich is to be determined with customerc consent.

3.2.4 Rule Configuration function


The user can configure the parameter of the inspection and cleansing rules. Therules can get input data, such as column names for checking duplication inspectionrule shown in Appendix B, inspection rules, to result in inspection result data andreport. For the rules, the system provides function to set the input data, select rulesto be applied, and manage the rules in categorized groups. The system can alsoprovide function to load or discard specific rules to and from the system itself, sothat the rules can be implemented and added continuously whenever new theneeds for new rules emerge.

3.2.4.2 Stimulus/Response sequence

3.2.4.2.1 The System shall provide user interface to load or remove rules to andfrom the system as well as grouping it into a rule group.

3.2.4.2.2 The System shall let the user store the configuration of the rules forlater use.

Each rule can have property setting user interfaces to get input data from the user.System detects the property setting user interface when it loads the rule andprovides the user chance to use it.


3.2.4.3.1 Rule group management

Loaded rules are to be categorized into some groups, so that they can be referredby dealing with groups. Group does not form a hierarchy: a group can only haverules as its children.

3.2.4.3.2 Rule component management

System provides function to load new rules and discard existing ones for the sakeof users selection.

3.2.4.3.3 The system shall provide the programmer interface so that the user canadd the rules into the predefined rule set.


8/2/2019 HPIMS_SRS v1.03

17/24



3.2.4.4 Rule Definition Sheet

The predefined rules are attached in Appendix A.

3.2.5 Use case and Domain Object Model

3.2.5.1 Use case & description

Inspect POI Data

Cleanse POI Data

Analyze

User

Configure Rule

Figure 3-13 Use Case diagram of HPIMS

User Case ID Primary Actor Use Cases

UC01 User Inspect POI DataUC02 User Cleanse POI Data

UC03 User Analyze

UC04 User Configure Rule

Use Case ID: UC01Use CaseName:

Inspect POI Data

Created By: JG Park Last Updated By: JG ParkDate Created: Dec. 2, 2004 Date Last

Updated:Dec. 2, 2004

Actors: UserDescription: The user find the defective data from the *.mdb file

which has the POI information


8/2/2019 HPIMS_SRS v1.03

18/24



Preconditions: 1. The User has the access file to inspect.Postconditions: 1. All the duplication and logical inconsistent data are

found from original POI access database.Normal Flow: 1. The use chooses inspection menu item.

2. The user opens the access file that he wants toinspect.3. The user chooses the rule to apply in this inspection.4. The use executes the inspection function.5. The system output the result of the inspectionfunction after some time.6. The user sees the result and use Analyze theinspected data use case.

Alternative Flows: 3a The values are within tolerance range.3a1 Do nothing.

Exceptions:

Includes:Priority: HighFrequency of Use:Business Rules:Special Requirements:Assumptions:Notes and Issues:


Cleanse POI data

Created By: JG Park Last Updated By: JG Park

Date Created: Dec. 2, 2004 Date LastUpdated: Dec. 2, 2004

Actors: UserDescription: The user cleanses the output data from inspection with

the cleansing rule or in a manual manner.Preconditions: 1. The user have already inspected original access file.Post conditions: 1. The user applied the correction process with the

cleansing rule or with the manual correction and as aresult cleanses the original POI data.

Normal Flow: 1. The user chooses cleanse menu item.2. The user opens the access file he wants to cleanse.

3. The user chooses the cleansing logic from the rulesyou defined for cleansing.4. The user activate cleanse button.5. The user can use Analyze use case with thecleansing history.

Alternative Flows: 4a. When no inspection was done about chosen accessfile, warning message is shown.5a. When no cleansing was done, warning message isshown.

Exceptions:Includes:Priority: HighFrequency of Use:

Business Rules:


8/2/2019 HPIMS_SRS v1.03

19/24



Special Requirements:Assumptions:Notes and Issues:


Analyze

Created By: JG Park Last Updated By: JG ParkDate Created: Dec. 5, 2004 Date Last

Updated:Dec. 5, 2004

Actors: UserDescription: The user analyzes the data itself or inspection result.Preconditions: 1. The user has already inspected original access file

when the user wants to analyze the inspected data.2. The user ha already cleansed the original data whenthe user wants to cleanse the data.

Post conditions: 1. The user gets the information about the data orinspected data.

Normal Flow: 1. The user chooses analysis menu.2. The user chooses the information he wants to have3. The user activates analyze button

Alternative Flows: 2a. The user can choose inspection analysis2b. The user can choose cleansing analysis.2c. The user can choose data analysis.

Exceptions: 2a. The user didnt inspect the data yet.2b, The user didnt cleanse the date yet.

Includes:Priority: HighFrequency of Use:Business Rules:Special Requirements:Assumptions:Notes and Issues:


Configure Rule

Created By: JG Park Last Updated By: JG Park

Date Created: Dec. 5, 2004 Date LastUpdated: Dec. 5, 2004

Actors: UserDescription: The user defines the rule by which to inspect or cleanse.Preconditions: 1. No precondition is O.K. Sometimes in the inspection

or cleansing process, you can edit the rule you want.Post conditions: 1. The rule was defined so that this rule can be added to

the rule set.

Normal Flow: 1. The user chooses Rule menu.2. The user defines the rule with options combinedtogether.

3. The defined rule is named for future use.


8/2/2019 HPIMS_SRS v1.03

20/24



Alternative Flows:Exceptions:Includes:Priority: HighFrequency of Use:Business Rules:Special Requirements:Assumptions:Notes and Issues:

3.2.5.2 Conceptual Architecture

Following Figure 3-2 shows the conceptual architecture and the flow of informationof the whole system.

The contents provider creates some of POI data. Another POI data are come fromyellow book. From this raw data, integrating and cleansing works are performed toenhance correctness and add value. The POI DB is provided to HMC, and then POIInspection & Management System performs the inspection and some cleansingworks.The POI Inspection & Managements System are consisting of POI DB for datamanagement, Memory DB for fast transaction management, and applicationcomponents and user interfaces for business logic management by the inspectionofficer.

After inspection, the POI DB passed to POI Master DB for product ionization to the


Figure 3-15 Conceptual architecture of system feature

8/2/2019 HPIMS_SRS v1.03

21/24



media like DVD, CD, and Hard Disk. Finally, the end customer uses the POI Data atthe navigation system.

3.2.5.3 Data ModelFollowing Data Model shows the existing data schema.

Most of entities are connected to POI_I_COMMON entity, POI Common Information

entity. In addition, most of information is partitioned by subject like Golf POI Data,SKI POI Data. Above data schema is from sample DB, therefore the schema haslimited information. The enhanced DB schema will be designed during designphase.Following table shows above schema name and description.No Schema Name Schema Description1 POI_I_COMMON POI General Information Table2 POI_I_TF_VERSION POI DB Version Control Table3 POI_I_PIC_INFO Photo Information Table4 POI_I_TYPEA Open Time Information Table5 POI_I_TYPEC Reservation Information Table6 POI_I_TYPED Tour Course Information Table7 POI_I_TYPEF Facility Information Table8 POI_I_TYPEG Sales Products Information Table9 POI_I_TYPEH Hotel Information Table

10 POI_I_TYPEM Membership Information Table


Figure 3-16 Data object model of the system

8/2/2019 HPIMS_SRS v1.03

22/24



11 POI_I_TYPEP Parking Information Table12 POI_I_TYPEU Credit Card Information Table13 POI_I_DGUIDE Drive Course Information Table

14 POI_I_GOLF Golf Course Information Table15 POI_I_HOSPITAL Hospital Information Table16 POI_I_TYPEHOSPITAL Hospital Subject Information Table17 POI_I_SKI1 Ski Course Information Table18 POI_C_CLASS KIWI Classification Code Table19 POI_C_ZIP Zip Code Table

3.3 Software Quality Attributes

3.3.1 Performance Requirements

3.3.1.1 The data inspection and analysis module shall be designed to execute completelyin 10 seconds except for a batch job. The cleansing module does not need to executecompletely in a short time, because of much data and lots of work.

3.3.2 Integrity Requirements

3.3.2.1 The original data taken from loaded several resources shall be able to keep theintegrity. The administrator user shall be able to trace the data change history by stage,and changer.

3.3.3 Security Requirements

3.3.3.1 The DB data is secured by encrypting the key field. And the text file that is theoutput of the system shall be encrypted.

3.3.4 Usability Requirements

3.3.4.1 The system must provide GUI (Graphic user interface) for user convenience.

3.3.5 Portability Requirements

3.3.5.1 The code source shall be able to migrate from PC environment to UNIX serverenvironment within 30% code migration work.

3.3.6 Other Requirements

3.3.6.1 The system shall make and maintain POI data for its own use such as summaryetc. but shall not change the original POI data.


8/2/2019 HPIMS_SRS v1.03

23/24



Appendix A: Rule Definition


8/2/2019 HPIMS_SRS v1.03

24/24



Appendix B: Requirement Tracking Sheet


Date post:	06-Apr-2018
Category:	Documents
Upload:	rajeshdiff6
View:	228 times
Download:	0 times

HPIMS_SRS v1.03

Documents