Requirements management - Traceability
in [OOP]
|
Prev: Simple inheritence question
Next: SQL
From: timasmith on 2 Jan 2006 14:16 Hi, In my past work I am familiar with using the Rational tools and for Requirements Management we used Req Pro. I have heard of but am not familiar with Doors. Now with a new open source project on the horizon I would either build, but preferably find a tool to do the following: 1) Uniquely identify, categorize and detailed low level functional requirements. 2) Embed the requirement ids in comments in the source code. 3) Create a suite of test cases for all requirements. 4) Generate reports of untested requirements or not yet implemented. I suppose one might like to have a trace to a design - modules or subsystems but I havent found that a worthy step - since the design is a generalization of the implementation. Req pro did not seem particularly complex - so it is tempting to build a database driven tool - skipping the MS Word piece - instead generating xml/html from the database of requirements. What is everyone else that is not purchasing tools using - if it matters the rest of the project uses Eclipse and JBoss. thanks Tim
From: Phlip on 2 Jan 2006 14:53 timasmith wrote: > In my past work I am familiar with using the Rational tools and for > Requirements Management we used Req Pro. I have heard of but am not > familiar with Doors. > > Now with a new open source project on the horizon I would either build, > but preferably find a tool to do the following: > > 1) Uniquely identify, categorize and detailed low level functional > requirements. > 2) Embed the requirement ids in comments in the source code. > 3) Create a suite of test cases for all requirements. > 4) Generate reports of untested requirements or not yet implemented. Suppose you write failing test cases before you write any new code that passes the tests. This forces all your code to have test cases. Now annotate each test case with the name of the feature it resolves. From here, if you put any 'assert(false)' in any code, and run all the tests, the list of tests that fail is the list of features which that line of code supports. The more, the better. This shows your code is tight. -- Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
From: David Lightstone on 2 Jan 2006 17:16 <timasmith(a)hotmail.com> wrote in message news:1136229415.216435.44720(a)g44g2000cwa.googlegroups.com... > Hi, > > In my past work I am familiar with using the Rational tools and for > Requirements Management we used Req Pro. I have heard of but am not > familiar with Doors. > > Now with a new open source project on the horizon I would either build, > but preferably find a tool to do the following: > > 1) Uniquely identify, categorize and detailed low level functional > requirements. > 2) Embed the requirement ids in comments in the source code. > 3) Create a suite of test cases for all requirements. > 4) Generate reports of untested requirements or not yet implemented. You might want to think very carefully about your work process first. Which, if any, of these 4 have you done using Requisite Pro? > > I suppose one might like to have a trace to a design - modules or > subsystems but I havent found that a worthy step - since the design is > a generalization of the implementation. > > Req pro did not seem particularly complex - so it is tempting to build > a database driven tool - skipping the MS Word piece - instead > generating xml/html from the database of requirements. It is more difficult than you think. How do you plan to validate the "database" for completeness and consistency? > > What is everyone else that is not purchasing tools using - if it > matters the rest of the project uses Eclipse and JBoss. Word and Access > > thanks > > Tim >
From: timasmith on 2 Jan 2006 19:37 Phlip wrote: <snip> > Suppose you write failing test cases before you write any new code that > passes the tests. This forces all your code to have test cases. > > Now annotate each test case with the name of the feature it resolves. > > From here, if you put any 'assert(false)' in any code, and run all the > tests, the list of tests that fail is the list of features which that line > of code supports. > > The more, the better. This shows your code is tight. > > -- > Phlip > http://www.greencheese.org/ZeekLand <-- NOT a blog!!! I do like the concept of failing a method will highlight tests/features that you wrote tests for. However you cannot possibly write all test cases for a large system - the number of possibilities would be almost endless. Also this only tells you what you have coded - not what you have yet to code. And finally analysts work with end users to manage requirements - having them annotate code is not going to work as a communication tool to developers.
From: timasmith on 2 Jan 2006 19:43
With Req Pro I have done all 4 - I imported source code into Req Pro and marked up the methods which mapped to requirements. Of course it is impossible to maintain but was useful to provide a one time coverage analysis and later to direct new developers to where some of the requirements could be found in the code. Not sure what you mean about validating the database - by having a simple table of requirements it is complete and consistent - as long as you break down requirements into individual entitities and only use the database - not fully realistic but useful for most of the functional requirements. Ok I will use Access, my one table - and auto generate HTML documents from it - rudimentary but will do for now. |