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

  • Don't.

    Do add-in budgeting for the extra interface, integration and reporting steps [they are not 'problems']. Be 'honest' about the reality of the delays in resolving the test issue as they go up and down the hierarchy chains, and the extra cross function roles/staff needed. 

    On one level, make it 'not your problem'. However, within that budget exercise, quietly flesh-out the alternate structure and system V diagrams.

    This allows the 'management' to own the issues (again not a 'problem'), such that you can then buy into their solution which, hopefully, has extracted your nascent, poorly hidden ideas. 

    In addition make sure that your problem actually matters. You may find that the whole project is marching to a different drum that no amount of local efficiency is going affect. There maybe a major platform aspect that is driving the overall project and the hierarchy is a response to the herding cats aspects of such projects. 

    Pick your battles carefully. Stupidity [nobody knows the whole system] is to be managed, not eliminated. Ensure you have tolerances for [alleged] exact calculations (e.g. stochastic vs ergodic statistics). Learn from the mistakes of others, rather than ...]

     Remember Box's aphorism, misquoted : All interfaces are wrong, some are useful Grin.

    My experience was in military electro optic systems which cuts across the lot.

Reply

  • Don't.

    Do add-in budgeting for the extra interface, integration and reporting steps [they are not 'problems']. Be 'honest' about the reality of the delays in resolving the test issue as they go up and down the hierarchy chains, and the extra cross function roles/staff needed. 

    On one level, make it 'not your problem'. However, within that budget exercise, quietly flesh-out the alternate structure and system V diagrams.

    This allows the 'management' to own the issues (again not a 'problem'), such that you can then buy into their solution which, hopefully, has extracted your nascent, poorly hidden ideas. 

    In addition make sure that your problem actually matters. You may find that the whole project is marching to a different drum that no amount of local efficiency is going affect. There maybe a major platform aspect that is driving the overall project and the hierarchy is a response to the herding cats aspects of such projects. 

    Pick your battles carefully. Stupidity [nobody knows the whole system] is to be managed, not eliminated. Ensure you have tolerances for [alleged] exact calculations (e.g. stochastic vs ergodic statistics). Learn from the mistakes of others, rather than ...]

     Remember Box's aphorism, misquoted : All interfaces are wrong, some are useful Grin.

    My experience was in military electro optic systems which cuts across the lot.

Children
No Data

Community Rules & Guidelines