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

XP Stories and UML Use Cases

Expand Messages
  • Rosenbaum Yaron
    Hi. User stories are great, but they re not enough. Besides breaking a user story into engineering tasks, the requirement itself can be broken by the customer
    Message 1 of 85 , Feb 20, 2003
    • 0 Attachment
      Hi.

      User stories are great, but they're not enough. Besides breaking a user
      story into engineering tasks, the requirement itself can be broken by the
      customer in to detailed sub-requirements, to various levels. These
      sub-requirements can be futher broken by R&D to more technical requirements
      from the original system, sub-systems, or other systems.
      Another issue worth addressing, is documenting these requirements properly.

      Stories are one way to document requirements, but I feel like it should be
      extended.

      The company that I work for, produces large-scale products for telco
      operators. (If you have a voicemail, it's probably ours).
      If(you're planning on convincing me that I don't need this) {I'm writing
      this, just because (forgive me, but) I'm not interested in emails trying to
      convince me documenting requirements is a waste of time, and stories are
      good enough. I know what I need, and even a change to requirements at the
      format I'm describing is a big change which is hard enough to introduce.
      }
      Else { keep reading} :-)

      I've been trying to combine the unofficial free-text form narrative oriented
      'story' paradigm, with a more orderly UML Use Case. The results are rather
      interesting, and I would like to share them with all of you (and of course,
      hear some comments, and maybe evolve this technique further).

      I've taken all of the requirements of the current project I'm working on,
      and tried to create UML use cases, and scenarios.
      As you all may know, use cases and scenarios are no exact science, and the
      same story could sometimes be told in many different ways.
      What I did, was create an excel file per use case, and each sheet (table)
      represented a scenario within a use case.
      Each step in these scenarios had a row. Each row is composed of a few
      columns: ID, actor, action and description. As I digested more and more
      requirements, I developed techniques which are very similar to procedural
      programming: goto sentences, which point to another scenario (usually, to
      what we call a 'scenario fragment').
      Much the same as in procedural programming, it would be a bad practice to
      'copy-paste' scenario parts, and scenario fragment re-use should be
      preferred where possible.

      I'll stop the descriptions here, and let you dive into the examples I addad,
      not before pointing out that due to various reasons, I had to modify some
      names, and details.

      I can go on and on about stuff that I discovered along the way, and more
      philisophical issues, for example: The more detailed and formal the
      requirements, the more they look like (pseudo)code. Is it good? Is it bad?
      Can I use it? Etc..

      Waiting for your comments!


      Yaron Rosenbaum
      Chief Software Engineer
      CAP Project
      Comverse

      +972-3-7663411
      yaronr@...




      [Non-text portions of this message have been removed]
    • Kiel Hodges
      ... the ... form ... Well, they might come in verbally... On the whole, I would rather be doing XP. Kiel Hodges SelfSo Software
      Message 85 of 85 , Mar 26, 2003
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, Ron Jeffries
        <ronjeffries@a...> wrote:
        > On Wednesday, March 26, 2003, at 8:17:45 AM, Kiel Hodges wrote:
        >
        > > If the only purpose of requirement documents is to satisfy
        the
        > > manadate that they requirements are documented, then use the
        form
        > > that takes the least amount of work.
        >
        > That would be whatever form they come in, I expect ...
        >
        > Ron Jeffries
        > www.XProgramming.com
        > The Great and Powerful Oz has spoken.

        Well, they might come in verbally...

        On the whole, I would rather be doing XP.

        Kiel Hodges
        SelfSo Software
      Your message has been successfully submitted and would be delivered to recipients shortly.