Opportunity Options Planning Architecture Build Ready Deploy

Activities

Modelling
Requirements
Design
Engineering
Testing
Deploying
Configuration
Project Management
Design Activity

The goal is to analyze the requirements for the system and to design a solution to be implemented, taking into consideration the requirements, constraints and all applicable standards and guidelines. Critical activities include:

  • Formulating, and then defining, an architecture for a system
  • Constructing a proof-of-concept, where appropriate, to validate an architecture
  • Understanding (analyzing) the requirements for the system
  • Design of components, services, and/or modules
  • Network, user interface, and database design

The design activity focuses on the following:

  • Evaluating and selecting solutions (sometimes referred to as "design approaches," "design concepts," or "preliminary designs") that potentially satisfy an appropriate set of allocated requirements
  • Developing detailed designs for the selected solutions (detailed in the context of containing all the information needed to manufacture, code, or carry out the design as a product or product component)

It can start before all requirements are finalised and is often best performed as an iterative activity in conjunction with developing requirements. Some level of design, at times fairly detailed, may be needed to select a design solution. Prototypes may also be used as a means of gaining sufficient knowledge to develop a complete set of requirements.

Alternative solutions and their relative merits should be considered before selecting a final solution. The aim should be to keep it simple (though the effort to come up with a simple solution may be high). One indicator of a good design is that the design was chosen after comparing and evaluating it against alternative solutions.

Alternative solutions are not only different ways of addressing the same requirements, but may also cover different grouping of requirements into components for the solution. The objective is to optimize the solution as a whole and not the individual components.

Considerations for detailed alternative solutions and selection criteria include the following:

  • Cost (development, procurement, support, product life cycle)
  • Technical performance
  • Complexity of the product component and product-related life-cycle processes
  • Robustness to product operating and use conditions, operating modes, environments, and variations in product-related life-cycle processes
  • Product expansion and growth
  • Technology limitations
  • Sensitivity to construction methods and materials
  • Risk
  • Evolution of requirements and technology
  • Disposal
  • Capabilities and limitations of end users and operators

The criteria used in selection of the final solution should provide a balanced approach to costs, benefits, and risks. Support considerations should also be included.

Design activities include:

  • Establishing the component structure and rules for interfaces between components
  • Identifying major internal interfaces and all external interfaces
  • Identifying software product components
  • Establishing infrastructure capabilities and services

Examples of techniques and methods that facilitate effective design include the following:

  • Prototypes
  • Structural models
  • Object-oriented design
  • Entity relationship models
  • Design reuse

The design is recorded in a technical specification that is created during preliminary design to document the architecture definition. This technical specification is maintained throughout the life of the product to record essential details of the product design. The technical specification provides the description of a product or product component It includes all applicable technical data such as drawings, associated lists, specifications, design descriptions, design databases, standards, performance requirements, quality assurance provisions, and packaging details.

A technical specification should include the following

  • Product architecture description
  • Allocated requirements
  • Product-component descriptions
  • Interface requirements
  • Rationale for decisions and characteristics (requirements, requirement allocations, and design choices)

Verifying the design

Verifications are performed throughout design in order to evaluate the suitability of the architecture for its intended purpose. Verification is checking we have got all the details right.

Questions answered here are:

  • Does the design meet the requirements?
  • Does it conform to all our security, architectural and other standards?
  • Is the design simple and optimal (expert review)?
  • Is it going to work?

Verification is a very important activity, in that it substantially increases the likelihood that the design will meet the customerís requirements.

Peer reviews are an important part of verification and are well proven for effective defect removal early in the development cycle. Peer reviews involve a methodical examination of work products by the producers' peers to identify defects and other changes that are needed.

Examples of verification methods include the following:

  • Inspections
  • Structured walkthroughs
  • Audits
  • Simulations
  • Demonstrations

Checking what you propose to do against the customerís requirements is essential. This is to make sure you have not either misinterpreted what is needed, or that you have not missed anything. Verification is an important quality step that is often overlooked in the excitement to get on and build something. It is not enough that you think you know what the standards are; you need to check against them and confirm that the solution is compliant.

The design should be approved. For medium and large projects this may be done formally as part of the adopted methodology and quality plan. For these projects:

  • Architectural design needs to be verified and approved by the architecture board.
  • Business Analysis walkthrough techniques can be used to approve the design against the confirmed requirements.

For small projects this may be done more informally but still requires approval from the assigned technical architect and evidence that the design has been checked against the confirmed requirements.