Loading ...
Sorry, an error occurred while loading the content.
 

Re: [agile-usability] design or requirements was: RE: Re: Subtle User Intera...

Expand Messages
  • PaulOldfield1@aol.com
    (responding to Jeff) ... This is one point where I like using UML s Use case symbols - you know, the oval one with the stick man outside. That is a Use Case
    Message 1 of 3 , Aug 2, 2006
      (responding to Jeff)
       
      >
      ...Hearing the statement “design masquerading as a requirement” is
      > interesting to me.  I believe the process of considering solutions to
      > a
      problem and deciding on a best one /is/ design.  So, in my mind
      > the product of design /is/ a requirement...
       
      This is one point where I like using UML's Use case symbols - you
      know, the oval one with the stick man outside.  That is a Use Case
      for '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' and
      the stick man.  I call this 'our business'.  There's a stick man outside
      this, who might be 'the customer for our business', but our first
      stick man is inside this second oval.  We could call him 'our
      business 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 being
      given the design of 'our system' masquerading as requirements
      for 'our system'.
       
      One question that people have been addressing recently is the
      question of getting feedback from what we learn as we design
      'our system' into the design of 'our business'.  Mary Poppendieck
      reports from Sweden that some companies over there are
      building the 'business system' (i.e. manual processes etc.)
      and the automated system ('our system') together as a
      holistic, integrated entity.
       
      Why does it matter, if the design needs to be done anyway?
      Because design isn't easy, and design decisions should
      be made by those in full posession of relevant facts and
      with best knowledge of options for a solution.  If we're
      deciding on technical design, leave it to the system architects
      and 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 terminology
      issue, and my standpoint on that.  It might also help us
      identify points where we differ, if any remain.
       
      Paul Oldfield
       
       
    • Jeff Patton
      Hi Paul, 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
      Message 2 of 3 , Aug 2, 2006

        Hi Paul,

         

        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.  ;-)

         

        Thanks,

         

        -Jeff

         


        From: agile-usability@yahoogroups.com [mailto: agile-usability@yahoogroups.com ] On Behalf Of PaulOldfield1@...
        Sent: Wednesday, August 02, 2006 11:21 AM
        To: agile-usability@yahoogroups.com
        Subject: 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

        > a problem and deciding on a best one /is/ design.  So, in my mind

        > the product of design /is/ a requirement. ..

         

        This is one point where I like using UML's Use case symbols - you

        know, the oval one with the stick man outside.  That is a Use Case

        for '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' and

        the stick man.  I call this 'our business'.  There's a stick man outside

        this, who might be 'the customer for our business', but our first

        stick man is inside this second oval.  We could call him 'our

        business 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 being

        given the design of 'our system' masquerading as requirements

        for 'our system'.

         

        One question that people have been addressing recently is the

        question of getting feedback from what we learn as we design

        'our system' into the design of 'our business'.  Mary Poppendieck

        reports from Sweden that some companies over there are

        building the 'business system' (i.e. manual processes etc.)

        and the automated system ('our system') together as a

        holistic, integrated entity.

         

        Why does it matter, if the design needs to be done anyway?

        Because design isn't easy, and design decisions should

        be made by those in full posession of relevant facts and

        with best knowledge of options for a solution.  If we're

        deciding on technical design, leave it to the system architects

        and 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 terminology

        issue, and my standpoint on that.  It might also help us

        identify points where we differ, if any remain.

         

        Paul Oldfield

         

         

      • PaulOldfield1@aol.com
        (responding to Jeff) And for others, sorry, this is a bit of an epic. I think it s worth writing, but feel free to differ. ... I ve had this discussion
        Message 3 of 3 , Aug 2, 2006
          (responding to Jeff)
           
          And for others, sorry, this is a bit of an epic.  I think it's worth
          writing, 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 useful
          observation nobody has made before.  (I'd dig out the old e-mails
          if I hadn't lost them in a disk crash...).  Yes, a Use case expects
          a crisp edge, a well-defined boundary to the system, at least
          by the time we finish writing it.  With user stories this edge starts
          fuzzier; we don't get the crisp definition until the acceptance
          tests 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 inner
          oval but inside the outer oval.  The outer oval represents the business
          and all its systems (manual and automated).  The inner oval
          represents the IT system; specifically that IT system we are building.
          For an enterprise model, the outer oval could contain many nested
          ovals. So the business worker is inside the business but outside
          the 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, but
          not IT system design.  Remember, the two ovals represent
          different systems, that are nested.  So this is design of the outer
          system.
           
          > 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 doing
          business 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 a
          requirement on the inner, IT system.  Negotiating the requirement
          is best done by collaboration between the designers of the two
          systems and the person who is going to have to use the system;
          possibly with a few other roles thrown in.  Of course, these roles
          can be combined in various ways.  The user of the IT system might
          also 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.  Yet
          at some point, the decision becomes (relatively) irrevocable,
          immutable.  The trick is to ensure this doesn't happen until
          they don't need to be questionable - until all questions have
          already been asked and answered.  Even when working with
          Use cases we can ensure the conversations that need to happen
          have happened before the use case is 'done'... provided we
          don't get a PM who demands sign off before he will sanction
          commencement of design  :-(   User stories are *expected* to
          have 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 the
          conversation.  As for the high precision example, I'd need to
          ask a few questions to find out what is wanted; that's
          almost all solution.  It might turn out to be the right solution;
          ideal for what the user wants.  Yet we could choose to accept
          these stories as-is, because they are placeholders for a
          conversation.
           
          <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 album
          cover are open to negotiation.  We tell the business what's feasible
          and what it costs; they tell us what they need, which of the
          feasible options they prefer after consideration of the cost, and
          what priority to put on this compared to their other requirements.
          It doesn't matter where the ideas come from; a good idea is a
          good 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 come
          in to play.  First, we may get better information later.  Second,
          we need to record the decision because we aren't going to
          act on it straight away.  Okay that isn't strictly true, but we can
          only hold a few decisions in memory.
           
          > Hope I didn’t get to edgy with those opinions.  ;-)
           
          Not by my reckoning.
          Thanks.
           
          Paul Oldfield
           
           
        Your message has been successfully submitted and would be delivered to recipients shortly.