s SIEMENS CORPORATE RESEARCH SCR SE Architecture Requirements

  • Slides: 14
Download presentation
s SIEMENS CORPORATE RESEARCH SCR SE Architecture Requirements Engineeering Theory vs. Practice Bob Schwanke

s SIEMENS CORPORATE RESEARCH SCR SE Architecture Requirements Engineeering Theory vs. Practice Bob Schwanke STRAW ‘ 03 1

s Motivation One of world’s largest software employers q Internal consulting on software architecture

s Motivation One of world’s largest software employers q Internal consulting on software architecture q Previous books on architecture description and project management q Recent project turned out badly: SIEMENS CORPORATE RESEARCH q i Failed to win buy-in i Had all the pieces, couldn’t put them together i Requirements Engineering was part of the problem q Goal 1: Architecture-centered reference process i Practical i Adaptable (to different organizations and to changing conditions) i Optimizable Goal 2: Connect requirements to architecture and implementation q 2

s Overview Motivation q A Reference Process: Data + Control q Stakeholder Analysis q

s Overview Motivation q A Reference Process: Data + Control q Stakeholder Analysis q Product Features, Requirements, and Specifications q Global Analysis: Factors vs. Requirements q Global Analysis: Issues and Strategies q Consistency Across Dependencies q. Adapting the Process SIEMENS CORPORATE RESEARCH q 3

s Stakeholder List Stakeholder Requests Voice of the Customer SIEMENS CORPORATE RESEARCH Feature Reqts

s Stakeholder List Stakeholder Requests Voice of the Customer SIEMENS CORPORATE RESEARCH Feature Reqts Detailed Reqts UI Prototype A Reference Process: Data and 360 View Dependencies Representativ es Priority/Plan Complete “What” Partial “How” Product Specs Complete “How” 4

s Stakeholder List SIEMENS CORPORATE RESEARCH Stakeholder Requests Feature Reqts Global Analysis Detailed Reqts

s Stakeholder List SIEMENS CORPORATE RESEARCH Stakeholder Requests Feature Reqts Global Analysis Detailed Reqts Arch. Concept UI Prototype Product Specs Arch. Description A Reference Process: Data and Dependencies Architectural Factors Issues Strategies Broad Audience Partial Description Justifies Approach Technical Audience Complete Description 5

s Stakeholder List Stakeholder Requests SIEMENS CORPORATE RESEARCH Feature Reqts A Reference Process: Data

s Stakeholder List Stakeholder Requests SIEMENS CORPORATE RESEARCH Feature Reqts A Reference Process: Data and Dependencies Global Analysis Unresolved Issues Detailed Reqts Arch. Concept Project Risks UI Prototype Product Specs Arch. Description Build/Release Plan 6 weeks internal Bucketed Scenarios Bucketed Requirements 6

s Stakeholder List RESEARCH CORPORATE Global Analysis Detailed Reqts Arch. Concept Project Risks UI

s Stakeholder List RESEARCH CORPORATE Global Analysis Detailed Reqts Arch. Concept Project Risks UI Prototype Arch. Description Product Specs Test Plan Detailed Designs Build/Release Plan SW Development Plan Definition Phase SIEMENS Feature Reqts Concept Phase Stakeholder Requests A Reference Process: Data and Dependencies 7

s Control concepts Each document is a potentially separate, concurrent thread q Each thread

s Control concepts Each document is a potentially separate, concurrent thread q Each thread “executes” opportunistically until “complete enough” and “consistent enough” q Allocate documents to teams, e. g. Marketing, Req. Eng. , Architecture, Development q Closer coordination within teams than across teams q Each document associated with phase of first review q Phase gate defines “complete enough” and “consistent enough” for next phase SIEMENS CORPORATE RESEARCH q 8

s Stakeholder Analysis Stakeholder Class SIEMENS CORPORATE RESEARCH i. Affected by project i. May

s Stakeholder Analysis Stakeholder Class SIEMENS CORPORATE RESEARCH i. Affected by project i. May affect project (e. g. cancel it!) i. Concerns i. Has accessible representative Comprehensive (360 degree) analysis Classify and prioritize i. How important is their buy-in, and why? i. When to approach, and how i. Which documents would convince them? All project decisions draw authority from stakeholders 9

s Requirements: How Many Documents? Theory: “What” vs. “how” q Different know-how q Overlapping

s Requirements: How Many Documents? Theory: “What” vs. “how” q Different know-how q Overlapping information q Maintenance Marketing team: What sells, how to make headaches SIEMENS CORPORATE RESEARCH q Feature Reqts Detailed Reqts UI Prototype Product Specs money Subject matter experts, tech support: everything the product has to do UI Designers: Cognitive processes, aesthetics Software Designers: How it can be done 10

s SIEMENS CORPORATE RESEARCH Requirements vs. Architectural Factors Requirement Architectural Factor q Predicate q

s SIEMENS CORPORATE RESEARCH Requirements vs. Architectural Factors Requirement Architectural Factor q Predicate q Assertion the product must satisfy q Correct (validated) q Precise q Testable q Complete (collectively) that affects the product or project “Our developers don’t know Java” q Some likelihood of being true “DB transaction rates might overwhelm preferred DBMS product” q Negotiable “Buy reporting system if it’s affordable” q Covers a range of possibilities “Maximum configuration size will grow by 2 x to 4 x per year” q Arguable q More or less important 11

s Issues and Strategies SIEMENS CORPORATE RESEARCH Issue 9: Scaling Up and Down PDX

s Issues and Strategies SIEMENS CORPORATE RESEARCH Issue 9: Scaling Up and Down PDX must support solution sizes from 100 to 1, 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, 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). 12

s Consistency Across Dependencies Consider Feature Reqts Global Analysis (FR GA) SIEMENS CORPORATE RESEARCH

s Consistency Across Dependencies Consider Feature Reqts Global Analysis (FR GA) SIEMENS CORPORATE RESEARCH q E. g. some Factors reference Features q Concurrent progress requires tracking inconsistency Stakeholder List Producer / Consumer Reviews q GA team reviews Feature Requirements Stakeholder Requests q FR team reviews Global Analysis q Review record identifies inconsistencies Feature Reqts Global Analysis q Process enhances cross-team communication What if GA ready before FR? Detailed Reqts q GA must document assumptions UI Prototype q E. g. “fat reference” from Patterns community Product Specs Arch. Concept Arch. Description 13

s Stakeholder List My current project Market. Stakeholder Intent | Other Requests SIEMENS Detailed

s Stakeholder List My current project Market. Stakeholder Intent | Other Requests SIEMENS Detailed Reqts Q&A Global Analysis Arch. Concept Project Risks UI Prototype Arch. Description Product Specs Test Plan Detailed Designs Build/Release Plan SW Development Plan Definition Phase CORPORATE RESEARCH Feature Reqts Concept Phase Project (reference) This Week Start 14