Rules and Guidelines
Want to participate in the discussions? Please read our Community Rules and Guidelines. Need some help? Visit Support and Answers.

  • Replies 28 replies
  • Subscribers 20 subscribers
  • Views 681 views
  • Users 0 members are here
Options
You may also be interested in

Requirement Structuring

Mark Tickner

A coffee break question?

I have a legacy requirements set, the requirements have been structured in alignment with disciplines (software, hardware, mechanical, etc). The project work breakdown structure has a similar pattern. It should be noted that there are multiple parts that come together to form the whole system and those parts are not necessarily the product of a single team.

The issue I take here is 1) it has a risk of siloed working 2) it's not aligned to the integration of the system components 3) I'm pretty sure there are missing requirements relating to interfaces and integration

My preference would be to stucture along a more logical/functional methodology. However, I need to get buy-in for the change.

I won't be able to actually change the legacy system, but the intent is to make reuse and leverage of requirements for future projects and I want to set up that stucture. I also doubt I'll be able to change the Work Breakdown Structure.

I would be interested in views to the matter on the pro's and con's of the various approaches.

Assume this is a reasonably complex product with a multidisciplinary team working on it.

Many Thanks in Advance

Mark

Parents

  • 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 reply to Joseph Kasser

    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.

  • in reply to Mark Tickner

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

Reply Children
  • in reply to Joseph Kasser

    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.

  • in reply to Mark Tickner
    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.

  • in reply to Philip Oakley

    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.

  • in reply to Andy Millar
    Andy Millar said:
    but there were just to many interactions to consider in the processes that were used

    Very much the "Crappers brainfull" analogy of Prof Hitchins (INCOSE & IEE, as was), whereby Mrs. Thomas Crapper (of flush toilet fame) was said to the last person to be able to understand all the elements of a complete system (all rather apocryphal, but very relatable). Reference somewhere in an IEE conference proceedings up in my loft...

  • in reply to Philip Oakley

    A direct reference to Hitchin's "Crapper's Brainfull"

Community Rules & Guidelines