Use-Story Specification: <A Bug's Life>
1. Brief Description
[The description briefly conveys the role and purpose of the use case. A single paragraph will suffice for this description.]
2. Basic Flow of Events
Software user finds bugs of that software. He wants vendor to fix these bugs, so he tells description and sends several snapshots about these bugs to vendor’s customer service (CS). He also tells that some of these bugs must be fixed at once; some are not so urgent, as well as some are just his suggestions which are just nice to have. At last, He asks CS to notify him by email when the bugs are fixed.
CS records when user tells these bugs, code each of these bugs, and then reports these bugs to project manager of that software in papers one by one. CS receives bugs from quite a lot different software, so he also categorizes these bugs under corresponding software name.
Software development team manager, who is also called project manager (PM), is notified about these bugs by email. For these critical bugs, PM wants to be notified once CS records them. However, for some case, company needs CS to confirm it’s really bug at first before he sends notification. After CS proves they’re truly bugs, he sends these bugs by email in a daily base. Meanwhile, it’s decided by PM whether to be notified at once or not. If it’s not bug, CS should reply to user at once, tell user why it’s not a bug. PM also needs Business Analyst (BA) to be notified at the same time he receives bug notification. After PM receives notification, he will discuss with BA about these bugs: if they are truly bugs; is it so critical to be fixed in current software version, if not, when will this bug be fixed? Especially, if it’s just a suggestion, should it be fixed now? Who will be responsible to fix bug? When will this bug be fixed? After making decision about all bugs, plus fixed bug status, PM sends a summary to CS, which is based on last day’s bug report, CS will tell status of these bugs to user. User can only get his own bug daily report. Every year, a bug statistic will be generated, through this report, the user who 1, reports the most quantity of bugs, 2, reports the most quantity of critical bugs will be invited to travel, or some activity else to improve relationship between company and customer.
2005-03-24 Found Bugs | ||||
No | Description | Status | Estimate Fixed Time | Remarks |
AU101 |
| Fixed |
|
|
AU102 |
| Undertaking | 2005-03-26 |
|
AU103 |
| Rejected |
|
|
AU106 |
| Delayed |
|
|
| ||||
Other Fixed, Delayed & Rejected Bugs | ||||
No | Description | Status | Remarks | |
AU066 |
| Fixed |
| |
AU098 |
| Delayed |
| |
AU099 |
| Rejected |
|
Figure: Daily Bug Report
Annual Bug Statistic | |||||
User | Total | Critical | Medium | Low | Suggestion |
Jorge Bush | 100 | 10 | 20 | 30 | 50 |
Bill Gates | 80 | 30 | 20 | 10 | 20 |
Hillary Clinton | 75 | 20 | 20 | 20 | 15 |
Yao Ming | 50 | 16 | 26 | 8 | 0 |
Michel Jordan | 40 | 10 | 10 | 10 | 10 |
Kobe Brian | 10 | 1 | 2 | 3 | 4 |
Figure: Annual Bug Statistic
PM has his project bug report. CS has report of bug he recorded, including various software. User has report of bug he tells, including various software. They have different view on whole bugs.
Developer gets notified by email per bug once PM proves that bug should be fixed and assigns that bug to that developer. Receiving that notification, developer estimates how long it will take to fix, then tells PM estimate time. Then he begins to fix that bug. Some time past, developer fixes that bug, he notifies PM that bug has been fixed, what reason causes this bug, and when he fixes the bug. PM then notifies Tester to test if that bug is really fixed.
Tester gets one version of software then begins to test on claimed fixed bugs. If one bug is fixed, tester will tell on which version the bug is fixed. For those bugs which fail to pass testing, tester will notify them to PM and tell him on which version that bug still exists.
If one version of software has pretty low amount of bugs, PM decides to release that version. He asks tester to get all claimed tested bugs to do recursive testing, if pass, PM release that version of software, CS tell user that a new version of that software is released, what bugs he submitted are fixed, what bugs of all are fixed. If it fails to pass recursive testing, PM asks developers to fix them until all of those claimed tested bugs are fixed to that version.
At the end of year, PM needs a statistic on how many bugs everyone makes. Each developer will be awarded or punished based on this statistic.
Annual Bug Statistic | |||||
Developer | Total | Critical | Medium | Low | Suggestion |
Grady Booch | 100 | 10 | 20 | 30 | 50 |
Bill Gates | 80 | 30 | 20 | 10 | 20 |
Bruce Eckel | 75 | 20 | 20 | 20 | 15 |
Kent Beck | 50 | 16 | 26 | 8 | 0 |
Ivonkon | 40 | 10 | 10 | 10 | 10 |
Linus | 10 | 1 | 2 | 3 | 4 |
Figure: Annual Bug Statistic
Developer also wants to submit bugs found by himself, he don’t want to wait, wait and wait for PM’s confirmation. And after fixed, he also doesn’t need to be tested by tester, he just wants to mark that bug as tested himself.
Sometime, developer finds bugs belonging to other developers; he notifies these bugs to them. But he shouldn’t fix these bugs, instead, only bug owner may fix them. And other developers don’t like that tester knows about these bugs.
The end.