Re: Feature request/discussion: Trace to requirements

> Larry and others,
>
> What you stated below brings me to my next / parallel project idea  
> I have been thinking about. Managing requirements and traceability  
> is a difficult thing when you get to the concept of platforms,  
> multiple products which may use the platform to do slightly  
> different things (and at some point branch off, etc).
>
> Really what you need is your requirements "branching" and your code  
> "branching" need to be in sync. The other end of the project I have  
> been considering is a web-based requirements management system  
> which would handle this, amongst other things.
>
> But back to the Doxygen point in hand; at some point, I think you  
> have to specify for each branch, a code or groups of code root  
> requirements. Either you do that in the requirements/design  
> documents or you do it in the code. I think it is better for the  
> code to know about the requirements rather than the requirements to  
> "know" about the code.
>
> However, the "set of code" brings me to the next point I have been  
> thinking about. Generally when you trace from requirements to code,  
> you often go through design (software design doc). In my previous  
> company, we were writing our SDDs in Doxygen and at the end of a  
> SDD we would list the groups of code that implemented the design.
>
> So to generalize this, I think @defgroup should be able to trace to  
> requirements, which means every class in that group will trace to  
> the requirements that the group traces to. (Which is also one way  
> to manage what you were stating, then you only have to change the  
> groups requirement tracing, rather than each class).
>
> This also brings me to another point: tracing from requirements ->  
> design -> code -> test. Doxygen can clearly play a strong role in  
> the code -> test (at least some tests) and I believe naturally  
> design -> code. What is missing is the requirements -> design or  
> requirements -> code and knowledge of design -> code. Some options/ 
> ideas I have been thinking about; one is to add an option to @page  
> to stated that the page is an SDD and if a class description  
> references the SDD than it could auto link to the SDD (and create  
> the trace). Or you could require a special command to trace.
>
> My next step is to capture all of these ideas down into stories/ 
> requirements and to start researching the doxygen implementation to  
> investigate feasibility.
>
> Let me know if anyone is interested in these project ideas. I  
> always appreciate a good discussion and viewpoints (and code).
>
> Greg
>
> On Sep 7, 2007, at 11:59 AM, Randall, Larry wrote:
>
>> Well,  I "fat fingered" send instead of save...
>>
>> I was going to say that test cases are constantly added, and software
>> requirements may trace to different code in different release  
>> streams.
>>
>> Perhaps, rather than trying to maintain a set of "traceability  
>> links" in
>> code, we could maintain a unique ID for each "set" of code (i.e.,
>> function, feature, API,.....).  We could then automate traceability
>> linkages in a database.
>>
>> Other ideas ????
>>
>> Regards,
>> Larry
>>
>
> Greg Stern
> [email protected]
>
>
>

Greg Stern
[email protected]




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/