> 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
> gre...@gm...
>
>
>
Greg Stern
gre...@gm...
|
