Difference between revisions of "Template Page"
From Scube-casestudies
(→Domain Assumptions) |
|||
Line 47: | Line 47: | ||
== Scenarios== | == Scenarios== | ||
+ | ALERT scenarios | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | {| 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 |
− | | | | + | | 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" | ||
− | ! | + | ! Involved Actors |
− | | | + | | Customer<br> |
− | |||
|- style="background:white; color:black" | |- style="background:white; color:black" | ||
− | ! | + | ! 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" | ||
− | ! | + | ! 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" | ||
− | ! | + | ! Business Trigger |
− | | | + | | Customer encounters an issue, and reports it. <br> |
− | |||
|- style="background:white; color:black" | |- style="background:white; color:black" | ||
− | ! | + | ! 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" | ||
− | ! | + | ! Priority |
− | | | + | | Should have <br> |
− | |||
− | |||
|} | |} |
Revision as of 16:30, 6 June 2011
Contents
Description
Case study Description
Business Goals and Domain Assumptions
Business Goals and the Domain Assumptions for the current case study.
Business Goals
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
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 |