IS1024 Project Team 7

Вид материала

Содержание

List of use cases
Scope: BevDOT System Level
Scope: BevDOT Level
Scope: BevDOT System Level
1.3    References
3.1    Operating System Compliance
4.    Reliability
4.2    Mean Time Between Failures
5.2    Database Access Response Time
7. Design Constraints
8. Documentation Requirements
8.2 Online Help
9. Scheduled Maintenance

Подобный материал:

1 2 3 4 5

List of use cases:

UC #1 – Extract Data

UC #2 – Validate Data

UC #3 – Manual Validate Data

UC #4 – Transform Data

UC #5 – Load Data

UC #6 – Error Handling

UC #7 – Generate Reports

UC #8 – Ad Hoc Report

UC #9 – Create Graphs

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

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.

Use Case #2.0

Use Case Name: Validate Data

Description: Ensures data integrity. Routes inconsistent 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

Technology and Data Variations:

A data chunk is a sufficient amount of data to perform batch validation, transformation, and storage in data warehouse.

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.

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.

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

1. System performs Error Handling

Return error code to Validate Data

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.

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

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.

(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

The use case on this page was created by Mark Wimer

(creator: Mark Wimer and Philip Boggs)

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.

Preconditions: User is logged into the system. Database must be established with minimum of one (1) record.

Success Guarantee (Postcondition): A report is generated.

Main Scenario (Basic Flow):

1. System displays operations options on the GUI interface.

2. User chooses the generate report option.

3. System displays a report type variant screen.

4. User selects a report type from the menu.

5. System queries BevDOT for report-specific data.

7. BevDOT returns data to System.

8. System displays data in spreadsheet format.

9. System presents options to print results or export results.

Use Case #8.0

Use Case Name: Generate Ad-Hoc Report

Description: Gives users ability to specify parameters to craft report output.

Scope: BevDOT System

Level: Sub function of Generate Reports

Primary Actor: Sales person, Marketing Agent, Accountant

Stakeholders and Interests: 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.

Preconditions: User is logged into the system. Reports menu is displayed.

Success Guarantee (Postcondition): Report is generated, critiqued to the users’ needs.

Main Scenario (Basic Flow):

User chooses ‘Custom Reporting’ from the menu.
System presents options for the user to choose a saved configuration, or create a new one
User chooses ‘create new’
System presents options screen for the user to select and/or key-in values
User selects desired options and enters needed criteria.
System checks for incomplete or improper specification
System generates query from the users configuration.
System queries data warehouse and displays results
System presents options to print, save, save configuration, generate graph, quit

Extensions (Alternative Flows):

2a. Upon selection to use saved configuration,

System presents user with list of saved configurations
User chooses the desired configuration from the menu
Skip to step 7.

6a. Upon detection of bad spec:

System informs user of the fields improperly or not filled
System resumes at step 4

9a. Upon selection to print

System sends the report to the print spooler.
System presents Reports menu

9b. Upon the selection to save

System writes the query results to an Excel compatible file
System resumes at step 9

9c. Upon selection to save configuration

System prompts for input of a name for the custom configuration
User enters a name for the custom configuration
System saves the query criteria in the database
System resumes at step 9

9d. Upon selection to generate graph

System Performs Generate Graph
System resumes at step 9

9e. Upon selection to quit

1. System presents the Reports menu

*a. Upon detection of system failure:

Present failure message to user.
Generate error message and send to IT dept error logger
Restart main menu, step 1

Special Requirements: None

Technology and Data Variations: None

Frequency of Occurrence: As needed

(creator: Mark Wimer and Bryan Defranco)

Use Case #9.0

Use Case Name: Create Graphs

Description: Gives users ability to create graphs in conjunction with existing BevDOT reports and previously saved ad-hoc reports. Users will use a 3^rd party graphing tool to interpret BevDOT data for graph generation

Scope: BevDOT System

Level: Sub function of Generate Reports

Primary Actor: Sales person, Marketing Agent, Accountant, System Administrator, Database Administrator

Stakeholders and Interests: Sales, Marketing, Finance / Accounting, System Administrators, Database Administrators – will all have access to create graphs

Preconditions:

User is logged into the system.
Reports menu has been accessed and is displayed.

Success Guarantee (Postcondition): Graph is generated based on existing BevDOT reports, or previously saved ad-hoc reports.

Main Scenario (Basic Flow):

1. User chooses the ‘Graph Data’ option.

2. System displays a ‘Graph Type’ selection screen.

3. User selects a graph type from the available options.

4. System presents options to print results, export results, or quit.

[Bryan DeFranco]

Introduction

1.1    Purpose

The purpose of this document is to define requirements of the BevDOT system. This Supplementary Specification lists the requirements that are not readily captured in the use cases of the use-case model. The Supplementary Specifications and the use-case model together capture a complete set of requirements on the system.

1.2    Scope

This Supplementary Specification applies to the BevDOT System which will be developed by the Beverage Company, Inc. IT department. The IT department will develop this client-server system to interface with the existing legacy database system.

BevDOT system will give users needed information previously not redily available. BevDOT system will reduce the load on the existing Legacy system.

This specification defines the non-functional requirements of the system; such as reliability, usability, performance, and supportability as well as …

1.3    References

[References to be added in final supplementary specification]

[Philip Boggs]

Functionality

2.1 System Error Handling

All system errors shall be logged. Non-fatal errors will cause the session to restart at the best previous point. Fatal system errors shall result first in a system halt, then an orderly shutdown of the system.

The system error messages shall include a text description of the error, the operating system error code (if applicable), the module detecting the error, and a date/time stamp. All system errors shall be retained in the Error Log Database.

[Philip Boggs]

3.    Usability

This section lists all of those requirements that relate to, or affect, the usability of the system.

3.1    Operating System Compliance

The desktop user-interface shall be platform independent. The minimum operating system requirements shall be Microsoft Windows XP, Linux kernel 5.1, or Mac OS X 10.3.

3.2    Design for Ease-of-Use

The user interface of the data warehouse shall be designed for ease-of-use and shall be appropriate for a computer-literate user community with a minimal level of training on the System.

[Philip Boggs]

4.    Reliability

This section lists all reliability requirements.

4.1    Availability

The data warehouse shall be available 99% during normal business hours. It will also be available outside of business hours subject to SS item #9

4.2    Mean Time Between Failures

      Mean Time Between Failures shall exceed 500 hours.

[Philip Boggs]

  5.    Performance

The performance characteristics of the system are outlined in this section.

5.1    Simultaneous Users

The system shall support up to 500 simultaneous users against the central database at any given time, and up to 200 simultaneous users against the local servers at any one time.

5.2    Database Access Response Time

The BevDOT system shall respond in a time of no longer than 2 seconds during normal transactional operations.

[Mark Wimer]

6. Supportability

6.1    Software Updates and Maintenance

To provide as much security as possible,. The database itself will not be connected to any external connections except for occasional software updates and maintenance, at which point a system admin will enable such a connection. Any off-site access must be done through a VPN to the legacy system.

[Bryan DeFranco]

7. Design Constraints

7.1 Legacy System

The system shall integrate with the existing legacy database system.

The system shall clean and transform data from an operational format (Create, Read, Update, Delete) into an informational format, and store it in a data warehouse.

Software platform requirements

The system shall use a modern, industry-standard data warehousing scheme. Refer to supplementary specification item #10

[Philip Boggs]

8. Documentation Requirements

This section will outline the documentation that will be included for a successful deployment of the product.

8.1 User Manual

The user manual will provide a purpose, table of contents, and glossary as well as detailed instructions on operating the product and troubleshooting any problems that may be encountered.

8.2 Online Help

The online help section will have a download of the user manual a frequently asked questions page.

8.1 Online Help

Each feature of the data warehouse shall have built-in online help for the user. Online Help shall include step by step instructions on using the System. Online Help shall include definitions for terms and acronyms

[Bryan DeFranco]

9. Scheduled Maintenance

Periodical loading / ETL batch transformations from legacy database will take place during evening/night (non-business hours)

[Section 10,11,12,by Michael Smolenski]

10. Applicable Standards

The Database Warehouse system must run an Oracle based Unix system and compatible with Windows XP or greater. It needs an easy to use GUI interfaces will allow easy to use access to the necessary data. The interface must be compatible with a TCP/IP protocol accessed on a company controlled WAN. Firewalls must be in place to avoid outside users accessing the WAN. The system should also be compatible with Norton Antivirus software.

Blog

IS1024 Project Team 7

Содержание