HPIMS - SRS v1.03

Software Requirements Specification For HMC POI Inspection & Management System
Version 1.02
Prepared by 4WD ICU-CMU MSE Studio Project Team Feb 15, 2005
Table of Contents
1. Introduction.......................................................................................1 1.1 Purpose ..........................................................................................................1 1.2 Scope..............................................................................................................1 1.3 Definitions, acronyms, and abbreviations.......................................................1 1.3.1 Definition..................................................................................................1 1.3.2 Acronym....................................................................................................1 1.4 References.......................................................................................................2 1.5 Overview.........................................................................................................2 2. Overall Description.............................................................................3 2.1 Product Perspective.........................................................................................3 2.2 Product Features..............................................................................................3 2.3 User Classes and Characteristics.....................................................................4 2.4 Operating Environment...................................................................................4 2.5 Design and Implementation Constraints.........................................................4 2.6 User Documentation........................................................................................4 2.7 Assumptions and Dependencies.....................................................................4 2.7.1 Assumptions..............................................................................................4 3. Specific Requirement..........................................................................5 3.1 External Interface Requirements.....................................................................5 3.1.1 User Interfaces..........................................................................................5 3.1.2 Hardware Interfaces................................................................................11 3.1.3 Software Interfaces.................................................................................11 3.1.4 Communications Interfaces....................................................................11 3.2 System Features............................................................................................11 3.2.1 Data Inspection.......................................................................................11 3.2.2 Data Cleansing........................................................................................12 3.2.3 Data Analysis..........................................................................................12 3.2.4 Rule Configuration function....................................................................13 3.2.5 Use case and Domain Object Model........................................................14 3.3 Software Quality Attributes...........................................................................19 3.3.1 Performance Requirements.....................................................................19 3.3.2 Integrity Requirements............................................................................19 3.3.3 Security Requirements............................................................................19 3.3.4 Usability Requirements...........................................................................19 3.3.5 Portability Requirements.........................................................................19 3.3.6 Other Requirements................................................................................19 Appendix A: Rule Definition.................................................................20 Appendix B: Requirement Tracking Sheet.............................................21
ii
Revision History
Name Jonggul Park Jaeha Song Changki Kim Kuyul Noh Jaeha Song Jonggul Park Changki Kim Jonggul Park Jonggul Park Date 21 Oct 20 04 17 Nov 2004 25 Nov 2004 14 Dec 2004 14 Dec 2004 14 Dec 2004 14 Dec 2004 15 Feb 2005 2 May 2005 Reason For Changes Draft Refinement of draft Update Use Case, Data Model, some other part Add description to Conceptual Model Add description to Rule Configuration function Add User interface Prototype Add Rule definition Appendix Refine System features Add Analysis features Version 0.10 0.11 0.12 0.13 0.14 0.15 1.00 1.02 1.03
iii
HMC POI Inspection & Management System Development Software Requirement Specification
Date: 2004
May 2,
1.
1.1
Introduction
Purpose
The SRS document created by the 4WD team provides both the functional and nonfunctional requirements of the POI data management system (HPIMS). This document also includes definitions, specifications, and other information that will be helpful for the customer, Hyundai Motor Company (HMC) and for the 4WD team to have a clear understanding of the system to be developed. From this document, the customer will be able to understand our teams comprehension of the requirements. This document can be updated or revised when required by the customer as we consider our customers demands important for our project. This document will evolve according to the requirement.
1.2
Scope
HMC Point of Interest (POI) Inspection & Management System (HPIMS) will handle the original POI data provided by HMC. The original data shall be handled so that the errors such as duplication, logical inconsistency, etc., will be detected and corrected according to the rules. The system allows rules to be defined. The output of 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. In addition to the database file output, the system will report the status of the inspection and modifications present. The system does not convert the POI data to its compressed form.
1.3
Definitions, acronyms, and abbreviations

Definition This is the data that will be used as location information
1.3.1 Definition
Term Point Interest of
1.3.2 Acronym
CMU DB CVS CSV GUI HMC HPIMS MDB ICU POI SOW SPMP SRS Carnegie Mellon University Database Concurrent Versions System 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. Graphical User Interface Hyundai Motor Company Hyundai Motor Company Point of Interest Inspection & Management System Microsoft Access Database file or its file extension name Information and Communication University Point of Interest Statement of Work Software Project Management Plan Software Requirements Specification
Team name: 4WD
ICU-CMU MSE Studio Project, 2012
Page 1 of 22
Date: 2004
May 2,
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 on what and how we will handle the project. In section 3, the detailed functional and non-functional requirement is described in a way that no ambiguous aspects are left. Section 4 describes the other requirement that is not described in section 3.
Team name: 4WD
Page 2 of 22
Date: 2004
May 2,
2.
2.1
Overall Description
Product Perspective
HMC manages around 2 million POI data every 6 months. It gets the original POI data from third party content provider(s) who in turn get the POI data from the real investigation or telephone data. This collected POI data, is refined by HMC into clean POI data which will be sent to the commercialization process. Commercialization process is a method by which the refined POI data is compressed so that various forms of car navigation information can be developed Raw POI DB Raw POI DB gathering refinement commercialization Collecte d POI DB
real survey telephon e data
POI Inspection POI Cleansing
Data Data Refined POI DB
POI Data Analysis
Figure 2-1: Overall description of POI DB refinement process
such as CD, DVD, etc. To get highly qualified POI data, it is necessary to apply a series of complex functions of data manipulation in the refinement process, such as removing the duplication, finding and removing logical inconsistency, and free editing of data items. Figure 1 shows the overall process of the POI data refinement. POI Inspection & Management System support refinement process from original collected data to refined DB with inspection and cleansing. How we inspect and cleanse the POI data is analyzed for the purpose of checking the quality of the data source. The analysis of 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 Team name: 4WD ICU-CMU MSE Studio Project, 2012 Page 3 of 22
Date: 2004
May 2,
Function and Analysis Function: This program also provides Graphical User Interface (GUI) for the user. The three major functions are as follows - Data Inspection Function: Duplication check, multimedia data file check, and logical inconsistency inspection - Data Cleansing Function: Duplication, logical inconsistency elimination - Data analysis function: Statistical representation of raw POI data, errors found by inspection, numbers, and history of them. In addition to the three main functions, import function from CSV file (*.csv) and export function to CSV file (*.csv) will be provided for the convenience of the user. Rules for POI data inspection and cleansing will be supported in a pluggable way in case there is a possibility to add more enhanced rules for inspection and cleansing in 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 Windows XP with Microsoft Access DB. The system will be developed using platformindependent Java language, so the underlying operating environment can be changed with little cost. Since the target system deals with voluminous data, large size of main memory is necessary: Giga Bytes of Main Memory or more.
2.5 2.6
Design and Implementation Constraints User Documentation
All codes shall be written in Java-family language.
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.
Team name: 4WD
Page 4 of 22
Date: 2004
May 2,
3.
3.1
Specific Requirement
External Interface Requirements
3.1.1 User Interfaces

This user interface is prototype made after discussion among 4wd team. This will help 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 users requirement and technical constraints.
3.1.1.1 User interface architecture

This is the overall architecture of HPIMS prototypical user interface. The user interface 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 system already has. With the combination of the rules, you can have various inspections depending on the criteria of your inspection. The groups of rules are managed through files and they can be changed by adding or deleting rules through the panel below. The description of the rule with the rule description inquiry is shown in figure 3-3.
Team name: 4WD
Page 5 of 22
Date: 2004
May 2,
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 the Rule Group Manager panel, you can inspect the data as Figure 3-4.
Team name: 4WD
Page 6 of 22
Date: 2004
May 2,
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 inspection result will provide detailed information on the error. The history of each inspection report is shown in the inspection history as Figure 3-7.
Team name: 4WD
Page 7 of 22
Date: 2004
May 2,
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 batch operation. 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 Group Management panel. The batch cleansing execution, the result of the execution, and the history of the cleansing operation is shown in Figure 3-8, Figure 3-9, and Figure 3-10.
Team name: 4WD
Page 8 of 22
Date: 2004
May 2,
Figure 3-8 Cleansing Manager - Batch Operation
Figure 3-9 Cleansing Manager - Cleansing Report
Team name: 4WD
Page 9 of 22
Date: 2004
May 2,
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 and the analysis on inspection or cleansing data. The analysis of data itself includes the number of data in each region, the number of the data in each kind, and the combination of those. The history of the updated data is shown to track the trend of update. (Figure 3-11). The analysis of the inspection or cleansing work is also displayed 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 of cleansing results in each region and kind. Also, history of cleansing is tracked.
Figure 3-11 Analysis Manager - Changed Data History
Team name: 4WD
Page 10 of 22
Date: 2004
May 2,
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 Interfaces

N/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 have some 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 user configure 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 as problematic items, and the system shall save the findings for the purpose of using it in the 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 convenient form as a report or can export it to the CSV file so as to open it in MS Excel application.
Team name: 4WD
Page 11 of 22
Date: 2004
May 2,
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 some advanced rules for inspection or cleansing, they can program it into java component with interfaces predefined by the system. Then, the system can load the newly added rules from the predefined location in the file system.
However, the system does not support dynamic building of rule in combination with existing rules or scripting of elementary operations. In addition, the system does not support dynamic load or unload of new rules: it needs to restart in order to load or to unload rules.
3.2.1.3.2 The system shall provide a user interface to let the user select the rules among 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 with erroneous data detected but unable to cleanse automatically. 3.2.1.3.4 The result of inspection shall be analyzed in terms of data characteristics 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 Stimulus/Response Sequences 3.2.2.2.1 The input is the POI data and the defined rules. The system shall let a user open POI DB file and select the rules for cleansing. The data items that match the selected rules shall be corrected based on those rules. 3.2.2.2.2 Data cleansing shall be executed after the data inspection or be executed independently. 3.2.2.2.3 DB file. The system shall store the result of data cleansing in another Access
The result of data cleansing can be exported to the CSV file with some important columns encrypted.
3.2.2.3 Associated functional requirement 3.2.2.3.1 After data cleansing function, the related information of changed data shall 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 the statistical results. The result of inspection and cleansing shall be stored and managed so that the trend of error and change is clearly shown. The user would like 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 Team name: 4WD ICU-CMU MSE Studio Project, 2012 Page 12 of 22
Date: 2004
May 2,
are. Also, the user wants to know history and statistical information of changed data. The changed history can give some insight about what kind of data should be managed as core POI data that is important and doesnt change much.
3.2.3.2 Stimulus/Response Sequences 3.2.3.2.1 The input is the POI data. The system shall enable a user to view the number of current POI data in each region or in each kind. This shows the status of the 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 see the number of the errors found during inspection in each region or in each kind. The change 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 graph which 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. The rules can get input data, such as column names for checking duplication inspection rule shown in Appendix B, inspection rules, to result in inspection result data and report. For the rules, the system provides function to set the input data, select rules to be applied, and manage the rules in categorized groups. The system can also provide function to load or discard specific rules to and from the system itself, so that the rules can be implemented and added continuously whenever new the needs 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 and from the system as well as grouping it into a rule group. 3.2.4.2.2 later use. The System shall let the user store the configuration of the rules for
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 and provides the user chance to use it.
3.2.4.3 Associated functional requirement 3.2.4.3.1 Rule group management
Loaded rules are to be categorized into some groups, so that they can be referred by dealing with groups. Group does not form a hierarchy: a group can only have rules as its children.
3.2.4.3.2
Rule component management
System provides function to load new rules and discard existing ones for the sake of users selection.
3.2.4.3.3 The system shall provide the programmer interface so that the user can add the rules into the predefined rule set.
Team name: 4WD ICU-CMU MSE Studio Project, 2012 Page 13 of 22
Date: 2004
May 2,
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 User Analyze
Configure Rule
Figure 3-13 Use Case diagram of HPIMS
User Case ID
UC01 UC02 UC03 UC04
Primary Actor
User User User User
Use Cases
Inspect POI Data Cleanse POI Data Analyze Configure Rule
Use Case ID: Use Case Name: Created By: Date Created:
UC01 Inspect POI Data JG Park Dec. 2, 2004 Last Updated By: Date Last Updated: JG Park Dec. 2, 2004
Actors: Description:
User The user find the defective data from the *.mdb file which has the POI information ICU-CMU MSE Studio Project, 2012 Page 14 of 22
Team name: 4WD
HMC POI Inspection & Management System Development Software Requirement Specification Preconditions: Postconditions: Normal Flow:
Date: 2004
May 2,
1. The User has the access file to inspect. 1. All the duplication and logical inconsistent data are found from original POI access database. 1. The use chooses inspection menu item. 2. The user opens the access file that he wants to inspect. 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 inspection function after some time. 6. The user sees the result and use Analyze the inspected data use case. 3a The values are within tolerance range. 3a1 Do nothing.
Alternative Flows: Exceptions: Includes: Priority: Frequency of Use: Business Rules: Special Requirements: Assumptions: Notes and Issues: Use Case ID: Use Case Name: Created By: Date Created:
High
UC02 Cleanse POI data JG Park Dec. 2, 2004 Last Updated By: Date Last Updated: JG Park Dec. 2, 2004
Actors: Description: Preconditions: Post conditions: Normal Flow:
Alternative Flows:
User The user cleanses the output data from inspection with the cleansing rule or in a manual manner. 1. The user have already inspected original access file. 1. The user applied the correction process with the cleansing rule or with the manual correction and as a result cleanses the original POI data. 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 rules you defined for cleansing. 4. The user activate cleanse button. 5. The user can use Analyze use case with the cleansing history. 4a. When no inspection was done about chosen access file, warning message is shown. 5a. When no cleansing was done, warning message is shown.
Exceptions: Includes: Priority: Frequency of Use: Business Rules: Team name: 4WD
High
Page 15 of 22
HMC POI Inspection & Management System Development Software Requirement Specification Special Requirements: Assumptions: Notes and Issues:
Date: 2004
May 2,
Use Case ID: Use Case Name: Created By: Date Created:
UC03 Analyze JG Park Dec. 5, 2004 Last Updated By: Date Last Updated: JG Park Dec. 5, 2004
Actors: Description: Preconditions:
Post conditions: Normal Flow: Alternative Flows: Exceptions: Includes: Priority: Frequency of Use: Business Rules: Special Requirements: Assumptions: Notes and Issues: Use Case ID: Use Case Name: Created By: Date Created:
User The user analyzes the data itself or inspection result. 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 when the user wants to cleanse the data. 1. The user gets the information about the data or inspected data. 1. The user chooses analysis menu. 2. The user chooses the information he wants to have 3. The user activates analyze button 2a. The user can choose inspection analysis 2b. The user can choose cleansing analysis. 2c. The user can choose data analysis. 2a. The user didnt inspect the data yet. 2b, The user didnt cleanse the date yet. High
UC04 Configure Rule JG Park Dec. 5, 2004 Last Updated By: Date Last Updated: JG Park Dec. 5, 2004
Actors: Description: Preconditions: Post conditions: Normal Flow:
User The user defines the rule by which to inspect or cleanse. 1. No precondition is O.K. Sometimes in the inspection or cleansing process, you can edit the rule you want. 1. The rule was defined so that this rule can be added to the rule set. 1. The user chooses Rule menu. 2. The user defines the rule with options combined together. 3. The defined rule is named for future use. ICU-CMU MSE Studio Project, 2012 Page 16 of 22
Team name: 4WD
HMC POI Inspection & Management System Development Software Requirement Specification Alternative Flows: Exceptions: Includes: Priority: Frequency of Use: Business Rules: Special Requirements: Assumptions: Notes and Issues:
Date: 2004
May 2,
High
3.2.5.2 Conceptual Architecture

Following Figure 3-2 shows the conceptual architecture and the flow of information of the whole system.
Figure 3-15 Conceptual architecture of system feature The contents provider creates some of POI data. Another POI data are come from yellow book. From this raw data, integrating and cleansing works are performed to enhance correctness and add value. The POI DB is provided to HMC, and then POI Inspection & Management System performs the inspection and some cleansing works. The POI Inspection & Managements System are consisting of POI DB for data management, Memory DB for fast transaction management, and application components and user interfaces for business logic management by the inspection officer. After inspection, the POI DB passed to POI Master DB for product ionization to the Team name: 4WD ICU-CMU MSE Studio Project, 2012 Page 17 of 22
Date: 2004
May 2,
media like DVD, CD, and Hard Disk. Finally, the end customer uses the POI Data at the navigation system.
3.2.5.3 Data Model

Following Data Model shows the existing data schema. Most of entities are connected to POI_I_COMMON entity, POI Common Information
Figure 3-16 Data object model of the system 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 has limited information. The enhanced DB schema will be designed during design phase. Following table shows above schema name and description. No Schema Name Schema Description 1 POI_I_COMMON POI General Information Table 2 POI_I_TF_VERSION POI DB Version Control Table 3 POI_I_PIC_INFO Photo Information Table 4 POI_I_TYPEA Open Time Information Table 5 POI_I_TYPEC Reservation Information Table 6 POI_I_TYPED Tour Course Information Table 7 POI_I_TYPEF Facility Information Table 8 POI_I_TYPEG Sales Products Information Table 9 POI_I_TYPEH Hotel Information Table 10 POI_I_TYPEM Membership Information Table Team name: 4WD ICU-CMU MSE Studio Project, 2012 Page 18 of 22
HMC POI Inspection & Management System Development Software Requirement Specification 11 12 13 14 15 16 17 18 19 POI_I_TYPEP POI_I_TYPEU POI_I_DGUIDE POI_I_GOLF POI_I_HOSPITAL POI_I_TYPEHOSPITAL POI_I_SKI1 POI_C_CLASS POI_C_ZIP
Date: 2004
May 2,
Parking Information Table Credit Card Information Table Drive Course Information Table Golf Course Information Table Hospital Information Table Hospital Subject Information Table Ski Course Information Table KIWI Classification Code Table 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 completely in 10 seconds except for a batch job. The cleansing module does not need to execute completely 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 the integrity. 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 the output 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 server environment 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 summary etc. but shall not change the original POI data.
Team name: 4WD
Page 19 of 22
Date: 2004
May 2,
Appendix A: Rule Definition
Team name: 4WD
Page 20 of 22
Date: 2004
May 2,
Appendix B: Requirement Tracking Sheet
Team name: 4WD
Page 21 of 22

HPIMS - SRS v1.03

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HPIMS - SRS v1.03

Uploaded by

Copyright:

Available Formats

Software Requirements Specification For HMC POI Inspection & Management System

Definitions, acronyms, and abbreviations

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

real survey telephon e data

POI Inspection POI Cleansing

Data Data Refined POI DB

POI Data Analysis

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

User Classes and Characteristics

Design and Implementation Constraints User Documentation

All codes shall be written in Java-family language.

Assumptions and Dependencies

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

3.1.1 User Interfaces

3.1.1.1 User interface architecture

Figure 3-1 User interface architecture

3.1.1.2 Rule Group Manager

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

Figure 3-2 Rule Group Manager - Selection

Figure 3-3 Rule Group Manager - Rule Inquiry

3.1.1.3 Inspection Manager

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

Figure 3-6 Inspection Manager - Detail Inspection Report

Figure 3-7 Inspection Manager - Inspection History

3.1.1.4 Cleansing Manager

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

Figure 3-8 Cleansing Manager - Batch Operation

Figure 3-9 Cleansing Manager - Cleansing Report

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

Figure 3-10 Cleansing Manager - Cleansing History

3.1.1.5 Analysis Manager

Figure 3-11 Analysis Manager - Changed Data History

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

Figure 3-12 Analysis Manager - Inspection and Cleansing Analysis

3.1.2 Hardware Interfaces

3.1.3 Software Interfaces

3.1.4 Communications Interfaces

3.2.1 Data Inspection

Team name: 4WD

ICU-CMU MSE Studio Project, 2012

3.2.2 Data Cleansing

3.2.3 Data Analysis

3.2.4 Rule Configuration function

3.2.4.3 Associated functional requirement 3.2.4.3.1 Rule group management

Rule component management

3.2.4.4 Rule Definition Sheet

3.2.5 Use case and Domain Object Model

Inspect POI Data

Cleanse POI Data User Analyze

Figure 3-13 Use Case diagram of HPIMS

Team name: 4WD

Actors: Description: Preconditions: Post conditions: Normal Flow: