OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


I'm considering potential benefits of using Topic Maps for requirements
traceability, and would like anyone's opinions on this.  Topic maps could be
a good fit, I think.  At first, the explosion from top level requirements
down to detailed specs and then to tests and test results seems hierarchical
and thereby perhaps less suited to topic maps, but in reality, each step of
the explosion generally involves sets, not ordered lists, and those are very
suited to being represented by associations.

Topic maps would let you form all kinds of groupings, temporary or
otherwise, for tracking purposes, and that should be a big benefit.  You
could also add any kind of annotation without having to change a rigid
database schema.  Other potential benefits would be the ability to export in
a standard format that could be used by other tools, and the ability to have
built-in semantics for various relationships, roles, etc.

How many requirements could be handled in practice?  I'm not clear what the
potential users here might need (one possible project would probably be
relatively small, less than one thousand requirements and spec items, but
another could get quite large, several tens of thousands at least).  As I
see it, for requirements traceability you don't need everything in the topic
map model, and the subset that you do need could be implemented in a
relational database pretty nicely.  That would be one way to get some decent
scalability and data management.

(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.)

Does anyone have any real information on other kinds of implementations that
could handle the larger sizes?   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?)?

Anyone like to tackle pros and cons when compared with that defacto
standard, DOORS?

Cheers,

Tom P



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC