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

  • Replies 25 replies
  • Subscribers 20 subscribers
  • Views 658 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

  • in reply to Mark Tickner

    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

  • 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.

Reply
  • 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.

Children
No Data

Community Rules & Guidelines