Comments (3)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 KeithCollyer commented Permalink

Excellent post. As usual, Jeremy explains very well first why some things that might seem obvious are not, and then how to deal with the implications of this and make them manageable.

2 CeesMichielsen commented Permalink

Hi Jeremy, thank you for this interesting article. <br /> I recognize the issues you encounter when trying to "decompose" requirements. The solution you describe does however not do justice to the product engineering practice of today. I fully agree with the four steps you describe for the development of requirements. I do not entirely agree with your implementation. In my opinion the decisions one takes based on several design options must be part of the requirements trace. Without exception. Requirements are not derived from other requirements, but from the design decisions. Therefor, linking requirements to one another results in losing the crucial design information that justifies not only the existence of the derived requirements, but also results in losing the justification that the derived requirements are indeed a a complete set of requirements to fulfill the requirement(s) that the design was created for. <br /> If you do not include the design decisions in the trace it becomes impossible to determine whether you are fully satisfying the requirements at lower abstraction levels. <br /> As you know, dealing with multi-objective projects is very common in systems engineering. Making decisions explicit and therefor making the traceability transparent is a fundamental part of this. Adding design decisions to the diagrams of trace views would be a tremendous step forward. <br /> By ignoring the outcome of the design process (which you actually suggest doing when representing requirements only in a multi-level structure), you hamper multi-discipline product development. Talking from the systems engineering background I think we should ban diagrams, methods, tools, and guidelines that suggest that there exists a requirements structure without explicitly positioning the design decisions. <br /> I hope our discussion will take requirements engineering (as part of systems engineering) a step further. <br /> Regards, Cees.

3 gbjedi commented Permalink

Thanks for your excellent comments. Of course you are right that, in the ideal, design options should be recorded as alternative flow-down structures. The challenge in achieving culture change, though, it is to choose your battles. In our recent project, we are already asking engineers to take on board a host of new practices, and it is as much as we can to persuade them to document the decomposition of requirements for the chosen design. We have decided to let them do their optioneering outside of the requirements structure, and just to record the selected design in the requirements decomposition. Although we are missing out on a host of information about design choices, the approach still improves their ability to carry impact analysis. <br /> Years ago when at QSS I did some work with a DOORS customisation called DecisionLink, which was an approach to tracing design decisions into the requirements structures. In practice, most users found that the added complexity outweighed the benefits, mainly because different choices tended to have very dramatic effects on the whole requirements structure. <br /> More recently, however, I have done some work integrating QFD House Of Quality diagrams with requirements in DOORS, and that may be a more practical approach to addressing this need.