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

Re: [TDD] Help Required

Expand Messages
  • JeffGrigg
    ... I was involved in Document-Driven approaches for quite a few years before joining the XP community. Requirements Tracability was always a promise of the
    Message 1 of 11 , Aug 3, 2011
      --- abrar arshad <ibrararshad@...> wrote:
      > Yeah I know requirements traceability has always been related
      > to formal requirements specification and in agile with don't
      > have formal documentation. ... For instances, how do you know
      > where to make changes if your client wants you to change a
      > feature which already has been developed. There is a chance
      > that changing one feature might effect the others as well.
      > ...

      I was involved in Document-Driven approaches for quite a few years before joining the XP community. "Requirements Tracability" was always a promise of the document-driven approach, used in part to justify its high cost. But honestly, I have never seen it deliver as promised:

      Requirements tracability advocates say that it will show you where to make a new change, and that it will highlight conflicting requirements. I have never seen this happen in practice.

      Consider this example: We have a system that is computing hourly pay in several divisions at several union plants. There is a fair amount of hard-coded conditional code. We just renegotiated the overtime rates for one of the divisions at two plants.

      For requirements tracability to be useful, it has to be easier to find the original requirements for these divisions and to trace these requirements down to code than it would be to find the code directly. And to see conflicts, one would have to go from all the requirements that are relevant to the code back to the requirements documents -- and then somehow figure out what to do with a whole bunch of requirements statements -- to see if they conflict or overlap in any way, and how to resolve the issues.

      Generally, in practice, it's pretty easy to find the relevant code, even without any external requirements documentation. It's easier to find the code than to trace through a tangled mess of requirement number references.

      And to make the change... Add or change tests. Then change the code so that it passes the tests. If there are conflicting requirements, other tests will fail. You'll look at the other tests and probably learn something. Sometimes it's a technical issue, easily solved. Sometimes it is a real conflict in the business requirements. In that case, you will probably have to go back to the business requirements and maybe to the people who specify them to resolve the business issue.

      So requirements tracability is not only costly and quickly out of date, it turns out to not be very useful. About the only good thing I've seen requirements tracability do is to serve as a checklist of all the things the system must do: When they're all checked off, then you have reason to believe that the system does everything that's been requested. User stories with automated acceptance tests also do this -- with much higher justifiable confidence levels.
    • George Dinwiddie
      Jeff, That email deserves to be published! - George ... -- ... * George Dinwiddie * http://blog.gdinwiddie.com Software Development
      Message 2 of 11 , Aug 3, 2011
        Jeff,

        That email deserves to be published!

        - George

        On 8/3/11 8:31 AM, JeffGrigg wrote:
        > --- abrar arshad<ibrararshad@...> wrote:
        >> Yeah I know requirements traceability has always been related
        >> to formal requirements specification and in agile with don't
        >> have formal documentation. ... For instances, how do you know
        >> where to make changes if your client wants you to change a
        >> feature which already has been developed. There is a chance
        >> that changing one feature might effect the others as well.
        >> ...
        >
        > I was involved in Document-Driven approaches for quite a few years before joining the XP community. "Requirements Tracability" was always a promise of the document-driven approach, used in part to justify its high cost. But honestly, I have never seen it deliver as promised:
        >
        > Requirements tracability advocates say that it will show you where to make a new change, and that it will highlight conflicting requirements. I have never seen this happen in practice.
        >
        > Consider this example: We have a system that is computing hourly pay in several divisions at several union plants. There is a fair amount of hard-coded conditional code. We just renegotiated the overtime rates for one of the divisions at two plants.
        >
        > For requirements tracability to be useful, it has to be easier to find the original requirements for these divisions and to trace these requirements down to code than it would be to find the code directly. And to see conflicts, one would have to go from all the requirements that are relevant to the code back to the requirements documents -- and then somehow figure out what to do with a whole bunch of requirements statements -- to see if they conflict or overlap in any way, and how to resolve the issues.
        >
        > Generally, in practice, it's pretty easy to find the relevant code, even without any external requirements documentation. It's easier to find the code than to trace through a tangled mess of requirement number references.
        >
        > And to make the change... Add or change tests. Then change the code so that it passes the tests. If there are conflicting requirements, other tests will fail. You'll look at the other tests and probably learn something. Sometimes it's a technical issue, easily solved. Sometimes it is a real conflict in the business requirements. In that case, you will probably have to go back to the business requirements and maybe to the people who specify them to resolve the business issue.
        >
        > So requirements tracability is not only costly and quickly out of date, it turns out to not be very useful. About the only good thing I've seen requirements tracability do is to serve as a checklist of all the things the system must do: When they're all checked off, then you have reason to believe that the system does everything that's been requested. User stories with automated acceptance tests also do this -- with much higher justifiable confidence levels.
        >
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
        >

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • JeffGrigg
        ... Why thank you. To make it a little more persistent and accessible, I copied it to my blog:
        Message 3 of 11 , Aug 3, 2011
          --- George Dinwiddie <lists@...> wrote:
          > Jeff,
          > That email deserves to be published!
          > - George

          Why thank you. To make it a little more persistent and accessible, I copied it to my blog:

          http://jeffgrigg.wordpress.com/2011/08/03/my-experiences-with-requirements-traceability/
        • Adam Sroka
          I think this is an interesting line of inquiry, and I will consider filling out the survey when I am back in front of my computer. However, I also think the
          Message 4 of 11 , Aug 4, 2011
            I think this is an interesting line of inquiry, and I will consider filling
            out the survey when I am back in front of my computer.

            However, I also think the notion of what TDD has to do with requirements
            traceability is potentially confusing. TDD has nothing to do with RT per se.
            Why/if/how you trace requirements to code is a methodology problem and TDD
            is a design technique not a methodology.

            An even more potentially interesting question, IMO, would be what the
            business goal of RT is and how that business goal is achieved by Agile
            teams.
            On Aug 1, 2011 7:18 PM, "abrar arshad" <ibrararshad@...> wrote:
            > Hi all
            > I am doing my master thesis on "Requirements Traceability in TDD". I am
            doing a survey to gather views of test driven developers about requirements
            traceability in TDD.
            > Kindly, fill the survey form provided below if possible (it won't take
            much time but it would help me alot).
            >
            https://spreadsheets.google.com/spreadsheet/viewform?formkey=dGxNMjJQbVNuV2RtTWphbGNvRFZrWXc6MQ#gid=0
            >
            > Thanks in advance.
            > Regards
            > Ibrar
            >
            >
            > [Non-text portions of this message have been removed]
            >


            [Non-text portions of this message have been removed]
          Your message has been successfully submitted and would be delivered to recipients shortly.