1 / 14

SCR SE

SCR SE. Architecture Requirements Engineeering Theory vs. Practice Bob Schwanke STRAW ‘03. Motivation. One of world’s largest software employers Internal consulting on software architecture Previous books on architecture description and project management

minda
Download Presentation

SCR SE

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SCR SE ArchitectureRequirementsEngineeering Theory vs. Practice Bob Schwanke STRAW ‘03

  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. 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. Stakeholder List Stakeholder Requests Feature Reqts Detailed Reqts UI Prototype Product Specs A Reference Process: Data and Dependencies 360 ViewRepresentatives Priority/Plan Voice of the Customer Complete “What” Partial “How” Complete “How”

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

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

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

  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. 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. Feature Reqts Detailed Reqts UI Prototype Product Specs Requirements: How Many Documents? • Theory: “What” vs. “how” • Different know-how • Overlapping information • Maintenance headaches Marketing team: What sells, how to make money Subject matter experts, tech support: everything the product has to do UI Designers: Cognitive processes, aesthetics Software Designers: How it can be done

  11. 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 Requirements vs. Architectural Factors

  12. Issues and Strategies Issue 9: Scaling Up and Down PDX must support solution sizes from 100 to 1,000,000 points, alsoranging 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. Stakeholder List Stakeholder Requests Feature Reqts Global Analysis Detailed Reqts Arch. Concept UI Prototype Arch. Description Product Specs 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

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

More Related