headers
abrar arshad | 2 Aug 2011 01:18
Picon
Favicon

Help Required

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]

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest <at> yahoogroups.com 
    testdrivendevelopment-fullfeatured <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 10 comments |
headers
Steven Gordon | 2 Aug 2011 01:46
Picon

Re: Help Required

Ibrar,

What exactly do you mean by "requirements traceability"?

Who uses "requirements traceability" and what exactly do they use it for?
 Can we not attain all the same goals in agile software development without
formal traceability?

Do you believe that random software developers really understand the
term "requirements traceability" the same way?  If not, how can the results
of a survey where different people have different interpretations of the
term be statistically valid?

Steven Gordon, PhD

On Mon, Aug 1, 2011 at 4:18 PM, abrar arshad <ibrararshad <at> yahoo.co.uk>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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
abrar arshad | 2 Aug 2011 02:05
Picon
Favicon

Re: Help Required

Yeah, everybody here can have his/her own interpretation of requirements traceability. Actually, this
survey is a start up to gather information about what actually happens in industry and I won't be applying
any statical analysis on the data gathered from it. I have contacted organizations who are working in this
domain and will conduct some interviews. The purpose of posting it here is to gather as much information as
I can and later based on it, I can design my interview questionnaire.  

--- On Tue, 2/8/11, Steven Gordon <sgordonphd <at> gmail.com> wrote:

From: Steven Gordon <sgordonphd <at> gmail.com>
Subject: Re: [TDD] Help Required
To: testdrivendevelopment <at> yahoogroups.com
Date: Tuesday, 2 August, 2011, 4:46

Ibrar,

What exactly do you mean by "requirements traceability"?

Who uses "requirements traceability" and what exactly do they use it for?
 Can we not attain all the same goals in agile software development without
formal traceability?

Do you believe that random software developers really understand the
term "requirements traceability" the same way?  If not, how can the results
of a survey where different people have different interpretations of the
term be statistically valid?

Steven Gordon, PhD

On Mon, Aug 1, 2011 at 4:18 PM, abrar arshad <ibrararshad <at> yahoo.co.uk>wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Donaldson, John (GEO | 2 Aug 2011 09:01
Picon
Favicon

RE: Help Required

On my current project, they are asking for "requirements traceability".
But, we don't really have a requirements spec - the customer asked us to modernize an old app - so the "spec" is
something like: "the new app does the same as the old app, but in a more flexible way using modern
techniques, languages and products". Hmm!

But we wrote a description of the solution down to the feature level - and I am aiming to tie the traceability
to feature delivery, because the features are all traceable to the old app. And of course, we have
automated tests for each feature.

But, we don't have low-level requirements in this way of working.

John D.

-----Original Message-----
From: testdrivendevelopment <at> yahoogroups.com [mailto:testdrivendevelopment <at> yahoogroups.com] On
Behalf Of Steven Gordon
Sent: 02 August 2011 05:17
To: testdrivendevelopment <at> yahoogroups.com
Subject: Re: [TDD] Help Required

Ibrar,

What exactly do you mean by "requirements traceability"?

Who uses "requirements traceability" and what exactly do they use it for?
 Can we not attain all the same goals in agile software development without
formal traceability?

Do you believe that random software developers really understand the
term "requirements traceability" the same way?  If not, how can the results
(Continue reading)

Permalink | Reply | 1 comment |
headers
JeffGrigg | 2 Aug 2011 16:47
Picon
Gravatar

Re: Help Required

--- "Donaldson, John (GEO)" <john.m.donaldson <at> ...> wrote:
> On my current project, they are asking for "requirements
> traceability".
>
> But, we don't really have a requirements spec - the customer
> asked us to modernize an old app - ...
>
> But we wrote a description of the solution down to the
> feature level - and I am aiming to tie the traceability
> to feature delivery, because the features are all traceable
> to the old app. And of course, we have automated tests for
> each feature.

My first thought is that the tests are the requirements.  And their tracability to the code can be seen with
any good code coverage tool -- or a debugger.

If they want to pay more money and delay delivery in order to feel better about something called
"tracability," then I suppose that one could number the documented features and put the numbers in test
and/or checkin comments.  (Or, for each feature, one could list the tests that verify it.)  None of this
ensures that you successfully captured all the requirements of the old application that they care about. 
But you and they will find out later if that's an issue.  ;->

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Roth | 2 Aug 2011 19:44
Picon

Re: Help Required

Since I'm retired, there wasn't any reason to actually include my 
opinions in your survey, but your survey didn't let me look at the 
entire thing without filling out the preceding pages. Consequently, I 
have no idea what questions you were asking.

My understanding of requirements traceability from CMMi and other 
sources is that it starts with formal requirements. TDD is not a 
complete development process, so the formal requirement piece needs to 
be supplied from some more comprehensive process.

One approach I've heard several times is to use an executable 
requirements tool such as FitNesse or a similar product. Then it's easy 
enough to write a few scripts that track changes in the repository to 
the implementation of the executable requirements, the code base and the 
problem tracking system. This approach adds the least manual overhead, 
and it's reported to be very acceptable to most auditors if explained 
and carried through properly.

HTH

John Roth

On 8/1/11 5:18 PM, abrar arshad 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).
(Continue reading)

Permalink | Reply | 4 comments |
headers
abrar arshad | 3 Aug 2011 14:01
Picon
Favicon

Re: Help Required

Firstly I would like to thanks all of you for this interesting debate.
Yeah I know requirements traceability has always been related to formal requirements specification and
in agile with don't have formal documentation. But still traceability is implemented even though it is
not explicit. 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.
In literature, there are few studies that make emphasis on implementation on requirements traceability
in agile and consider it very important like it is considered in traditional software development. I
might be wrong but from this conversation, I think most of industry practitioner here don't consider
traceability as an issue in agile development.
Anyways thanks for your time and valuable feedback.
Regards

--- On Tue, 2/8/11, John Roth <JohnRoth1 <at> gmail.com> wrote:

From: John Roth <JohnRoth1 <at> gmail.com>
Subject: Re: [TDD] Help Required
To: testdrivendevelopment <at> yahoogroups.com
Date: Tuesday, 2 August, 2011, 22:44

 
 

    

      
      Since I'm retired, there wasn't any reason to actually include my 

opinions in your survey, but your survey didn't let me look at the
(Continue reading)

Permalink | Reply | 3 comments |
headers
JeffGrigg | 3 Aug 2011 14:31
Picon
Gravatar

Re: Help Required

--- abrar arshad <ibrararshad <at> ...> 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.
(Continue reading)

Permalink | Reply | 2 comments |
headers
George Dinwiddie | 3 Aug 2011 19:17
Favicon

Re: Help Required

Jeff,

That email deserves to be published!

  - George

On 8/3/11 8:31 AM, JeffGrigg wrote:
> --- abrar arshad<ibrararshad <at> ...>  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
(Continue reading)

Permalink | Reply | 1 comment |
headers
JeffGrigg | 3 Aug 2011 22:50
Picon
Gravatar

Re: Help Required

--- George Dinwiddie <lists <at> ...> 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/

------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    testdrivendevelopment-digest <at> yahoogroups.com 
    testdrivendevelopment-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    testdrivendevelopment-unsubscribe <at> yahoogroups.com
(Continue reading)

Permalink | Reply | 0 comments |

Gmane