Security Architecture and Analysis:  Course Roadmap
Download
1 / 43

Architecture Definition & Analysis - PowerPoint PPT Presentation


  • 187 Views
  • Updated On :

Security Architecture and Analysis: Course Roadmap. Session 1 (Linger) What: Methods for defining and reasoning about system architectures. Why: The architecture level is cost-effective and intellectually manageable for analysis and design of system security and survivability capabilities. .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Architecture Definition & Analysis' - vance


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

Security Architecture and Analysis: Course Roadmap

Session 1 (Linger)

What: Methods for defining and reasoning about system architectures.

Why: The architecture level is cost-effective and intellectually manageable for analysis and design of system security and survivability capabilities.

Architecture

Definition &

Analysis

Session 2, 3a (Linger)

What: Survivability analysis improves preservation of critical mission capabilities.

Why: No amount of security can guarantee that systems will not be compromised; essential services and assets must be maintained.

Survivable

Network

Analysis

Sessions 4, 6, 7. 9, 11 (Longstaff)

What: Analysis of vulnerabilities and methods for improving system security.

Why: System security can be improved by a variety of techniques at the network, operating system, and application level.

Security

Architectures

Session 13 (Linger)

What: Architecture development with COTS components

Why: Most security vulnerabilities are the result of poor system development and acquisition practices. From a security perspective, good practices and management methods are critically important.

Architecture

Development

Management

  • Plus:

  • Student team project in survivability analysis (Mead)

  • Guest lectures on special topics

  • Student presentations


Slide2 l.jpg



Slide4 l.jpg

REVIEW: Architecture Defined

  • An information system architecture

  • is a specification for development of a system

  • composed of hardware and softwarecomponents and connectors

  • whose external behavior satisfies the enterprise mission and

  • business requirements

Enterprise mission and

business requirements

System

operation

Design

Validate

Design

System

architecture

System

development

Validate


Slide5 l.jpg

REVIEW: Concepts of System Architectures

  • Architectures are comprised of components and connectors:

  • Components (Computation)

    • Hardware:

  • Workstations, servers, mainframes, printers, sensors, actuators, …

    • Software:

  • Operating systems, data base systems, middleware,

    • browsers, applications, utilities, firewalls, ...

  • Connectors (Communication)

    • Hardware:

    • Communication links: routers, switches, public telephone

    • network, leased lines, virtual private networks, …

    • Software:

    • Communication protocols: TCP/IP, SNMP, HTTP, FTP …, Linkage

    • conventions: procedure calls, remote procedure calls, thread

    • initiation, ...


  • Slide6 l.jpg

    REVIEW: Concepts of System Architectures

    • Architecture properties:

      • Functional properties

        • Must satisfy domain-specific functional requirements

        • and specifications

      • Non-functional properties (the “ilities”)

        • Must satisfy performance, availability, reliability, safety, security, survivability, maintainability, usability, manageability, … properties

    • Architecture trade-offs:

      • Properties can conflict

      • Trade-offs seek optimal combinations of properties

      • based on cost/benefit analysis


    Slide7 l.jpg

    REVIEW: Architectural Styles

    Example: A Bank ATM System

    Style: Hierarchical, client server, layered

    Users

    Domain/Enterprise Logic/ Data Layer

    Users

    Mainframe

    ...

    Infrastructure/ Communications

    Layer

    Server

    Server

    ...

    Server

    Presentation/User Interface Layer

    ATM

    ATM

    ATM

    ...

    ATM

    ATM

    ATM

    ATM

    ...

    ATM

    ATM

    ATM

    ATM

    ...

    ATM

    Users


    Slide8 l.jpg

    REVIEW: Architectural Styles

    Gartner’s Two-Tier and Multi-Tier Enterprise Architectures:

    Plump Client

    Two Tiers

    Fat Client

    Two Tiers

    Thin Client

    Multi-tier

    Ultra-Thin Client

    Multi-tier

    Presentation

    Business Rules

    Data Access

    Presentation

    Business Rules

    Presentation

    Browser

    Desktop:

    Business Rules

    Data Access

    Business Rules

    Data Access

    DBMS

    Data Access

    DBMS

    Server(s):

    DBMS

    DBMS


    Slide9 l.jpg

    REVIEW: Architecture Impact of COTS Products

    • Long history

      • Started with environment support

        • Operating systems, data bases, language processors, …

      • Moving up the food chain

      • Specialized applications, middleware, network services, ...

    • Most architectures today are “assembled” from COTS products

      • Domain-specific vendors

      • Bend business processes to match software capabilities

      • “Glue code” ties incompatible products together

    • COTS characteristics:

      • Ties your system capability and evolution to vendors

      • Cost savings possible, but risks must be managed

      • Functionality and security are what vendor says they are

        • Actual capabilities may differ

      • Source code usually not available

      • Knowledge of quality and reliability difficult to acquire

      • Acceptance testing and configuration management are critical


    Slide10 l.jpg

    REVIEW: An Architecture Framework

    SYSTEM ARCHITECTURE

    Architecture Fundamentals:

    Architecture role and life cycle

    Architecture representation and reasoning

    Architecture processes and work products

    Architecture analysis and design

    Architecture modeling and validation

    Architecture patterns and properties

    COTS evaluation and integration

    Marketplace Environment:

    Partners and alliances

    COTS and component products

    Service and consultation offerings

    User groups and standards

    System Environment: enterprise architecture, business models, system usage and evolution

    Parts for Developing

    System Requirements: function, and properties of reliability, performance, scalability, security, usability, cost, …

    Ability to Develop

    External Behavior View (System Specification):

    User tasks and workflows

    Function and information

    Stimulus/response behavior

    Domain Architectures:

    EAI architectures

    E-commerce architectures

    Directory architectures

    System management architectures

    Middleware architectures

    Industry standard architectures

    Framework for Developing

    Architecture Best Practices:

    Enterprise modeling and requirements specification

    Application analysis and design

    Data analysis and design

    System integration

    Network analysis and design

    Incremental system development

    Data and Software View (Logical Infrastructure):

    Middleware and applications

    Databases and storage systems

    Operating systems

    Processes for Developing

    Enabling Technologies:

    Computing & comm. components

    Microsoft technologies

    JAVA technologies

    Web technologies

    XML technologies

    Security technologies

    Architecture patterns

    Development methods and tools

    Tools for Developing

    Hardware and Network View (Physical Infrastructure):

    Computing hardware: servers, mainframes, PCs,mass storage, …

    Networks, wired & wireless: media, devices, topology, protocols

    Client Environment:

    Client relations, people, and culture

    Enterprise architectures, business models, workflows, & legacy systems

    Functional, non-functional, & usage requirements and constraints

    Goals for Developing


    Slide11 l.jpg

    REVIEW: Box Structure Reasoning for Components

    • Box Structures

      • A systematic model for component analysis and design

      • Five fundamental component characteristics: “BURST”

        • Boundary: What is inside and what is outside?

        • Users: Who are the users?

        • Responses: What is the set of possible responses?

        • Stimuli: What is the set of possible stimuli?

        • Transactions: What are the possible mappings from stimuli to responses?

      • Three fundamental component representations:

        • Black box: Component behavior based on history of use

        • State Box: Component behavior based on retained data

        • Clear box: Component behavior based on procedure (another course!)


    Slide12 l.jpg

    REVIEW: Box Structure Reasoning for Components: Black Boxes

    • The black box of a component in diagram form

    Stimulus (S)

    Response (R)

    • The example of black box behavior: A hand calculator

    Stimulus history

    Stimulus

    Response

    716

    5

    7165

    716C

    5

    5

    • Black box behavior depends on more than the current stimulus,

    • it also depends on the history of use

    • Transition function of a black box description

    • (stimulus history, stimulus)  (response)


    Slide13 l.jpg

    REVIEW: Box Structure Reasoning for Components: State Boxes

    • The state box of a component in diagram form

    state

    Stimulus (S)

    Response (R)

    trans

    • Opens up a black box to reveal retained data; allows reasoning about

    • the state

    • Transition function of a state box description

      • (stimulus, current state) --> (response, new state)


    Slide14 l.jpg

    REVIEW: Compositional Reasoning for Networks

    A Bank ATM System

    Domain/Enterprise Logic/ Data Layer

    Users

    Mainframe

    ...

    Infrastructure/ Communications

    Layer

    Server

    Server

    ...

    Server

    Presentation/User Interface Layer

    ATM

    ATM

    ATM

    ...

    ATM

    ATM

    ATM

    ATM

    ...

    ATM

    ATM

    ATM

    ATM

    ...

    ATM

    Users


    Slide15 l.jpg

    REVIEW: Compositional Reasoning for Networks

    • What happens from viewpoint of ATM user submitting a transaction?

    User

    ATM

    Server

    Mainframe

    Server

    ATM

    User

    • [User] o [ATM] o [server] o [mainframe] o [server] o [ATM] o [User]

      • “o” is composition operator

      • “[, ]” denote the transition function of the component

      • Note that each use of a component is in the composition

    • Component compositions are also known as architecture traces

    • ATM Security: Composition with wrong pin number (U for user)

    U

    U

    U

    U

    U

    U

    U

    U

    ATM

    Server

    ATM

    Server

    ATM

    Server

    ATM

    Try

    again

    wrong

    pin

    Try

    again

    wrong

    pin

    Access

    denied


    Slide16 l.jpg

    REVIEW: Compositional Reasoning for Networks

    • Another pin number composition

    U

    U

    U

    Server

    ATM

    right

    pin

    Access

    granted

    U

    U

    U

    U

    U

    U

    U

    U

    ATM

    Server

    ATM

    Server

    ATM

    Server

    ATM

    wrong

    pin

    Try

    again

    wrong

    pin

    Try

    again

    wrong

    pin

    Access

    denied

    • Compositional reasoning is concerned with the net effect of

    • all the components in a composition

    • Net effect means the overall change

      • From the stimuli to the first component

      • To the response from the last component


    Slide17 l.jpg

    REVIEW: Compositional Reasoning for Networks

    When you buy gas at a pump with a speedpass, what is a possible architecture trace of your transaction?

    ?

    User

    pump

    pump

    User

    Despite the fact that thousands of users may be accessing the system at the same time, the system is designed to maintain the compositional integrity of the architecture traces of all the users. It appears to you as though you are the only user.


    Slide18 l.jpg

    REVIEW: Compositional Reasoning for Networks

    A Bank ATM System

    Users

    Mainframe

    ...

    Server

    Server

    ...

    Server

    ATM

    ATM

    ATM

    ...

    ATM

    ATM

    ATM

    ATM

    ...

    ATM

    ATM

    ATM

    ATM

    ...

    ATM

    Users

    • Many systems are designed to preserve composition and isolate

    • asynchronous behavior

    • Bank system preserves independence of transactions based on

    • account numbers

    • In general, systems are designed for compositional operations



    Slide20 l.jpg

    Architecture Life Cycle: Inputs

    INPUTS

    Architecture Fundamentals

    Architecture Practices

    Client Environment: enterprise arch. legacy systems initial requirements

    Marketplace Environment

    Domain Architectures

    Enabling Technologies


    Slide21 l.jpg

    Architecture Life Cycle: Inputs: Enterprise Architecture Def’n

    • If it exists and is current

      • May define business models

      • May define IT infrastructure

      • May define evolutionary objectives

      • May provide guidance for architecture development

    • If it exists and is not current

      • Opportunity to update

      • Guidance is suspect

    Perspective

    Know the status of enterprise architecture definition

    Analyze existing enterprise architecture IT infrastructure

    Evaluate requirements wrt existing infrastructure


    Slide22 l.jpg

    Architecture Life Cycle: Inputs: Legacy systems Def’n

    • Legacy reuse and integration

      • Data, software, and networks involved

      • Potential major costs or savings

      • Impacts architecture, development, & deployment

    • Many alternatives possible

      • Wrapping, rewriting, transforming, rehosting, …

    • Decision making

      • Legacy systems are often difficult to modernize

      • Assessment of legacy capabilities is crucial

      • Business valuation of legacy assets

        is crucial

      • New uses for old data

      • Business case, cost/benefit analysis

    Perspective

    Analyze legacy capabilities wrt client requirements

    Understand evolution plans for legacy assets

    Treat legacy integration on a par with new components

    Architect for firm future uses of legacy elements


    Slide23 l.jpg

    Architecture Life Cycle: Inputs: Initial Requirements Def’n

    • Often not fully known by client

      • Effective requirements discovery is essential

      • Enterprise and business models are the basis

    • Functional requirements

      • User tasks and workflows

      • System services and transactions

      • Use cases are a popular method

    • Usage requirements

      • User types and roles

      • Usage patterns and traffic levels

    • Non-functional (property) requirements

      • Reliability, performance, scalability,

        security, survivability, usability, cost, …

    Perspective

    Never architect against presumed requirements

    Avoid late-life-cycle requirements surprises

    Iterate requirements definition with clients

    Involve all client roles and stakeholders

    Treat requirements as an architecture entry condition

    Develop prototypes to elicit requirements from clients

    Establish requirements baselines to manage change and prevent scope creep


    Slide24 l.jpg

    Architecture Life Cycle: Inputs: Marketplace Environment Def’n

    • Partners and alliances

      • Partnering can reduce costs and spread risk

    • COTS products

      • Extensive, comprehensive capabilities available

      • Vendor capability and track record can be issues

      • Product function and quality can be issues

      • Trend to standard, integrated solutions

    • User groups and standards

      • Provide experience benchmark,

        enable interoperability

    Perspective

    Capitalize on alliance strategies and agreements

    Perform due diligence assessments of vendors

    Evaluate function and quality of COTS products

    Reconcile COTS capabilities with client requirements

    Recognize COTS selections tie clients to supply chains

    Capitalize on accepted standards, avoid others


    Slide25 l.jpg

    Architecture Life Cycle: Inputs: Domain Architectures Def’n

    • EAI architectures

      • Data-, application-, portal-, process-oriented, …

      • XML, middleware, RPCs, message brokers, …

      • Packages: SAP, PeopleSoft, BizTalk, …

    • E-commerce architectures

      • B2C, B2B, B2G, G2C…

      • Content, payments, orders, fulfillment, …

      • Security, trust, privacy, QoS…

      • Packages, ISPs, …

    • Industry standard architectures

    Perspective

    Capitalize on applicable domain architectures

    Maintain knowledge of evolving domain methods


    Slide26 l.jpg

    Architecture Life Cycle: Inputs: Enabling Technologies Def’n

    • Computation & communication hardware

      • Processing power and bandwidth

      • Intel, Cisco, …

      • Hardware in continual evolution

    • Integration environments

      • Applications, middleware, operating systems, …

      • Microsoft, Sun, Oracle, …

      • Environments in continual evolution

    • Integration enablers

      • HTML, XML, security, …

      • Enablers in continual evolution

    Perspective

    Maintain knowledge of evolving technologies

    Where possible, build on existing client environments

    Recognize enabler selections tie clients to supply chains

    Architect for component and environment evolution


    Slide27 l.jpg

    Architecture Life Cycle: Work Products Def’n

    INPUTS

    WORK PRODUCTS

    Architecture Fundamentals

    Architecture Practices

    Client Environment: enterprise arch. legacy systems initial requirements

    Marketplace Environment

    Domain Architectures

    Enabling Technologies

    Final Requirements

    Prototypes & Models

    Architecture Design

    Architecture Provisioning

    Architecture Validation

    Vendor Agreements

    Development Plan


    Slide28 l.jpg

    Architecture Life Cycle: Work Products: Final Requirements Def’n

    • Discovery and reconciliation

      • Requirements analysis with client

      • User experience with prototypes

      • User needs vs. product capabilities

    • Requirements trade-offs

      • Optimal non-functional property mix

      • Functional trade-offs:

    • Goal is no project impact

      • Customer understands trade-offs

      • Customer agrees to requirements baseline

      • Schedule and budget remain intact

    Benefit

    Low

    High

    Discuss

    High

    No Go

    Perspective

    Challenge and confirm key requirements

    Find any under-represented stakeholders

    Review property trade-offs with client

    The baseline plus controlled changes are the final reqs.

    It doesn’t matter how well the wrong system is built

    Cost

    Discuss

    Go

    Low


    Slide29 l.jpg

    Architecture Life Cycle: Work Products: Prototypes & Models Def’n

    • Prototype goals

      • Requirements elicitation and finalization

      • Proof of concept

    • Model goals

      • Simulation, prediction of system performance

      • Proof of concept

    • Prototyping and Modeling

      • Key risk management strategies

      • Can be a phase in multi-phase project

    Perspective

    Target prototypes to specific questions and objectives

    Evolving prototypes into products can be very risky

    Model results are only as good as model fidelity

    Model results are only as good as model inputs

    Match modeling effort to project stakes


    Slide30 l.jpg

    Architecture Life Cycle: Work Products: Architecture Design I

    • Architecture is the integrating foundation of the project

      • A complete abstraction of the final system

      • Defers details without losing them

      • Development and usage become envisionable

      • Basis for reasoning, discussions, and decisions

    • Satisfies client needs

      • Functional and non-functional requirements

      • Traceability of requirements into architecture is important

    • Prescribes system development

      • Architecture should leave nothing out at

        its level of abstraction

      • Development should refine, not

        invent, architecture

    Perspective

    Get all the guidance, advice, and review you can find

    Simple and straightforward solutions are best

    Use what is known to work -- capitalize on similar projects


    Slide31 l.jpg

    Architecture Life Cycle: Work Products: Architecture Design II

    • Architecture defines

      • External behavior design (system specification)

        • User tasks and workflows

        • Stimulus/response behavior

      • Data and software design (logical infrastructure)

        • Retained state, application software, …

        • Middleware, operating systems, databases, …

        • Partitioning of function and data in an architectural style

      • Hardware and network design (physical infrastructure)

        • Servers, mainframes, PCs, …

        • Media, devices, topology, protocols, …

      • Non-functional properties

        • Property definitions

        • How properties are satisfied

      • User skills and training


    Slide32 l.jpg

    Architecture Life Cycle: Work Products: Provisioning II

    • Provide specifications for every component

      • Function

      • Usage

      • Non-functional properties

    • Provide source for every component

      • As-is or modified legacy or COTS

      • As-is or modified partner product

      • Enabling environment or technology

      • New development

      • ISP, ASP, …

      • Various combinations

    Perspective

    Select sources based on component specifications

    Satisfy cost objectives

    Define level of effort for component provisioning

    Carefully weigh benefits of buy vs. build

    Develop components as a last resort


    Slide33 l.jpg

    Architecture Life Cycle: Work Products: Validation II

    • Validate architecture functionality

      • Every required user function must be present

      • All functions must operate harmoniously

    • Validate non-functional properties

      • Every required property must be satisfied

      • All properties must co-exist harmoniously

    • Validation processes

      • Verify “as-designed” against “as-specified”

      • Many methods may be employed

      • Team inspections are a key technique

    Perspective

    Treat validation as a distinct task

    Apply validation entry and exit conditions

    Ensure artifacts are in shape for validation

    Validate conformance of artifacts to specifications

    Document evidence for conformance

    Iterate validation and rework until artifacts pass

    Use validation defect rates to manage quality


    Slide34 l.jpg

    Architecture Life Cycle: Work Products: Vendor Agreements II

    • Architecture is a driver of vendor agreements

      • Incorporates vendor components

      • Basis for development plan

      • Defines component deliverables

        • Provisioning strategies

        • Requirements and specifications

      • Defines service deliverables

        • Scope and QoS

        • Staffing and skills

    Perspective

    Define deliverables for vendor agreements

    Perform due diligence on vendor capabilities

    Define checkpoints for assessing vendor progress

    Define testable acceptance criteria for deliverables

    Define implications of acceptance failure

    Manage risk with plan B for critical components


    Slide35 l.jpg

    Architecture Life Cycle: Work Products: Development Plan II

    • Defines development environment

      • Enabling technologies

      • Development and testing processes

    • Defines development steps

      • Incremental development is essential

      • Stepwise completion of system parts

      • Client feedback from early increments

      • Tasks and schedules

    Perspective

    Define environment early to drive staffing and training

    Define steps so that system accumulates into final form

    Be prepared for development feedback to architecture

    Evaluate early increments wrt required properties


    Slide36 l.jpg

    Architecture Life Cycle: Arch. Development II

    INPUTS

    ITERATIVE ARCHITECTURE DEVELOPMENT

    WORK PRODUCTS

    Architecture Fundamentals

    Architecture Practices

    Client Environment: enterprise arch. legacy systems initial requirements

    Marketplace Environment

    Domain Architectures

    Enabling Technologies

    Planning

    Mgmt. Plan

    Final Requirements

    Prototypes & Models

    Architecture Design

    Architecture Provisioning

    Architecture Validation

    Vendor Agreements

    Development Plan

    Ent. Arch., Legacy, Reqs., Market, Domain, Enablers

    Analysis

    (Architecture Development)

    Devel. Planning

    Env. and Steps

    Schedule


    Slide37 l.jpg

    Architecture Life Cycle: Arch. Development: Schedule II

    • Embedded within project schedule

      • Supports project dependencies

    • Entry conditions (rarely satisfied)

      • Stable and complete requirements

      • Availability of appropriate staff and resources

    • Exit condition

      • Architecture work products are complete and validated

    Perspective

    Failure to meet schedule is a non-starter

    Surface schedule-impacting problems early

    Work at level of abstraction compatible with schedule


    Slide38 l.jpg

    Architecture Life Cycle: Arch. Development: Management Plan II

    • Defines work products

      • Project-specific architecture artifacts

    • Defines tasks

      • Activities that will produce the work products

    • Defines internal schedules and resources

      • Task sequencing and resource allocation

    • Defines risks and mitigations

      • Key risks and uncertainties

      • Actions for recognition and control

    Perspective

    Plan is a sequencing of tasks plus risk management

    Define tasks to accumulate into work products

    Use the plan to manage the architecture work

    Track actual vs. predicted performance

    Discovery/experimentation tasks can reduce risk


    Slide39 l.jpg

    Architecture Life Cycle: Arch. Development: Analysis II

    • Understand the client and resources

      • Client problem

        • Enterprise architecture and business models

        • Legacy systems

        • Requirements

        • From present operations to envisioned future operations

      • Potential resources

        • Marketplace offerings

        • Domain architectures

        • Enabling technologies

    • A project-long activity

      • May require experimentation, training

      • Document understandings for decision-making

    Perspective

    Never stop learning about the problem and resources


    Slide40 l.jpg

    Architecture Life Cycle: Arch. Development: Development Planning

    • Define development environment

    • Define development and testing steps

    Perspective

    Consult with developers to arrive at a consensus plan

    Consult with customers on staging of deliverables


    Slide41 l.jpg

    Architecture Life Cycle: Arch. Development: Design Activities

    INPUTS

    ITERATIVE ARCHITECTURE DEVELOPMENT

    WORK PRODUCTS

    Architecture Fundamentals

    Architecture Practices

    Client Environment: enterprise arch. legacy systems initial requirements

    Marketplace Environment

    Domain Architectures

    Enabling Technologies

    Planning

    Mgmt. Plan

    Final Requirements

    Prototypes & Models

    Architecture Design

    Architecture Provisioning

    Architecture Validation

    Vendor Agreements

    Development Plan

    Ent. Arch., Legacy, Reqs., Market, Domain, Enablers

    Analysis

    External Behavior

    Iterations

    Design

    Refine

    Refine

    Data & Software

    Design

    Refine

    Hardware & Network

    Design

    Validation Checkpoint

    Inspection

    Devel. Planning

    Env. and Steps

    Schedule


    Slide42 l.jpg

    Architecture Life Cycle: Arch. Development: The Refinement Process

    • External behavior design maps requirements into specifications

    • External behavior design plus network traffic, etc., drives data and software design

    • Data and software design plus network traffic, geography, etc., drives hardware and network design

    • Non-functional requirements drive everything

    • System evolution requirements drive everything

    Perspective

    Refinement process allows divide, connect, and conquer strategy

    Refinement helps maintain intellectual control

    Refinements can be verified wrt their specifications

    Can’t design the top without knowing the bottom

    Last intellectual pass is top down


    Slide43 l.jpg

    Architecture Life Cycle: Arch: Development: The Iteration Process

    • The first idea is rarely the best idea

    • Iteration drives evaluation and improvement

    • Iteration permits systematic convergence to a solution

    • Iteration has desirable properties similar to requirements change control

    • Iterations document design decisions

    Perspective

    Use iteration to achieve informed agreement

    Use iteration to uncover gaps and misunderstandings

    Continually challenge assumptions and decisions