Design Rules for NBD – Network Based Defence Development Status: [Identified, Draft, Proposal, Verified, Rejected, Obsolete] Validity for each referenced DR: [Normative, Descriptive, Emerging] Problem Context Solution Requirements Meta data DRP Product VDD Domain DR and DRP references Status Identifier DR References Validity = Descriptive 0..n Verification Method Result Analysis DR Consequence DR product Version Date 1 +Owner +Refers Each association between DR:s configured in different DRP:s must also have a corresponding dependency between the involved DRP:s. 1..n Design Rules for NBD – Network Based Defence

Definition A design rule is a solution to a problem in a specific context with at least one of the following properties (why’s): make design NBD compliant solve frequently shown problems be part of the corporate memory (solutions to difficult problems) improve quality

Characteristics Packages knowledge in a re-usable form Provides a way of standardizing the solutions to design problems within NBD May solve both high and low level problems. Value to the re-user is the most important aspect Belongs to a design rule package – i.e. a problem domain

Development Conditions When: Problems specific to NBD When not: Simple problems Problems where established solutions already exist and are used A unique problem which is not likely to occur again

Relationships Design Rules Methods Architectural Frameworks prescribes frameworks Architectural Frameworks Technical Design Rules Harvest from design Improvements from design Uses Methods Design Uses Design rules Uses Methods

Rejection can appear anywhere Design Rule Life Cycle Improvement proposals Candidate Harvesting, ideas etc. Development In use Phase out Obsolete status Identified Draft Proposed Verified Rejection can appear anywhere in the maturing chain

The Formal Design Rule Model Problem domain Not part of the DR product. THE design rule Refered DR is mandatory or recommended

Design Rule Template Outline overview General Unique Identity Status Target Group . Description Context Problem Solution Motivation Consequences Meta Data Appendix with Rejected Solutions Status

Design Rule Product Structure Design Rule Package Product e.g. Information Management Design Rule Package products keeps structural and version (release) information. Design Rule Package Product e.g. Information Quality Abstraction level Design Rule Product Description: Context Problem Solution Other artifacts: Consequences Analysis Verification info Design Rule products are always leafs in the structure Relations to other DRs needed for the solution. Validity [Normative, Descriptive, Emerging] is always an relation parameter.

Example of a relation between Design Rules communication System Configuration Infrastructure Policies Architecture Convergence Plane Policy A Descriptive Control Plane Policy B ... ... .... Normative Security Mechanisms ...

Use of Technical Design Rules Example Security Applications Service Implementation Information Management Technical Administration Communication MSI System Configuration Policies Mainy composite design rules Associations Basic Systems Mainly singular design rules Rules for a system to develop: Appropriate design rule for a Basic System product Policy design rule product governed by the environment of use. e.g. a C3I for a FHQ