1. s S I E M E N S C O R P O R A T E R E S E A R C H 1 SCR SE Architecture Requirements Engineeering Theory vs. Practice Bob Schwanke STRAW ‘03

2. s S I E M E N S C O R P O R A T E R E S E A R C H 2 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

3. s S I E M E N S C O R P O R A T E R E S E A R C H 3 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 Dependencies  Adapting the Process

4. s S I E M E N S C O R P O R A T E R E S E A R C H 4 A Reference Process: Data and Dependencies Stakeholder List Stakeholder Requests Feature Reqts UI Prototype Product Specs Detailed Reqts 360 View Representatives Priority/Plan 360 View Representatives Priority/Plan Voice of the Customer Complete “What” Partial “How” Complete “How”

5. s S I E M E N S C O R P O R A T E R E S E A R C H 5 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 Factors Issues Strategies Architectural Factors Issues Strategies Broad Audience Partial Description Justifies Approach Broad Audience Partial Description Justifies Approach Technical Audience Complete Description Technical Audience Complete Description

6. s S I E M E N S C O R P O R A T E R E S E A R C H 6 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 Issues 6 weeks internal Bucketed Scenarios Bucketed Requirements 6 weeks internal Bucketed Scenarios Bucketed Requirements

7. s S I E M E N S C O R P O R A T E R E S E A R C H 7 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 Concept Phase Definition Phase

8. s S I E M E N S C O R P O R A T E R E S E A R C H 8 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

9. s S I E M E N S C O R P O R A T E R E S E A R C H 9 Stakeholder Analysis Stakeholder Class  Affected by project  May affect project (e.g. cancel it!)  Concerns  Has accessible representative Comprehensive (360 degree) analysis Classify 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

10. s S I E M E N S C O R P O R A T E R E S E A R C H 10 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 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, aesthetics Software Designers : How it can be done

11. s S I E M E N S C O R P O R A T E R E S E A R C H 11 Requirements vs. Architectural Factors Requirement  Predicate the product must satisfy  Correct (validated)  Precise  Testable  Complete (collectively) Architectural Factor  Assertion 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

12. s S I E M E N S C O R P O R A T E R E S E A R C H 12 Issues and Strategies Issue 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 communication Where 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 architecture Use 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 options In 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).

13. s S I E M E N S C O R P O R A T E R E S E A R C H 13 Consistency Across Dependencies Consider Feature Reqts  Global Analysis (FR  GA)  E.g. some Factors reference Features  Concurrent progress requires tracking inconsistency Producer / Consumer Reviews  GA team reviews Feature Requirements  FR team reviews Global Analysis  Review record identifies inconsistencies  Process enhances cross-team communication What if GA ready before FR?  GA must document assumptions  E.g. “fat reference” from Patterns community Stakeholder List Stakeholder Requests Global Analysis Arch. Concept Arch. Description Feature Reqts UI Prototype Product Specs Detailed Reqts

14. s S I E M E N S C O R P O R A T E R E S E A R C H 14 My current project Stakeholder 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 Start Market Intent | Other Requests This Week Q&A Concept Phase Definition Phase