@@ -19,54 +19,55 @@ use-cases and start to flesh things out.
19
19
20
20
Back to our domain expert:
21
21
22
- So when we've added a reported issue to the issue log, what happens next?
22
+ _ So when we've added a reported issue to the issue log, what happens next?_
23
23
24
- Well we need to triage the problem and decide how urgent it is. Then we might
25
- assign it to a particular engineer, or we might leave it on the queue to be
26
- picked up by anyone.
24
+ > Well we need to triage the problem and decide how urgent it is. Then we might
25
+ > assign it to a particular engineer, or we might leave it on the queue to be
26
+ > picked up by anyone.
27
27
28
- Wait , the queue? I thought you had an issue log, are they the same thing, or is
29
- there a difference?
28
+ _ Wait , the queue? I thought you had an issue log, are they the same thing, or is
29
+ there a difference?_
30
30
31
- Oh, yes. The issue log is just a record of all the issues we have received, but
32
- we work from the queue.
31
+ > Oh, yes. The issue log is just a record of all the issues we have received, but
32
+ > we work from the queue.
33
33
34
- I see, and how do things get into the queue?
34
+ _ I see, and how do things get into the queue?_
35
35
36
- We triage the new items in the issue log to decide how urgent they are, and what
37
- categories they should be in. When we know how to categorise them, and how
38
- urgent they are, we treat the issues as a queue, and work through them in
39
- priority order.
36
+ > We triage the new items in the issue log to decide how urgent they are, and what
37
+ > categories they should be in. When we know how to categorise them, and how
38
+ > urgent they are, we treat the issues as a queue, and work through them in
39
+ > priority order.
40
40
41
- This is because users always set things to "Extremely urgent"?
41
+ _ This is because users always set things to "Extremely urgent"_ ?
42
42
43
- Yeah, it's just easier for us to triage the issues ourselves.
43
+ > Yeah, it's just easier for us to triage the issues ourselves.
44
44
45
- And what does that actually mean, like, do you just read the ticket and say "oh,
46
- this is 5 important, and it's in the broken mouse category"?
45
+ _ And what does that actually mean, like, do you just read the ticket and say "oh,
46
+ this is 5 important, and it's in the broken mouse category"?_
47
47
48
- Mmmm... more or less, sometimes we need to ask more questions from the user so
49
- we'll email them, or call them. Most things are first-come, first-served, but
50
- occasionally someone needs a fix before they can go to a meeting or something.
48
+ > Mmmm... more or less, sometimes we need to ask more questions from the user so
49
+ > we'll email them, or call them. Most things are first-come, first-served, but
50
+ > occasionally someone needs a fix before they can go to a meeting or something.
51
51
52
- So you email the user to get more information, or you call them up, and then you
53
- use that information to assess the priority of the issue - sorry triage the
52
+ _ So you email the user to get more information, or you call them up, and then you
53
+ use that information to assess the priority of the issue - sorry * triage* the
54
54
issue, and work out what category it should go in... what do the categories
55
- achieve? Why categorise?
55
+ achieve? Why categorise?_
56
56
57
- Partly for reporting, so we can see what stuff is taking up the most time, or if
58
- there are clusters of similar problems on a particular batch of laptops for
59
- example. Mostly because different engineers have different skills, like if you
60
- have a problem with the Active Directory domain, then you should send that to
61
- Barry, or if it's an Exchange problem, then George can sort it out, and Mike has
62
- the equipment log so he can give you a temporary laptop and so on, and so on.
57
+ > Partly for reporting, so we can see what stuff is taking up the most time, or if
58
+ > there are clusters of similar problems on a particular batch of laptops for
59
+ > example. Mostly because different engineers have different skills, like if you
60
+ > have a problem with the Active Directory domain, then you should send that to
61
+ > Barry, or if it's an Exchange problem, then George can sort it out, and Mike has
62
+ > the equipment log so he can give you a temporary laptop and so on, and so on.
63
63
64
- Okay , and where do I find this "queue"?
64
+ _ Okay , and where do I find this "queue"?_
65
65
66
- Your customer grins and gestures at the wall where a large whiteboard is covered
67
- in post-its and stickers of different colours.
66
+ > Your customer grins and gestures at the wall where a large whiteboard is covered
67
+ > in post-its and stickers of different colours.
68
+
69
+ ## Mapping our requirements to our domain
68
70
69
- Mapping our requirements to our domain
70
71
How can we map these requirements back to our system? Looking back over our
71
72
notes with the domain expert, there's a few obvious verbs that we should use to
72
73
model our use cases. We can triage an issue, which means we prioritise and
0 commit comments