Re: [agile-usability] design or requirements was: RE: Re: Subtle User Intera...
- (responding to Jeff)And for others, sorry, this is a bit of an epic. I think it's worthwriting, but feel free to differ.
style="FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">I think I understand the basics pretty well – although the fuzziness>> of the real world doesn’t seem to be well represented in the crisp> edged ovals of a UML: diagram.I've had this discussion several times, and that's a usefulobservation nobody has made before. (I'd dig out the old e-mailsif I hadn't lost them in a disk crash...). Yes, a Use case expectsa crisp edge, a well-defined boundary to the system, at leastby the time we finish writing it. With user stories this edge startsfuzzier; we don't get the crisp definition until the acceptancetests are written if we use a typical agile approach.> I think in the picture you’re sketching with words below you draw> the business worker pointing to the usecase as inside the system> oval.We have nested ovals; the 'business worker is outside the inneroval but inside the outer oval. The outer oval represents the businessand all its systems (manual and automated). The inner ovalrepresents the IT system; specifically that IT system we are building.For an enterprise model, the outer oval could contain many nestedovals. So the business worker is inside the business but outsidethe IT system.> Does that imply that deciding who the workers are and what they> do is part of the design of the system?It's part of the design of the outer oval - it is business design, butnot IT system design. Remember, the two ovals representdifferent systems, that are nested. So this is design of the outersystem.> And does that make that the responsibility of the developer?I assume here you are talking about the developer of the IT system,in which case, no. Not unless this developer is also doingbusiness process engineering.> Or is supporting specific workers to use the system to do specific> tasks part of the requirements of the system?Part of the requirements of the inner system, the IT system, Yes.> what about the specific steps of the tasks and the specific user> interactions of the tasks? Are those things designed? By who?> Agile customers or developers? And how much of that design> happens after the story card is introduced, and how much> happened before it was written?If the steps in the Business Worker's tasks are totally manual,then they are solely the responsibility of the Business Designer(or equivalent). If they are automated, then they become arequirement on the inner, IT system. Negotiating the requirementis best done by collaboration between the designers of the twosystems and the person who is going to have to use the system;possibly with a few other roles thrown in. Of course, these rolescan be combined in various ways. The user of the IT system mightalso be acting as designer of the business system, for example.> It’s that tagging a thing as a requirement that makes me bristle.> It smacks of waterfall thinking – hints at irrevocable immutable> decisions – seems to suggest that that since they’re requirements,> they aren’t questionable. But, I think my allergy to the word> requirement is my own problem. ;-)I hear what you're saying, and agree with the sentiment. Yetat some point, the decision becomes (relatively) irrevocable,immutable. The trick is to ensure this doesn't happen untilthey don't need to be questionable - until all questions havealready been asked and answered. Even when working withUse cases we can ensure the conversations that need to happenhave happened before the use case is 'done'... provided wedon't get a PM who demands sign off before he will sanctioncommencement of design :-( User stories are *expected* tohave the card, conversation, confirmation lifecycle.> ... low precisions like “customer enters album title in search> box to see a list of albums that match the title” to very high> precision like “place a 40 x 40 pixel image of the album cover> next to album listing in the search return.”I immediately think "search box" is design. Leave it for theconversation. As for the high precision example, I'd need toask a few questions to find out what is wanted; that'salmost all solution. It might turn out to be the right solution;ideal for what the user wants. Yet we could choose to acceptthese stories as-is, because they are placeholders for aconversation.<aside>> ... no one’s buying UML diagrams [unless you work for Accenture].They've moved on from powerpoint, then? ;-)</aside>In reality, things like whether to show a representation of the albumcover are open to negotiation. We tell the business what's feasibleand what it costs; they tell us what they need, which of thefeasible options they prefer after consideration of the cost, andwhat priority to put on this compared to their other requirements.It doesn't matter where the ideas come from; a good idea is agood idea from any source.As to when to make the decision - the best time is just in time.If we make the decision any earlier two significant things comein to play. First, we may get better information later. Second,we need to record the decision because we aren't going toact on it straight away. Okay that isn't strictly true, but we canonly hold a few decisions in memory.> Hope I didn’t get to edgy with those opinions. ;-)Not by my reckoning.Thanks.Paul Oldfield