Requirement Structuring

Those requirements were set a while ago. Should the system be upgraded they will probably be out of date. So I suggest you leave them alone but store them where they could be used in the future as a legacy input to a future conceptual model should the system be upgraded.

In terms of project lifecycles, the "donor" project is right at the start of its lifecycle - so its requirements are actively being changed and updated as the design develops. Not so much out of date, more, immature currently.

However, its the structuring of those requirements that I'm questioning here.

if the requirements ae in a database, that is the purpose of keywords

I now tend to separate Requirements from Specifications - it took me decades to understand the distinction. 

The ideal Requirement is a narrative, without numeric limits.

Meanwhile the consequent Specification is all about setting the testable numeric limits for blind testing of the product or it's sub-system in a test environment.

There are very few cases where the narrative requirement is actually achieved: E.g. President Kennedy's "landing a man on the Moon and returning him safely to the Earth before this decade is out", (old now) Quantel Paintbox drawing software "the capability of an HB pencil", and Steve Jobs mouse pointer to operate on "a pair of jeans" (maybe apocryphal).

Also noted is that the functional technical performance often fits within three quarters of a page - the other 60 pages are environmental survival aspects (power provision, EMC, vibration, temperature ranges, etc.) They are all zero function requirements - input this, get out zero change. Hence the Gold Plated Brick requirements that can turn up every now and again.

Finally, given some "requirement", look at how big the pile of lower level part specifications become, all from that simple short narrative - where did all that come from? Have a look at Knowledge levels (similar to TRLs - Technology readiness levels), and the Knowledge tree.

1 Bohn, R.E.: ‘Measuring and Managing Technological Knowledge’, in ‘The Economic Impact of Knowledge’ (Elsevier, 1998), pp. 295–314,

Also as article in Sloan Management Review · January 1994 (MAM) DOI: 10.1016/B978-0-7506-7009-8.50022-7

This is of course the whole point of it being in a database.

However, if those keywords are not constrained then what you find is that people populate it with a varied selection of keywords, which may or may not align to the design and architecture. With the extreme being where different teams call the same thing by different names or acronyms.

You end up going through the database to correct all the names, because the alternative is that when you do searches or filters on the database you don't get the right data.

Personally, I always suggest that the keywords should be constrained to items shown as architecture elements or ontological elements, whichever is most relevant.

Mark Tickner said:

I always suggest that the keywords should be constrained

Though there can be a foresight bias of believing that one has completeness in the keywords, or that folk actually understand what the terms mean, include/exclude. One man's ontology is another lady's hierarchy.. Being able to update the keyword list quickly also matters..

Manoeuvring gets an honourable mention for the number of potential ways folks can re-spell it. Along with how many reference datums you can have [surely the plural of datum is data?]

The Ergodic, Stochastic and Ensemble distinctions always get me.

There's also the unintended consequence that keywords (or any similar grouping strategies) can mean that interactions between those groups get missed - when doing a modification on sub-system "A" the engineering team reasonably search for requirements on sub-system "A". But don't check the source and rationale of those requirements which means that they miss the fact that their changes inadvertently impact their interaction with subsystem "B".

In my mind it's not so much a problem with the database, it's awareness of the fact that by the time your requirement set is so big that you need a database to mange them then, by definition, the set is so big that no one person can keep a level of awareness of all the requirements and their interactions. So sort of back to the start of this thread: in those circumstances the team need to be very aware of this and be careful about letting teams work solely on sub-sets - which practically of course those teams will mostly need to. 

I'll admit that this is why I like working on small projects! And why the big fails I've seen have been on big integration projects - everyone was doing their best, but there were just to many interactions to consider in the processes that were used. As has been commented here, it's a whole area of systems engineering by itself, and my feeling is that it's an area that needs more intelligence put into it on each project than is often appreciated.

There's also the unintended consequence that keywords (or any similar grouping strategies) can mean that interactions between those groups get missed - when doing a modification on sub-system "A" the engineering team reasonably search for requirements on sub-system "A". But don't check the source and rationale of those requirements which means that they miss the fact that their changes inadvertently impact their interaction with subsystem "B".

In my mind it's not so much a problem with the database, it's awareness of the fact that by the time your requirement set is so big that you need a database to mange them then, by definition, the set is so big that no one person can keep a level of awareness of all the requirements and their interactions. So sort of back to the start of this thread: in those circumstances the team need to be very aware of this and be careful about letting teams work solely on sub-sets - which practically of course those teams will mostly need to. 

I'll admit that this is why I like working on small projects! And why the big fails I've seen have been on big integration projects - everyone was doing their best, but there were just to many interactions to consider in the processes that were used. As has been commented here, it's a whole area of systems engineering by itself, and my feeling is that it's an area that needs more intelligence put into it on each project than is often appreciated.