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

FDD Features and Task Cases

Expand Messages
  • David J. Anderson
    Jeff, I read your material. Thanks for the pointer. What a pity, we didn t get a chance to meet at OOPSLA - I am based in Seattle and attended the conference
    Message 1 of 18 , Mar 13 8:54 AM
    • 0 Attachment
      Jeff,

      I read your material. Thanks for the pointer. What a
      pity, we didn't get a chance to meet at OOPSLA - I am
      based in Seattle and attended the conference for a
      single day.

      Anyway, I felt I needed to give you some feedback
      regarding FDD. You need to be careful when relating
      Task Cases to FDD. FDD Features are not tasks. They
      are not procedures but functions.

      FDD uses architectural partitioning. There are four
      types of Features in FDD: PD (problem domain or
      business logic); UI (user interface); DM (data
      management or persistence); SI (systems interface).

      Most of the writing on FDD only talks about PD so
      those less familiar with it can be forgiven for
      mistakes in interpretation.

      The Feature partitioning existed right from the start
      in FDD. Of the regular contributors at
      http://www.featuredrivendevelopment.com/ Steve Palmer,
      Pauyl Szego and Jeff De Luca matured the PD Feature
      methods. As these were most mature when the book "Java
      Modeling in Color with UML" was written, these were
      the things which were written down. Philip Bradley was
      repsonsible for the SI and DM side of FDD and I was
      repsonsible for the UI.

      On the original project the UI was split into two
      levels which were known as HLD and LLD (High level and
      Low level design - respectively). The HLD tracked my
      own work as the designer. The LLD tracked the
      developers work programming the UI.

      Later I wrote a paper "Extending FDD for UI" which
      updated the LLD process using Ian Horrock's work of
      Statechart Modeling for UI based on David Harel's
      original Statechart notation.

      Today, UI Features are grouped in Sets based on the
      Container in the UI design. There are Features for
      each View and Features for each event controller (or
      action).

      FDD Features are much more like object-oriented
      Function Points than tasks or use cases. This is a
      significant distinction from other methods.

      Hence, Task Cases need to be elaborated into a Content
      Model and Interaction Model before Features can be
      defined.

      Best Regards,

      David
      --
      David J. Anderson
      http://www.uidesign.net/
      The Webzine for Interaction Designers


      --- Jeff Patton <jeff621@...> wrote:


      I haven't written too much, but you'll find an
      experience report
      here: http://oopsla.acm.org/fp/files/pra_extra.html
      If I get my act
      together, I'll be giving a presentation and/or
      tutorial on exactly
      this stuff at ForUse 2003.

      cheers,

      -Jeff



      __________________________________________________
      Do you Yahoo!?
      Yahoo! Web Hosting - establish your business online
      http://webhosting.yahoo.com
    • Jeff Patton
      Thanks David for the feedback. I m sure it s obvious that my knowledge of FDD is a little sketchy. Based on the little reading I d done, I d very roughly
      Message 2 of 18 , Mar 13 9:50 AM
      • 0 Attachment

        Thanks David for the feedback.  I'm sure it's obvious that my knowledge of FDD is a little sketchy.  Based on the little reading I'd done, I'd very roughly equated FDD features to XP stories - and from what I'm hearing, if you look at them sideways, FDD PD type features could be mistaken for stories.  I'll dig in over the next little while and read more about FDD so I can understand it better.  But, I have to admit that the little bit of reading I've done has left me confused.  I had actually found your site and read your article there months ago.

        >Hence, Task Cases need to be elaborated into a Content
        Model and Interaction Model before Features can be
        defined.<

        In practice, these days, I've found this to be true also.  I am finding that I can't simply recast task cases into things to develop. 

        My methods these days are more about establishing a language that works between development, customers and management.  I don't like the XP term "story" - since folks with millions of dollars to spend don't feel good about characterizing their needs as a "pack of stories."  I have been using the term "feature."  And by that I mean something that is understandable by customer and management, decomposable and buildable by development, testable by QA and easily demonstrable at acceptance time.  For those features I look for traceability back through the U-CD task and role models.  I need to know who uses the feature, in support of what goal, and as part of what task.

        Looking at what I understand so far about FDD, the granularity of feature types might fail some of my tests for a valid feature - such as "understandable by customer and management."  Today, every once in a while, I let features slip into scope documents that fail my tests above.  After 30 minutes on a conference call explaining to a group of customers what I mean by BusinessObject, object-relational mapping and persistence, I've sworn to plan, manage and commicate about projects in terminology that works for most people involved.  Internally we'll break my course-grain features out into development tasks that might closely match up to FDD features types - but for us that sort of exercise is part of our teams implementation - not our public interface - if that makes sense.    

        This very course-grain feature probably really is an XP story.  That's what I'm finding U-CD very effective at generating quickly and collaboratively. 

        But, back to the original point of your message - I'd better get up to speed on FDD so I'm not mis-using its terminology.  And, more importantly, so I can make use of the work you and others have done.

        BTW: I'd found and rooted around in your site sometime last year, but at that time it looked like you'd discontinued posting new content.  Looking at it now I see lots of new stuff to read.  I'll look forward to digging through it.

        Thanks again for the feedback.  I look forward to meeting you sometime soon.  I'm sure we'll stumble across each other at one of these conferences.

        If you're ever in or near my neck of the wood, Salt Lake City, please look me up. 

        cheers,

        -Jeff

         "David J. Anderson" <netherby_uk@...> wrote:

        Jeff,

        I read your material. Thanks for the pointer. What a
        pity, we didn't get a chance to meet at OOPSLA - I am
        based in Seattle and attended the conference for a
        single day.

        Anyway, I felt I needed to give you some feedback
        regarding FDD. You need to be careful when relating
        Task Cases to FDD. FDD Features are not tasks. They
        are not procedures but functions.

        FDD uses architectural partitioning. There are four
        types of Features in FDD: PD (problem domain or
        business logic); UI (user interface); DM (data
        management or persistence); SI (systems interface).

        Most of the writing on FDD only talks about PD so
        those less familiar with it can be forgiven for
        mistakes in interpretation.

        The Feature partitioning existed right from the start
        in FDD. Of the regular contributors at
        http://www.featuredrivendevelopment.com/ Steve Palmer,
        Pauyl Szego and Jeff De Luca matured the PD Feature
        methods. As these were most mature when the book "Java
        Modeling in Color with UML" was written, these were
        the things which were written down. Philip Bradley was
        repsonsible for the SI and DM side of FDD and I was
        repsonsible for the UI.

        On the original project the UI was split into two
        levels which were known as HLD and LLD (High level and
        Low level design - respectively). The HLD tracked my
        own work as the designer. The LLD tracked the
        developers work programming the UI.

        Later I wrote a paper "Extending FDD for UI" which
        updated the LLD process using Ian Horrock's work of
        Statechart Modeling for UI based on David Harel's
        original Statechart notation.

        Today, UI Features are grouped in Sets based on the
        Container in the UI design. There are Features for
        each View and Features for each event controller (or
        action).

        FDD Features are much more like object-oriented
        Function Points than tasks or use cases. This is a
        significant distinction from other methods.

        Hence, Task Cases need to be elaborated into a Content
        Model and Interaction Model before Features can be
        defined.

        Best Regards,

        David
        --
        David J. Anderson
        http://www.uidesign.net/
        The Webzine for Interaction Designers


        --- Jeff Patton <jeff621@...> wrote:


        I haven't written too much, but you'll find an
        experience report
        here: http://oopsla.acm.org/fp/files/pra_extra.html
        If I get my act
        together, I'll be giving a presentation and/or
        tutorial on exactly
        this stuff at ForUse 2003.

        cheers,

        -Jeff



        __________________________________________________
        Do you Yahoo!?
        Yahoo! Web Hosting - establish your business online
        http://webhosting.yahoo.com


        Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



        Do you Yahoo!?
        Yahoo! Web Hosting - establish your business online

      • David J. Anderson
        Yes, the term Feature was never completed satisfactory. Se my post at the FDD community site on A Feature by any other name . Features in FDD come after
        Message 3 of 18 , Mar 13 10:01 AM
        • 0 Attachment
          Yes, the term Feature was never completed
          satisfactory.

          Se my post at the FDD community site on "A Feature by
          any other name".

          Features in FDD come after initial analysis. The PD
          Features are definitely understandable by the
          customer. The UI Features are too. Customers
          comprehend a single View object and they understand
          the notion that code must be written to process button
          presses and their like. SI and DM are not understood
          by the customer.

          Hence, I tend to work with Marketing Features - which
          would be your coarse-grained features - and either FDD
          or Coad Features which are the Features as defined in
          FDD for UI, PD, DM and SI.

          The Feature template for PD and the architectural
          partitioning are Peter Coad's contributions to FDD.

          Sadly, there still isn't enough written down about FDD
          in the other layers outside of PD.

          I intend to re-launch uidesign.net in April with
          irregular content. The recent material there will be
          moving to my other site agilemanagement.net.

          David

          --- Jeff Patton <jeff621@...> wrote:
          >
          >
          > BTW: I'd found and rooted around in your site
          > sometime last year, but at that time it looked like
          > you'd discontinued posting new content. Looking at
          > it now I see lots of new stuff to read. I'll look
          > forward to digging through it.
          >


          __________________________________________________
          Do you Yahoo!?
          Yahoo! Web Hosting - establish your business online
          http://webhosting.yahoo.com
        • Handan Nalbantoglu
          Please unsubscribe me from this group. http://mobile.yahoo.com.au - Yahoo! Mobile - Check & compose your email via SMS on your Telstra or Vodafone mobile.
          Message 4 of 18 , Jun 26, 2003
          • 0 Attachment
            Please unsubscribe me from this group.

            http://mobile.yahoo.com.au - Yahoo! Mobile
            - Check & compose your email via SMS on your Telstra or Vodafone mobile.
          • Ben Luff
            Hi, Please could you remove my email from your mailing list? Thanks, Ben
            Message 5 of 18 , Jun 27, 2003
            • 0 Attachment
              Hi,

              Please could you remove my email from your mailing list?

              Thanks,

              Ben
            • Richard J Watt
              Message 6 of 18 , Jun 28, 2003
              • 0 Attachment
              • ben@system-concepts.com
                Message 7 of 18 , Jul 9, 2003
                • 0 Attachment
                • tsjosten@abo.fi
                  Unsubscribe
                  Message 8 of 18 , Jul 16, 2003
                  • 0 Attachment
                    Unsubscribe
                  Your message has been successfully submitted and would be delivered to recipients shortly.