IS1024 Project Team 7
| Вид материала | Документы |
- Point Team Services, входящий в состав ms project Server. Основные термины задача, 197.38kb.
- Project Expert 0, 587.79kb.
- Fast Street Team» Зимний Кубок клуба Fast Street Team по ралли-спринту «fst winter, 157.07kb.
- Microsoft Project Server. Microsoft Project Web Access Web-интерфейс для отчет, 98.46kb.
- Член Project Management Institute (pmi). Certified Senior Project Manager (cpm) Сертифицированный, 27.46kb.
- Software Project Management ) (базовый) по направлению: 511600 факультеты: фупм кафедра:, 41.85kb.
- Microsoft Project Portfolio Server Пример внедрения: решение, 374.46kb.
- Microsoft Office Project 2007-2010 программа, 121.65kb.
- Одним из лидирующих инструментов планирования бизнеса в условиях рынка, разработки, 42.42kb.
- Великий Новгород, ул. Псковская,, 12.23kb.
11. System Requirements
The hosting server will be a Windows based or Unix operating system with at least 4 GB of memory and each PC that interfaces with the sever must have at least 1 GB of memory in order to run the necessary queries. The hosting server will have at least 2 TB or storage with bays available to expand as needed.
12. Licensing, Security, and Installation
An Oracle or Microsoft licenses will be needed for the server. Microsoft licenses will be needed for the interfacing computers. Norton Antivirus software licenses will be needed for all computers in the network. Only authorized employees of Beverage Inc. will be allowed to access the system and updates will handled by the maintenance staff.
[Bryan DeFranco]
- Technical Specification
13.1 Data and Technology Variations
13.1.1 Data Chunk
A data chunk is a sufficient amount of data to perform batch validation, transformation, and storage in data warehouse for a DB-unit of information. This typically will be less than 12 records, or 100K Bytes per chunk, but each chunk will vary is size.
A DB-unit of information is that which sufficient to create a meaningful storage in Data Warehouse informational format. This is bound by the external rules file.
13.1.2 Extraction, Transformation and Validation Rules
Data extraction rules are specified outside of BevDOT, and define the data to retrieve. The rules file will also define table formats of Legacy system to facilitate ability to reconfigure if Legacy database structure changes in the future.
BevDOT
Legacy System
Validate
Transform
1. Introduction
Purpose
The purpose of this section was to prioritize the features and the use cases for the BevDot System and then identify the use cases for the first iteration. The prioritization of the use cases is related to the needs as specified in section two.
- 4.1 Prioritize Use Cases
- Features Table, Prioritized
| ID | Feature | Effort | Risk | Comment |
| 1 | Extract Data | Med | High | Download data |
| 2 | Auto validate data | Med | High | Auto validation |
| 3 | Manually validate data | Med | High | Manual validation |
| 4 | Transform data to BevDOT | High | High | Transform data |
| 5 | Load data | Med | High | Load validated data |
| 6 | Error handling | High | High | Handle critical errors |
| 7 | Generate reports(high level) | Med | Med | High level reports |
| 8 | Generate ad-hoc reports | Med | Med | Ad-Hoc reports |
| 9 | Generate sales forecasting reports | Med | Med | Sales forecasting reports |
| 10 | Generate regional revenue reports | Med | Med | Regional revenue reports |
| 11 | Generate tracking reports | Med | Med | Tracking reports |
| 12 | Generate seasonal sales reports | Med | Med | Seasonal sales reports |
| 13 | Create system efficiency reports | Med | Low | System efficiency reports for IT |
| 14 | Create graphical representations of data | Med | Low | Make graphs based on report data |
- Use Cases, Prioritized
The use cases have been derived from the features as shown above and put in order of importance from highest to lowest.
- ETL Use Case (Extract, Transform, Load)
- Automatic Validation
- Manual Validation
- Error Handling
- Generate Reports
- Generate Ad-Hoc Reports
- Create Graphs
- Section 4.2 Identify Use Cases for Initial Iteration
After discussing the necessary use cases for the successful operation of the system, the use cases have been narrowed down to six for the initial iteration of BevDOT. They are as follows:
- ETL Use Case
- Automatic Validation
- Manual Validation
- Error Handling
- Generate Reports
- Generate Ad-Hoc Reports
These six (6) use cases will fulfill the needs of the company in the initial iteration. Graphical representations of data from user-generated reports as well as additional reports will be added in future iterations.
| | | | |
| | | | |
1. Introduction
Purpose
The purpose of this section is to further refine the system by finalizing preliminary use cases into fully dressed use cases. This section is to also refine the initial supplementary specification into the Final Supplementary Specification for the BevDOT data Warehouse.
5.1a (creator: Bryan Defranco)
Use Case #1.0
Use Case Name: Extract Data
Description: Initiates the ETL process for transferring data from the operational format legacy system to the informational format BevDOT data warehouse.
Scope: BevDOT System
Level: Batch Process
Primary Actor: Legacy System
Stakeholders and Interests: IT Department, DBA
Preconditions: BevDOT system has loaded the data acquisition and extraction rules from external file.
Success Guarantee (Postcondition): Required data is retrieved from Legacy System and passed to Validate Data1
Main Scenario (Basic Flow):
- BevDOT system connects to Legacy System using ODBC over TCP/IP
- Legacy System authenticates BevDOT system
3. BevDOT system generates SQL statements based on loaded rules, and the date the last extraction was performed.
4. BevDOT System submits query to Legacy System
5. Legacy system begins return of requested data
6. BevDOT System performs ValidateData1
7. BevDOT System checks if more data is available from Legacy system
8. BevDOT System disconnects from Legacy system
Extensions:
7a. Upon additional data available
- BevDOT restarts process at step 4.
7b. Upon no additional data available
- BevDOT resumes process at step 8
*a. Upon detection of system failure
1. BevDOT System performs Error Handling
Special Requirements: None
Technology and Data Variations: Data extraction rules are specified outside of BevDOT, and define the data to retrieve. The rules file will also define table formats of Legacy system to facilitate ability to reconfigure if Legacy database structure changes in the future.
Frequency of Occurrence: Weekly
5.1b (creator: Bryan Defranco)
Use Case #2.0
Use Case Name: Validate Data
Description: Ensures data integrity. Routes bad data to be held in temporary tables for Manual Validation
Scope: BevDOT System
Level: Sub Function
Primary Actor: Legacy System
Stakeholders and Interests: IT Department, DBA
Preconditions:
1. BevDOT System is authenticated with Legacy System
2. A data chunk has been extracted.
3. Validation rules have been loaded from external file.
Success Guarantee (Postcondition): Required data chunk is validated and passed to Transform Data
Main Scenario (Basic Flow):
- BevDOT System applies rules from external configuration.
- BevDOT System performs Transform Data
Extensions:
1a. Upon failure of validation algorithm
- BevDOT System saves the questionable data in temporary storage for manual review
*a. Upon detection of system failure
1. BevDOT System performs Error Handling
- Return error code to Extract Data
Special Requirements:
Validation rules will contain checks for null values, dates out of range, orphaned records, and any other items the DBA requires for successful transformation. This external configuration can be changed as needed.
Technology and Data Variations:
A data chunk is a sufficient amount of data to perform batch validation, transformation, and storage in data warehouse.
Frequency of Occurrence: As needed by parent process
5.1c (creator: Bryan Defranco)
Use Case #3.0
Use Case Name: Manual Validate Data
Description: DBA Corrects data anomalies received from Legacy Database
Scope: BevDOT System
Level: User Goal
Primary Actor: DBA
Stakeholders and Interests: IT Department, DBA
Preconditions:
- User is logged on to BevDBW system, and has entered Manual Validation screen
- Validation rules are loaded from external file
Success Guarantee (Postcondition): Data is successfully corrected and passed to Transform Data
Main Scenario (Basic Flow):
- BevDOT System displays questionable data from temporary storage
- User corrects data abnormalities
- BevDOT System validates data using validation rules
- BevDOT System performs Transform Data
Extensions:
3a. Upon failure of validation algorithm
1. BevDOT System displays data that did not pass validation
- BevDOT System resumes at step 1
*a. Upon detection of system failure
1. BevDOT System performs Error Handling
Technology and Data Variations: None
Special Requirements:
Validation rules will contain checks for null values, dates out of range, orphaned records, and any other items the DBA requires for successful transformation. This external configuration can be changed as needed.
5.1d (creator: Bryan Defranco)
Use Case #4.0
Use Case Name: Transform Data
Description: Data is cleansed and transformed from an operational format, into an informational format consistent with BevDOT data warehouse
Scope: BevDOT System
Level: Sub Function
Primary Actor: Legacy System
Stakeholders and Interests: IT Department, DBA
Preconditions:
- BevDOT System is authenticated with Legacy System
- A data chunk has been Extracted and Validated.
- Transformation Rules have been loaded from external file.
Success Guarantee (Postcondition): Required data chunk is cleansed and transformed and passed to Load Data
Main Scenario (Basic Flow):
- BevDOT System applies transformation algorithm to data.
- BevDOT System performs Load Data
Extensions:
*a. Upon detection of system failure:
- System displays error code
- System Performs Error Handling
- Return error code to Validate Data
Special Requirements: None
Technology and Data Variations:
A data chunk is a sufficient amount of data to perform batch validation, transformation, and storage in data warehouse.
Transformation algorithm is based on loaded rules defined external to the BevDOT system. These rules may be changed for future needs.
Frequency of Occurrence: As needed by parent process
5.1e (creator: Bryan Defranco)
Use Case #5.0
Use Case Name: Load Data
Description: Data is loaded into tables in the BevDOT data warehouse in a manner consistent with existing information data format
Scope: BevDOT System
Level: Sub Function
Primary Actor: Legacy System
Stakeholders and Interests: IT Department, DBA
Preconditions:
1. BevDOT System is authenticated with Legacy System
2. A data chunk has been Extracted, Validated, and Transformed.
3. BevDOT system has loaded the configuration rules from external file.
Success Guarantee (Postcondition): Required data is stored in data warehouse tables
Main Scenario (Basic Flow):
- BevDOT System generates SQL statements based on configuration file
- BevDOT System initiates transaction
- BevDOT System writes data to data warehouse tables using SQL
- BevDOT System commits changes
Extensions:
*a. Upon detection of system failure:
- System displays error code
- System Performs Error Handling
Special Requirements: None
Technology and Data Variations: Data Loading rules are specified outside of BevDOT. The rules file will define table formats of BevDOT system to facilitate ability to reconfigure if BevDOT database structure changes in the future.
Frequency of Occurrence: As needed by parent process
5.1f (creator: Mark Wimer)
Use Case #6.0
Use Case Name: Error Handling
Description: Error Handling use case will perform the appropriate actions if an abnormal error occurs within the system’s scope of performance.
Scope: BevDOT
Level: System Goal
Primary Actor: Database Administrator, System Administrator
Stakeholders and Interests: Senior Management, IT Department
Preconditions:
- BevDOT is performing a system function
- System error occurs
Success Guarantee (Postcondition):
- BevDOT successfully receives, codes, and logs system errors for later retrieval.
Main Scenario (Basic Flow):
- Legacy system sends handshake request to BevDOT
- BevDOT connects to Legacy System
- Legacy system sends error report(s) to BevDOT
- BevDOT disconnects from Legacy System
- BevDOT assigns incremental error code to each error report
- BevDOT logs errors in a flat file
Extensions (Alternative Flows):
6a. Export Error log
- User opens log file
- BevDOT displays all errors
- User chooses, ‘Export Data’ from file options
- BevDOT presents user with file extensions for exporting
- User selects file extensions and chooses, “Export”
- BevDOT creates export file.
6b. Delete Error Log
- User opens log file
- BevDOT displays all errors
- User chooses specific or all error logs
- User selects, ‘Delete’
- BevDOT displays warning prompt, “Are you sure?”
- User confirms ‘Delete’
- BevDOT removes selected error logs
*a. Upon detection of system failure:
- BevDOT halts process
- BevDOT dumps temporary memory to file
- BevDOT terminates process
Special Requirements: Error reports are stored until an IT user clears them from the BevDOT.
Technology and Data Variations: BevDOT retains a small portion of disk space for error logs.
Frequency of Occurrence: Daily or as needed.
5.1g (creator: David Azzolina; contributor(s): Mark Wimer )
Use Case # 7.0
Use Case Name: Generate Reports
Description: Serves as the initial reporting interface for users of the BevDOT system to generate reports based on existing BevDOT data.
Scope: BevDOT
Level: User Goal
Primary Actor: Sales, Marketing, Finance, Shipping, and IT departments.
Stakeholders and Interests: Sales, Marketing, Finance, Shipping, and IT departments – will use this to generate various reports for data contained within BevDOT.
Senior management - will use reports to set and track goals at the company, division, and country level to anticipate trends and changes in the market over time to improve forecasting, and to make executive decisions based on product demand.