s

1

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

SCR SE

ArchitectureRequirementsEngineeering

Theory vs. Practice

Bob SchwankeSTRAW ‘03

s

2

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

Motivation

One of world’s largest software employers Internal consulting on software architecture Previous books on architecture description and project

management Recent project turned out badly:

Failed to win buy-in Had all the pieces, couldn’t put them together Requirements Engineering was part of the problem

Goal 1: Architecture-centered reference process Practical Adaptable (to different organizations and to changing conditions) Optimizable

Goal 2: Connect requirements to architecture and implementation

s

3

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

Overview

Motivation A Reference Process: Data + Control Stakeholder Analysis Product Features, Requirements, and Specifications Global Analysis: Factors vs. Requirements Global Analysis: Issues and Strategies Consistency Across DependenciesAdapting the Process

s

4

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

A Reference Process: Data and Dependencies

Stakeholder List

Stakeholder Requests

Feature Reqts

UI Prototype

Product Specs

Detailed Reqts

360 ViewRepresentatives

Priority/Plan

360 ViewRepresentatives

Priority/Plan

Voice of the Customer

Voice of the Customer

Complete “What”Complete “What”

Partial “How”Partial “How”

Complete “How”Complete “How”

s

5

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

A Reference Process: Data and Dependencies

Stakeholder List

Stakeholder Requests

Global Analysis

Arch. Concept

Arch. Description

Feature Reqts

UI Prototype

Product Specs

Detailed Reqts

Architectural FactorsIssues

Strategies

Architectural FactorsIssues

Strategies

Broad AudiencePartial DescriptionJustifies Approach

Broad AudiencePartial DescriptionJustifies Approach

Technical AudienceComplete Description

Technical AudienceComplete Description

s

6

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

A Reference Process: Data and Dependencies

Stakeholder List

Stakeholder Requests

Global Analysis

Arch. Concept

Arch. Description

Project Risks

Build/Release Plan

Feature Reqts

UI Prototype

Product Specs

Detailed Reqts

Unresolved IssuesUnresolved Issues

6 weeks internalBucketed Scenarios

Bucketed Requirements

6 weeks internalBucketed Scenarios

Bucketed Requirements

s

7

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

A Reference Process: Data and Dependencies

Stakeholder List

Stakeholder Requests

Global Analysis

Arch. Concept

Arch. Description

Project Risks

Build/Release Plan

Test Plan

Detailed Designs

Feature Reqts

UI Prototype

Product Specs

Detailed Reqts

SW Development Plan

Co

ncep

t Ph

aseD

efinitio

n

Ph

ase

s

8

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

Control concepts

Each document is a potentially separate, concurrent thread

Each thread “executes” opportunistically until “complete enough” and “consistent enough”

Allocate documents to teams, e.g. Marketing, Req. Eng., Architecture, Development

Closer coordination within teams than across teams Each document associated with phase of first review Phase gate defines “complete enough” and “consistent

enough” for next phase

s

9

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

Stakeholder Analysis

Stakeholder Class Affected by project May affect project (e.g. cancel it!) Concerns Has accessible representative

Comprehensive (360 degree) analysisClassify and prioritize

How important is their buy-in, and why? When to approach, and how Which documents would convince them?

All project decisions draw authority from stakeholders

s

10

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

Requirements: How Many Documents? Theory: “What” vs. “how” Different know-how Overlapping information Maintenance headaches

Feature Reqts

UI Prototype

Product Specs

Detailed Reqts

Marketing team: What sells, how to make moneyMarketing team: What sells, how to make money

Subject matter experts, tech support: everything the product has to do

Subject matter experts, tech support: everything the product has to do

UI Designers: Cognitive processes, aestheticsUI Designers: Cognitive processes, aesthetics

Software Designers: How it can be doneSoftware Designers: How it can be done

s

11

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

Requirements vs. Architectural Factors

RequirementPredicate the product must

satisfyCorrect (validated)

Precise

TestableComplete (collectively)

Architectural FactorAssertion that affects the product or project

“Our developers don’t know Java”Some likelihood of being true

“DB transaction rates might overwhelm preferred DBMS product”

Negotiable“Buy reporting system if it’s affordable”

Covers a range of possibilities“Maximum configuration size will grow by 2x to 4x per year”

Arguable More or less important

s

12

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

Issues and StrategiesIssue 9: Scaling Up and Down

PDX must support solution sizes from 100 to 1,000,000 points, also ranging from very simple to very complex. In addition, there are license costs, engineering and commissioning efficiency, and pricing constraints.

Strategy 26: Location transparent communicationWhere practical, connections between software elements should have the same logical behavior whether the elements are implemented on the same or different computers.

Impact: Location transparency will allow different PDX solutions to use different numbers and types of processors without requiring individual software elements to know about all the possibilities.

Strategy 36: Use a scalable hardware architectureUse a scalable hardware architecture, made up of one or more PDX servers, which could even be multi-processor PCs.

Impact: Using multiple servers can improve memory and processing capacity, increase the number of separate buses served, distribute the solution across multiple buildings, and improve reliability.

Strategy 38: Selectable performance-enhancing optionsIn several technical areas, it is possible to purchase COTS packages that would enhance the performance or richness of high-end solutions. Design PDX so that these packages are optional (for extra cost, with separate license).

s

13

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

Consistency Across Dependencies

Consider Feature Reqts Global Analysis (FR GA)E.g. some Factors reference FeaturesConcurrent progress requires tracking inconsistency

Producer / Consumer ReviewsGA team reviews Feature RequirementsFR team reviews Global AnalysisReview record identifies inconsistenciesProcess enhances cross-team

communication

What if GA ready before FR?GA must document assumptionsE.g. “fat reference” from

Patterns community

Stakeholder List

Stakeholder Requests

Global Analysis

Arch. Concept

Arch. Description

Feature Reqts

UI Prototype

Product Specs

Detailed Reqts

s

14

S I

E M

E N

S

C

O R

P O

R A

T E

R E

S E

A R

C H

My current projectStakeholder List

Global Analysis

Arch. Concept

Arch. Description

Project Risks

Build/Release Plan

Test Plan

Detailed Designs

Feature Reqts

UI Prototype

Product Specs

Detailed Reqts

SW Development Plan

Stakeholder Requests

(reference)Market Intent | Other Requests

Project StartMarket Intent | Other Requests

This Week

Q&A

Co

ncep

t Ph

aseD

efinitio

n

Ph

ase