I’d like to know if there is any decision-oriented guidance for knowing the “time window” when it’s optimal to start this functional decomposition? I ask this question having seen the following anecdote:

““There are times when non-architects prematurely make major architectural decisions. For example, multiple contracts or subcontracts may be let based on organizational expertise, rational decomposition structures, project schedule and other reasons before the requirements and resulting overall system architecture have been adequately engineered. This can result in a suboptimal top-level system decomposition that is almost impossible to change.” [p.83]
Firesmith, Donald G. et al (2008), “The Method Framework for Engineering System Architectures”, Auerbach Publications, USA.

BRgds,
Trevor.

I have created a series of intense historical role playing games – imagine getting sucked into a illustrated history – “coffee table book” that you have to work your way through to get out. While eventually these games can be produced in computer versions, my first foray will use the traditional board game delivery system. As product road maps are usually associated with technology (correct me if I am wrong), what is the equvalent of a road map for someone in my situation?

Any advice would be very much appreciated

R.G. Guber

It was a surprise and a great pleasure to discover your website. To find such logically sound and clearly explained concepts in the area of decision making is unusual. I consult and teach worldwide in systems engineering. The proportion of engineers who understand decision making is miniscule, and yet, decision making is their professional role in life.

Thank you for a reat website to which I can refer others.

Kind regards
Robert

Requirement-to-requirement traceability really is a flawed (unscientific) concept except in the trivial case in which a higher-level requirement is simply allocated without change to a lower-level component.

DAR at least references the fact that criteria should be traceable to requirements, but leaves out the second half of the traceability paradigm, that derived requirements (inherent consequences, constraints that flow from the selected alternative) should be captured and communicated to the requirements baseline before the decision analysis is deemed to be complete.

I’ve been to over 50+ companies that are somewhere on a CMMI journey and have yet to have a single one who maintained any decision-requirement traceability until I explained the science of requirements derivation to them. There’s no reason to leave this ambiguity in CMMI; to leave the practice unchanged is akin to continuing to recommend trepanation let the evil spirits escape when treating epilepsy. If your doctor did that today you’d sue him/her for malpractice.

Picking a nit with CMMI over traceability, however, may prove to be limiting to your argument since the practice doesn’t *require* that traceability be limited only to requirements. In fact,
(a) even as written, Specific Practice 1.4 discusses both traceability among requirements as well as work products resulting from or contributing to requirements, and
(b) nothing in the practice says that traceability not be maintained from/to decisions.

Furthermore, CMMI has an entire process area called “Decision Analysis and Resolution”, which when used properly, could easily and appropriately generate the sort of artifacts of decisions that would lend themselves to being traced to or from requirements. Your argument is actually a strong one for why CMMI should be consumed holistically rather than piecemeal, as many others do.

Last note: Keep in mind, CMMI does not provide a process for managing requirements, but merely a handful of practices that would improve how requirements are managed. In this light, the practice for maintaining traceability should not be interpreted as what to maintain traceability to, or how to maintain traceability, rather as what benefits to product development and project management can be derived from maintaining traceability. In your argument, maintaining traceability to decisions is precisely the sort of thing organizations who understand the value of maintaining traceability would and ought to do! Interpreting CMMI REQM SP1.4 in such a way that only maintains traceability to/among requirements would easily leave large gaping holes in the collective understanding of the eventual product.

Nice work!

Thanks for this great post on entrepreneurial tips. I’ve included this link on my blog: http://entrepreneur.northstarthinktank.com/business/out_do_the_competition.

Thanks again, and keep up the good work!

Jeff

This is an excellent and unique article. I am interested in republishing some of your articles on PM Hut. Please contact me through the “Contact Us” form of the PM Hut site in case you’re OK with this.

Thanks!