5.2.3 UC-03 Cleansing Data From OLTP: Description

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 9

5.2.

3 UC-03 Cleansing Data from OLTP


Description
The data will be cleansed using specified standards and techniques.
Level: User goal.
Primary Actor
Performance analysis Assistant.
Supporting Actors
DWH Administrator.
Stakeholders and Interests
Performance analysis Assistant will require this information for analysis and reporting.
Pre-Conditions
Transformation is completed.
Post Conditions
Success end condition
The data is cleansed on certain standards and performance indicators are recorded.
Failure end condition:
The data is not cleansed and the performance indicator table is empty.
Minimal Guarantee
Null.
Trigger
The cleansing will start whenever specified numbers of records are transformed.
Main Success Scenario

1. The cleansing starts.


2. The data is successfully cleansed.
3. Performance indicators are recorded in table.
Frequency
Daily.
Assumptions
The data is already transformed and the tables are loaded on which the data will be stored.
Special Requirements
Performance
The cleansing effects the performance of the overall system as it takes too much space for tables.
User Interface
There will be button on desktop apps dashboard for initialization of cleansing.
Issues
They data will not be available for loading even after transformation until the data is completely
transformed.
To do
Store the table with performance indicator to use for reporting.

5.2.8 UC-08 Generate BI Reports


Description
Reports will be generated depending upon the requirement of user these reports will use data from
MOLAP.
Level
High level.

Primary Actor
Business Analyst.
Supporting Actors
DWH Assistant.
Stakeholders and Interests
Null.
Pre-Conditions
The Business analyst must be logged in to system.
Post Conditions
Success end condition
The report is displayed to the Business analyst.
Failure end condition
List failure end condition here.
Minimal Guarantee
Null.
Trigger
Business analyst requests for report.
Main Success Scenario
1. Business Analyst requests for report.
2. Report is generated.
1. Report is presented to Analyst.
Extensions
Null.

Variations
Null.
Frequency
Weekly.
Assumptions
Null.

5.2.6 UC-06 Data accessed by business analyst


Description
The data will be accessed by the business analyst for analysis and data retrieval.
Level: User goal.
Primary Actor
Business analyst.
Supporting Actors
DWH Admin.
Stakeholders and Interests
Null.
Pre-Conditions
The data is present in the DWH.
Post Conditions
Success end condition
The data is accessed and displayed to the desired person or process.

Failure end condition


The data is not accessed and nothing is displayed.
Minimal Guarantee
The data will be unaffected.
Trigger
Null.
Main Success Scenario
1. Data is requested.
1. Data is accessed.
2. Data is displayed.
Extensions
Null.
Variations
Null.
Frequency: Enter Frequency of execution here.
Assumptions
The SQL is used for accessing data.
Special Requirements
Enter any special requirements such as Performance requirements, Security requirements, User interface
requirements, etc.
Performance
The data retrieval needs to be fast.
User Interface

The User Interface will be used to display data.


Issues
The table can return excessive number of records.
To do
Record the time it took to retrieve and execute query.

5.2.7 UC-07 Data backup


Description
The data will be duplicated to make a backup for the data in case the data is lost.
Level
Low Level.
Primary Actor
DWH Admin.
Supporting Actors
Null.
Stakeholders and Interests
Null.
Pre-Conditions
The data is present.
Post Conditions
Success end condition
Separate repository is made for backup.

Failure end condition


The backup repository is empty.
Minimal Guarantee
The data remains unchanged.
Trigger
After each month the backup will be made.
Main Success Scenario
1. Data is selected for backup.
2. Data is duplicated.
3. Backup is made.
Extensions
Null.
Variations
Null.
Frequency
Monthly.
Assumptions
Null.

5.2.5 UC-05 Refreshing Data in DWH


Description
The data will be required to be integrated with prior data present in DWH repository every time data is
changed.

Level
User goal.
Primary Actor
DWH Administrator.
Supporting Actors
Null.
Stakeholders and Interests
Null.
Pre-Conditions
The data is loaded.
Post Conditions
Success end condition
The data is refreshed and integrated with previous data.
Failure end condition:
The changes are not made in data.
Minimal Guarantee
The data will not be lost and will be integrated again.
Trigger
The data refresh is initiated when the data is update.
Main Success Scenario
1. Changes are made.
2. Data is refreshed.
3. The data is integrated with prior available data.

Frequency
Daily.
Assumptions
Null.
Special Requirements
Performance
The integration phase should complete in specified time.
User Interface
There will be no specific User Interface for the data refresh phase.
Issues
It takes too much time to check old data.
To do
Null.

You might also like