Difference between revisions of "Template Page"

From Scube-casestudies
Jump to: navigation, search
(Domain Assumptions)
Line 47: Line 47:
  
 
== Scenarios==
 
== Scenarios==
 +
ALERT scenarios
  
the list of the scenarios
 
 
 
{| style="background:#cccc99;color:black;width:80%;" border="1" cellpadding="5" cellspacing="0" align="center"
 
|+ Table S1: Scenario ID
 
!Field !! Description
 
  
 +
{| cellspacing="0" cellpadding="5" border="1" align="center" style="background:#cccc99;color:black;width:80%;"
 +
|+ Table S1: Scenario ALERT-S1.1
 +
|-
 +
! Field
 +
! Description
 
|- style="background:#f0f0f0; color:black"
 
|- style="background:#f0f0f0; color:black"
! UniqueID
+
! UniqueID  
| |ID
+
| ALERT-S1.1
 
+
|- style="background:white; color:black"
 +
! Short Name
 +
| Detect possible duplicate issues at creation<br>
 +
|- style="background:white; color:black"
 +
! Brief Description
 +
| The Customer (or developer) enters and describes an issue<br>
 +
|- style="background:white; color:black"
 +
! Related To
 +
| ALERT-BG1<br>
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
! Short Name
+
! Involved Actors
|  
+
| Customer<br>
 
 
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
! Related To
+
! Detailed Operational Description
|  
+
| The Customer enters an issue. If a potential duplicate is spotted, he is asked to check it. A gatekeeper is notified of the new issue.<br>
 
 
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
! Involved Actors
+
! Problems and Challenges
|  
+
| Notify the Customer on time, so he can validate it's a duplicate.<br>Good quality detection.<br>
 
 
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
! Detailed Operational Description
+
! Business Trigger
|  
+
| Customer encounters an issue, and reports it. <br>
 
 
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
! Problems and Challenges
+
! Preconditions
|  
+
| An issue tracking system is installed, and ALERT is configured to retrieve information from it. <br>
 
 
 
|- style="background:white; color:black"
 
|- style="background:white; color:black"
! Additional Material
+
! Priority
|  
+
| Should have <br>
 
 
 
 
 
|}
 
|}

Revision as of 16:30, 6 June 2011

Description

Case study Description

Business Goals and Domain Assumptions

Business Goals and the Domain Assumptions for the current case study.

Business Goals

Table BG1. Business Goal ALERT-BG1
Field Description
UniqueID ALERT-BG1
Short Name Enable efficient duplicates identification
Type Business Goals.
Description Help developers and gatekeepers to manage issues. Developers should not work on duplicates, but instead access all duplicated issue entries to get more description on the issue. Gatekeepers should be notified of possible duplicates. Customers should be notified when their entry is a possible duplicate.
Rationale Developers loose time with duplicates. Duplicate entries should instead help to get more complete information.
Involved Stakeholders Customer, Gatekeeper
Conflicts Poor detection could ruin the process.
Priority of accomplishment Should have

Domain Analysis

Strategic Dependency Model and Context Diagram

Domain Model

Scenarios

ALERT scenarios


Table S1: Scenario ALERT-S1.1
Field Description
UniqueID ALERT-S1.1
Short Name Detect possible duplicate issues at creation
Brief Description The Customer (or developer) enters and describes an issue
Related To ALERT-BG1
Involved Actors Customer
Detailed Operational Description The Customer enters an issue. If a potential duplicate is spotted, he is asked to check it. A gatekeeper is notified of the new issue.
Problems and Challenges Notify the Customer on time, so he can validate it's a duplicate.
Good quality detection.
Business Trigger Customer encounters an issue, and reports it.
Preconditions An issue tracking system is installed, and ALERT is configured to retrieve information from it.
Priority Should have