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

  • Replies 5 replies
  • Subscribers 19 subscribers
  • Views 121 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

  • I have recently retired.  My former employer had software engineers, hardware engineers, mechanical engineers and systems engineers.  Amongst other things, the systems engineers were there to look at the requirements as a whole and ensure that they were correctly allocated to the different disciplines.  It was common that a single system requirement would map to sub-system requirements on several different disciplines.

    I'm not sure how it would work to split things by logical/functional methodology.  You still need to know if it's a bit of software or implemented in electronics.

Reply

  • I have recently retired.  My former employer had software engineers, hardware engineers, mechanical engineers and systems engineers.  Amongst other things, the systems engineers were there to look at the requirements as a whole and ensure that they were correctly allocated to the different disciplines.  It was common that a single system requirement would map to sub-system requirements on several different disciplines.

    I'm not sure how it would work to split things by logical/functional methodology.  You still need to know if it's a bit of software or implemented in electronics.

Children
  • in reply to Simon Barker

    The role of 'integration lead' is a real one, and needs a real budget. This person is the one making sure the various teams agree on sensible interfaces while not worrying about the contents of the different bits that need to be interfaced. 'system engineering' if you like.

    Like 'right first time' hardware, 'integrates first time' projects that are larger than a team co-located in a lock-up  garage are up there in occurrence with teeth for hens, unicorn hairs and rocking horse manure... or maybe I've been lucky ! 

    Like it or not some folk seem unhappy to grasp more than the part they are working on, and prefer to see the project through a letter-box. 

    Co-location into 'project team rooms' helps, but only if folk actually talk to each other to the right degree. Too much and no work occurs, too little and piles of square pegs are made for round holes.
    Mike.

Community Rules & Guidelines