Re: [agile-usability] design or requirements was: RE: Re: Subtle User Intera...
- (responding to Jeff)
...Hearing the statement “design masquerading as a requirement” is>> interesting to me. I believe the process of considering solutions to
problem and deciding on a best one /is/ design. So, in my mind> a> the product of design /is/ a requirement...This is one point where I like using UML's Use case symbols - youknow, the oval one with the stick man outside. That is a Use Casefor 'our system'. I think of 'our system' as being the inside of the oval.Clearly the stick man is outside the oval.Now what I do is draw a larger oval, encompassing 'our system' andthe stick man. I call this 'our business'. There's a stick man outsidethis, who might be 'the customer for our business', but our firststick man is inside this second oval. We could call him 'ourbusiness worker'; somebody who works inside 'our business'.This sets me up nicely to make the distinction between 'our business'as a system that has requirements and design, and 'our system'that has requirements and design.Now the design of 'our business' drives the requirements of'our system'. That's legitimate. What we want to avoid is beinggiven the design of 'our system' masquerading as requirementsfor 'our system'.One question that people have been addressing recently is thequestion of getting feedback from what we learn as we design'our system' into the design of 'our business'. Mary Poppendieckreports from Sweden that some companies over there arebuilding the 'business system' (i.e. manual processes etc.)and the automated system ('our system') together as aholistic, integrated entity.Why does it matter, if the design needs to be done anyway?Because design isn't easy, and design decisions shouldbe made by those in full posession of relevant facts andwith best knowledge of options for a solution. If we'redeciding on technical design, leave it to the system architectsand technical designers. If we're designing business processes,leave it to the business architects and business designers.I hope that picture helps you make sense of a tricky terminologyissue, and my standpoint on that. It might also help usidentify points where we differ, if any remain.Paul Oldfield
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 think in the picture you’re sketching with words below you draw the business worker pointing to the usecase as inside the system oval. Does that imply that deciding who the workers are and what they do is part of the design of the system? And does that make that the responsibility of the developer? Or is supporting specific workers to use the system to do specific tasks part of the requirements of the system? If supporting specific workers doing specific tasks is part of the requirements – 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?
You do a good job below pointing out that there’s lots of design going on and lots of different kinds of designers: system architects, technical designers, business architects, business designers. Which I think makes the point I was getting at – design happens at lots of levels and the results of a design can be tagged “requirement” and fed forward.
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 think the point I’m trying to make – and a point I know you understand – is that what’s written on a story card is a decision for some capability in the software that the customer believes they need. It’s their best decision based on their understanding of the problem. It may vary in precision – 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.” Now whether an album cover picture should be in the search return or not, and exactly how big it should be if we choose to place it there are decisions that need to be made. Things like what side of the UML oval those decisions fall on hurt my head to think about since at the end of the day no one’s buying UML diagrams [unless you work for Accenture]. Things like whether they should or shouldn’t have been made before the story card was written also hurt my head – since at the end of the day no one’s buying story cards either.
So wrapping back to my original point, the label “design decision” or “requirement” is a subjective one – and the choice to use one term or the other doesn’t change what it is – rather it implies a degree of immutability and/or implies who should or did make the decision – and in the case of the phrase “design masquerading as a requirement” who shouldn’t have made the decision. Those are interesting concerns if you’re trying to enforce a process – but less interesting if your ultimate concern is the quality of the finished software.
Hope I didn’t get to edgy with those opinions. ;-)
- (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