Re: [topicmaps-comment] Topic Maps for Requirements Management?

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Thomas B. Passin
|
| I'm considering potential benefits of using Topic Maps for
| requirements traceability, and would like anyone's opinions on this.

I think this is a very interesting usage area for topic maps, and I
think you analysis is good, as far as it goes. A very interesting
benefit of having your requirements as a topic map is that you can
then connect your design documents, your source code, your bugs, your
documentation, and other information with it.

This, BTW, is one of the things StarBase is working on in their Elmer
project, which they presented at XML 2001 in Orlando. 
(<URL: http://www.starbase.com >)

| How many requirements could be handled in practice? [...]

I think that most likely you will hit organizational limits before you
hit technical limits (provided you use a database approach, of course).

| (For example, you don't need more than one name for a topic - I
| think - and you don't need the full generality of subject
| indicators.  These two points alone allow significant
| simplification.)

Actually, I'm very much unconvinced that this is the case. You may not
need processing instructions, notation declarations, or unparsed
entities in most XML projects, but you still use general XML software
that implements them. I would think the same makes sense in topic
maps.

(More than one name on topics is *very* useful, BTW, probably also in
this application.)
 
| Does anyone have any real information on other kinds of
| implementations that could handle the larger sizes?  

I would expect all the commercial topic map implementations to be able
to handle those.

| How much memory might a map with say 20,000 topics with maybe 4
| occurrences each, and 20,000 associations, take up if it were
| in-memory in a topic map engine (very uncertain, I know, but do you
| think we might be talking about say 5 MB vs 500 MB here?)?

I would guess somewhere between 50 MB and 100 MB in Java. So you could
keep it in-memory if you wanted, but if it could grow you would want
to use a database. In fact, you'd probably want to do that anyway, for
reasons of concurrency management.

--Lars M.