Rules: Design Specification

Tag: Rules.DS. Version: October 7, 2004. Owner: TG. Status: Draft.

Note: Design specifications are either for optional design ideas (possible solutions) or required design constraints (that is, actualrequirements AND consequently, pre-selected solutions).

Base: The rules for generic specification, Rules.GS apply. If the design idea is a design constraint (a requirement), the rules forrequirement specification, Rules.RS also apply.

R1: Design Separation: Only design ideas that are intentionally ‘constraints’ (Type: Design Constraint) are specified in the requirements. Any other design ideas are specified separately (Type: Design Idea). Note all the design ideas specified as requirements should be explicitly identified as ‘Design Constraints.’

R2: Detail: A design specification should be specified in enough detail so that we know precisely what is expected, and do not, and cannot, inadvertently assume or include design elements, which are not actually intended. It should be 'foolproof'. For complex designs, the detailed definition of its sub-designs can satisfy this need for clarity, the high level design description does not need to hold all the detail.

R3: Explode: Any design idea, whose impact on attributes can be better controlled by detailing it, should be broken down into a list of the tag names of its elementary and/or complex sub-design ideas. Use the parameter ‘Definition’ for Sub-Designs. If you know it can be decomposed; but don't want to decompose it just now, at least explicitly indicate the potential of such a breakdown. Use a Comment or Note parameter.

R4: Dependencies: Any known dependencies for successful implementation of a design idea need to be specified explicitly. Nothing should be assumed to be ‘obvious’. Use the parameter, Dependency (or Depends On), or other suitable notation such as [qualifiers].

R5: Impacts: For each design idea, specify at least one main performance attribute impacted by it. Use an impact arrow ‘->’ or the Impacts parameter. Comment: At early stages of design specification, you are just establishing that the design idea has some relevance to meeting your requirements. Later, an IE table can be used to establish the performance to cost ratio and/or the value to cost ratio of each design idea.

R6: Side Effects: Document in the design specification any side effects of the design idea (on defined requirements or other specified potential design ideas) that you expect or fear. Do this using explicit parameters, such as Risks, Impacts [Side Effect] and Assumptions.

Do not assume others will know, suspect or bother to deal with risks, side effects and assumptions. Do it yourself. Understanding potential side effects is a sign of your system engineering competence and maturity. Don’t be shy!

R7: Background Information: Capture the Background information for any estimated or actual impact of a design idea on a performance/cost attribute. The evidence supporting the impact, the level of uncertainty (the error margins), the level of credibility of any information and, the source(s) for all this information should be given as far as possible. For example, state a previous project’s experience of using the design idea. Use Evidence, Uncertainty, Credibility, and Source parameters. Note the source icon (<-) usually represents the Source parameter. Comment: This helps ‘ground’ opinions on how the design ideas contribute to meeting the requirements. It is also preparation for filling out an IE table.

R8: IE Table: The set of design ideas specified to meet a set of requirements should be validated at an early stage by using an Impact Estimation (IE) table.

Does the selected set of design ideas produce a good enough set of expected attributes, with respect to all requirements and any other proposed design ideas? Use an IE table as a working tool when specifying design ideas and also, when performing quality control or design reviews on design idea specifications.

R9: Constraints: No single design specification, or set of design specifications cumulatively, can violate any specified constraint. If there is any risk that this might occur the system engineer will give a suitable warning signal. Use the Risk or Issues parameters, for example.

R10: Rejected Designs: A design idea may be declared ‘rejected’ for any number of reasons. It should be retained in the design documentation or database, with information showing that it was rejected, and also, why it was rejected and by whom.

Explicit Risk Specification: All managers/planners/engineers/testers/quality assurance people shall specify any uncertainty, and any special conditions, which can imaginably lead to a risk of deviation from defined target levels of system performance. This must be done at the earliest opportunity in writing, and integrated into the main plan.

Numeric Expectation Specification: The expected levels of all quality and cost attributes of the system shall be specified in a numeric way, using defined scales of measure, and at least an outline of one or more appropriate ‘meters’ (that is, a proposed test or measuring instrument for determining where we are on a scale).

Conditions Specified: The requirements levels shall be qualified with regard to when, where and under which conditions the targets apply, so there is no risk of us inadvertently applying them inappropriately.

Complete Requirement Specification: A complete set of all critical performance and cost aspects shall be specified, avoiding the risk of failing to consider a single critical attribute.

Complete Design Specification and Impact Estimation: A complete set of designs or strategies for meeting the complete set of performance and cost targets will be specified. They will be validated against all specified performance and cost targets (using Impact Estimation Tables). They will meet a reasonable level of safety margin. They will then be evolutionarily validated in practice before major investment is made. The Evo steps will be made at a rate of maximum 2% of total project budget, and 2% of total project timescales, per increment (Evo step) of designs or strategies.

Specification Quality Control, Numerically Exited: All requirements, design, impact estimation and evolutionary project plans, as well as all other related critical documents, such as contracts, management plans, contract modifications, marketing plans, shall be ‘quality controlled’ using the Inspection method (Gilb 1993). A normal process exit level shall be that ‘no more than 0.2 maximum probable major defects per page can be calculated to remain, as a function of those found and fixed before release, when checking is done properly’ (that is, at optimum checking rates of 1 logical page or less per hour).

Evolutionary Proof of Concept Priorities: The Evolutionary Project Management method will be used to sense and control risk in mid-project. Dominant features will include:

• • 2% (of budget and time-to-deadline) steps;

• • High value-to-cost steps, with regard to risk, prioritized asap;

• • High risk strategies tested ‘offline to customer delivery’, in the ‘backroom’ of the development process, or at cost-to-vendor, or with ‘research funds’ as opposed to using the official project budget.