© 2007 Carnegie Mellon University
QUality Assessment ofSystem Architecturesand their Requirements(QUASAR)Software Engineering InstituteCarnegie Mellon UniversityPittsburgh, PA 15213
Donald Firesmith28 March 2007
Report Documentation Page Form ApprovedOMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering andmaintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, ArlingtonVA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if itdoes not display a currently valid OMB control number.
1. REPORT DATE 28 MAR 2007 2. REPORT TYPE
3. DATES COVERED 00-00-2007 to 00-00-2007
4. TITLE AND SUBTITLE QUality Assessment of System Architectures and their Requirements (QUASAR)
5a. CONTRACT NUMBER
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Carnegie Mellon University ,Software Engineering Institute (SEI),Pittsburgh,PA,15213
8. PERFORMING ORGANIZATIONREPORT NUMBER
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
14. ABSTRACT
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF ABSTRACT Same as
Report (SAR)
18. NUMBEROF PAGES
153
19a. NAME OFRESPONSIBLE PERSON
a. REPORT unclassified
b. ABSTRACT unclassified
c. THIS PAGE unclassified
Standard Form 298 (Rev. 8-98) Prescribed by ANSI Std Z39-18
2QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Topics
What is QUASAR?
Why Use QUASAR?
QUASAR Philosophy
QUASAR Method
QUASAR Benefits
QUASAR – Today and Tomorrow
3QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What is QUASAR?
5QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What is QUASAR?
QUality Assessment of System Architectures and their Requirements
a Well-Documented and Proven Method based on the use of QualityCases for Independently Assessing the Quality of:
• Software-intensive System / Subsystem Architectures and the
• Architecturally-Significant Requirements that Drive Them
QUASAR Version 1 (July 2006) emphasized the quality assessmentof architectures against architecturally-significant requirements.
QUASAR Version 2 (February 2007) addresses the qualityassessment of both architectures and their architecturally-significantrequirements.
6QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Understanding QUASAR’s Definition
To understand QUASAR’s definition, you must understand:
• Quality
• Quality Cases
• Software-Intensive Systems (as opposed to just Software)
• Architecture
• Architecturally-Significant Requirements
7QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Model:Defining System Architecture Quality
8QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What is Quality?
Qualitythe Degree to which a Work Product (e.g., System, Subsystem,Requirements, Architecture) Exhibits a Desired or Required Amountof Useful or Needed Characteristics
Quality of a Work Product is defined in terms of a Quality Model:
• Quality Factors(a.k.a., Quality Attributes, Quality Characteristics, ‘ilities’)(e.g., availability, interoperability, performance, reliability, etc.)
• Quality Subfactors(e.g., jitter, latency, response time, schedulability, throughput)
• Quality Measures(e.g., milliseconds, transactions per second)
9QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Model
Quality Model
QualityFactor
QualitySubfactor
QualityMeasure
Work Product
defines the meaning of the quality of a
is measured using a
defines the meaning ofa specific
type of quality of a
RequirementsSystem
Subsystems
Architectureshas drive
10QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Model – Quality Factors
Robustness
Safety
Security
Survivability
Defensibility
Availability
Correctness
Predictability
Reliability
Soundness
Stability
Dependability
Efficiency
Interoperability
Configurability
Capacity
Performance
Usage-Oriented Quality Factor
Development-Oriented Quality Factor
Quality Factor
Sustainability
UsabilityAffordability
11QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Model – Performance QualitySubfactors
Performance Subfactor
Performance
Response Time
Latency
Jitter
Quality Factor
Quality Subfactor
Schedualability
Throughput
Quality Measure
is measured using a
Quality Model
Mandated Threshold
Failure Detection
Failure Reaction
Failure Adaptation
12QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Model – Safety Quality Subfactors
Safety SubfactorSafety
Safety Problem Type
Safety Solution Type
Accident & Safety Incident
Hazard
Safety Risk
Harm
Prevention
Detection
Reaction
Adaptation
Internal Vulnerability
Nonmalicious Agent
13QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Case:Foundation of QUASAR
14QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Case - Definition
Quality Case
a Cohesive Collection of Claims, Arguments, and Evidence thatMakes the Developers’ Case that their Work Product has SufficientQuality
A Generalization of Safety Cases from the Safety Community:
• Can Address any Quality Factor and/or Quality Subfactor
Useful for:
• Assessing Quality
• Certification and Accreditation
15QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Cases – Components1
A Quality Case consists of the following types of Components:• Claims
Developers’ Claims that their Work Products have Sufficient Quality,whereby quality is defined in terms of the qualify factors and qualitysubfactors defined in the official project quality model
• ArgumentsClear, Compelling, and Relevant Developer Arguments Justifying theAssessors’ Belief in the Developers’ Claims(e.g., inventions, decisions, analysis and simulation results, trade-offs,associated rationales, and assumptions)
• EvidenceAdequate Credible Evidence Supporting the Developers’ Arguments(e.g., official project diagrams, models, requirements specificationsand architecture documents; requirements repositories; analysis andsimulation reports; test results; and demonstrations witnessed by theassessors)
16QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Cases – Components2
Quality Case
make developer’s’ case for adequate quality of the
Work Product
Claims
Arguments
Evidence
supports
justify belief in
Quality Factor
Quality Subfactor
is developed for
17QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Cases – Components3
Quality Case
Claims Arguments Evidencejustify belief in supports
makes the case for the quality of a
Work Product
Quality Factor
Quality Subfactors
is specific to a
defines a type of quality of a
define a part of a type of quality of a
18QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Throughput Quality Case
Quality Case
ThroughputArguments
ThroughputEvidence
justify belief in supports
makes the case for the quality of a
System
Subsystem
Quality Factor
Quality Subfactors
is specific to a
defines a type of quality of a
define a part of a type of quality of a
Performance Quality Case
Throughput Quality Case
ThroughputClaims
19QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Specialized QUASAR Quality Cases
QUASAR utilizes the following types of Quality Case:
• Requirements Quality Cases
• Architectural Quality Cases
QUASAR Version 1 only had Architectural QualityCases.
QUASAR Version 2 has Both Types of Quality Cases.
20QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Requirements Quality Cases1
Requirements Quality Case
a Specialized Quality Case that is Limited to the Quality ofArchitecturally-Significant, Quality-Related Requirements
Makes Requirements Team’s Case that their RelevantRequirements are:
• Ready to Drive the Engineering of the Architecture:
— Sufficient Quality(e.g., are Correct, Complete, Consistent, Mandatory,Unambiguous, Verifiable, Usable, etc.)
— Sufficient Quantity(e.g., Sufficient for Current Point in Project Schedule)
• Sufficient on which to base the Subsystem Architecture Assessment
21QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Requirements Quality Cases2
RequirementsQuality Case
makes requirements engineers’ case for adequate quality of the
System/SubsystemQuality-Related Requirements
Claims: Quality-Related Requirements Help System Meet Stakeholder Quality Goals
Arguments: Requirements Decisions (Quality-Related Requirements), Trade-Offs, Rationales, and Assumptions
Evidence: Requirements Diagrams, Models, Repositories, and Specifications
supports
justify belief in
make verifiable Claims: Quality-Related Goals Help System Meet Stakeholder Quality Needs
Quality Factor
Quality Subfactor
is developed for
22QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Requirements Quality Cases3
Quality Case
Arguments Evidencejustify belief in supports
makes the case for the quality of a
System Subsystem
makes the case for the quality of the
Claims
RequirementsArguments
RequirementsEvidence
justify belief in supportsRequirementsClaims
RequirementsQuality Case
Quality-RelatedRequirements
specify required quality
of a
Work Product
23QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Requirements Quality Cases4
Claims:
• Quality-Related Goals Sufficiently Meet Stakeholder Quality Needs
• Quality-Related Requirements Sufficiently Operationalize QualityGoals
Arguments:
• Existence and Quality of Quality-Related Requirements
• Requirements Engineering Trade-Offs, Rationales, and Assumptions
Evidence:
• Requirements Diagrams, Models, and Prototypes
• Requirements Repositories and Specification Documents
• Requirements Inspection and Checking Results
24QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Example Requirements Quality Case1
Example Requirements Reliability Case
Claims:
• Subsystem X Requirements Engineers claim that their SubsystemGoals Sufficiently Meet Stakeholder Reliability Needs:
— “All Stakeholder Reliability Needs Allocated to Subsystem X havebeen Transformed into Subsystem X Reliability Goals.”
• Subsystem X Requirements Engineers Claim that their SubsystemReliability Requirements Sufficiently Help the Subsystem Meet itsReliability Goals:
— “All Subsystem X Reliability Goals for this block/release havebeen Operationalized into Requirements.”
— “All Subsystem X Reliability Requirements for this block/releasehave been Properly Engineered.”
25QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Example Requirements Quality Case2
Arguments:• Subsystem X Reliability Requirements are:
— Stored in the Project Requirements Repository— Published in the Subsystem X Requirements Specification
• Subsystem X Reliability Requirements in the RequirementsRepository have been annotated as Reliability Requirements usingRequirements Metadata.
• The Subsystem X Architects have verified the Feasibility of theReliability Requirements given available Hardware and SoftwareTechnology.
• Appropriate Availability, Reliability, and Security Requirements Trade-Offs have been made.
• The Subsystem X Reliability Requirements have been Checkedagainst a Checklist of Necessary Quality Characteristics (e.g.,Correctness, Completeness, Consistency, Necessity, Unambiguous,Verifiability, and Usability).
26QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Example Requirements Quality Case3
Example Requirements Reliability Case
Evidence:
• Requirements Traceability Matrix showing Allocation of ReliabilityRequirements from Parent Subsystem A to Derived ReliabilityRequirements in Subsystem X
• Project Requirements Repository with Subsystem X ReliabilityRequirements identified
• Reliability Section in Subsystem X Requirements SpecificationDocument
• Reliability Subsection of Subsystem X Requirements InspectionReport
27QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Requirements Quality Case Challenges
Most Requirements Engineers are not trained in the ProperEngineering of Non-Functional Requirements (e.g., QualityRequirements).
Vague Unverifiable Goals are often Mistaken as Requirements.
Stakeholders often do Not know where to set Quality MeasureThresholds.
Requirements Repository is Huge and Complex.
Only Small Subset of the Requirements is Relevant to any specificQuality Factor or Quality Subfactor for any specific Subsystem.
Tracing Quality Requirements is more Difficult than TracingFunctional Requirements.
28QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Architectural Quality Cases
Architecture Quality Casea Specialized Quality Case that is Limited to the Quality of theSystem/Subsystem Architectures
Make Architectures Team’s Case that their Architecture(s) are:
• Ready to Drive the Engineering of the Design, Implementation,Integration, and Testing:
— Sufficient Quality(e.g., Adequately Support the System’s or Subsystem’s Abilityto meet its Quality-Related Requirements)
— Sufficient Quantity(e.g., Sufficient for Current Point in Project Schedule)
29QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Architectural Quality Cases2
ArchitecturalQuality Case
makes architects’ case for adequate quality of the
System/Subsystem Architecture
Claims: Architecture Helps System Meet Quality Requirements
Arguments: Architecture Decisions (e.g., patterns, mechanisms) with Rationales, Trade-Offs, and Assumptions
Evidence: Architectural Diagrams, Models, Documents, and Witnessed Demonstrations
supports
justify belief in
make verifiable Claims: Architecture Helps System Achieve Stakeholder Quality Goals
Quality Factor
Quality Subfactor
is developed for
30QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Architectural Quality Case
Quality Case
Arguments Evidencejustify belief in supports
makes the case for the quality of a
System Subsystem
makes the case for the quality of the
Claims
ArchitecturalArguments
ArchitecturalEvidence
justify belief in supportsArchitecturalClaims
ArchitecturalQuality Case
Architectures
has
Work Product
31QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Architectural Quality Cases4
Claims:• Architectures Sufficiently Supports System/Subsystem’s Ability to
Meet All Quality Goals and Quality Requirements
Arguments:• Architectural Decisions (e.g., Architectural Mechanisms, Patterns, and
Styles as well as Choice of OTS Components)
• Architectural Engineering Trade-Offs, Rationales, and Assumptions
Evidence:• Architectural Diagrams, Models (Static and Dynamic), and Prototypes
• Architecture Documents and Architectural Whitepapers
• Properly Documented Architectural Simulation and Test Results
• Properly Witnessed Demonstrations
32QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Example Architectural Quality Case1
Example Protocol Interoperability Case
Claims:
• Subsystem X Architects Claim that their Subsystem ArchitectureSufficiently Supports its following derived Protocol InteroperabilityGoals:
— “Subsystem X will correctly use the interface protocols of allrelevant external systems.”
— “Subsystem X will use open interface standards (i.e., industrystandard protocols) when communicating with all externalsystems.”
33QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Example Architectural Quality Case2
Example Protocol Interoperability Case
Claims:
• Subsystem X Architects Claim that their Subsystem ArchitectureSufficiently Supports its following derived Protocol InteroperabilityRequirements:
— “The subsystem shall use open interface standards (i.e., industrystandard protocols) when communicating with external systemsacross all key interfaces identified in document X.”
— “The subsystem shall use the Ethernet over RS-232 forcommunication across interface X with external system Y.”
— “The subsystem shall use HTTPS for communicating securelywhen performing function X across interface Y with externalsystem Z.”
34QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Example Architectural Quality Case3
Arguments:• Layered Architecture
The subsystem uses a layered architecture.Rationale: Interface layer supports interoperability.
• Modular ArchitectureThe subsystem architecture is highly modular.Rationale: Architecture includes modules (proxies) for interoperability.
• Wrappers and ProxiesThe subsystem architecture includes proxies that wrap the interfacesto external subsystems.Rationale: Proxies localize and wrap external interfaces.
• Service Oriented Architecture (SOA)The subsystem service oriented architecture uses XML, SOAP, andUDDI to publish and provide web services over the Internet toexternal client systems.Rationale: Standard languages and protocols support interoperabilitybetween heterogeneous systems.
35QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Example Architectural Quality Case3
Evidence:• Context Diagram
(shows external interfaces requiring protocols)
• Architectural Class Diagram(shows modularity and location of proxies and web services)
• Allocation Diagram(shows allocation of software modules to hardware - modularity)
• Layer Diagram(shows architectural layers)
• Activity/Collaboration Diagrams(show proxies, wrappers, and the source and use of services)
• Interoperability Whitepaper
• Vendor-Supplied Technical Documentation(show COTS product support for SOA and associated protocols)
36QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Quality Case Responsibilities
Requirements Engineers and Architects’ Responsibilities:• Prepare Quality Cases• Provide Preparation Materials (including Presentation Materials
and Quality Cases) to Assessors Prior to Assessment Meeting• Present Quality Cases (Make their Case to the Assessors)• Answer Assessors’ Questions
Assessor Responsibilities:• Prepare for Assessments• Actively Probe Quality Cases• Develop Consensus regarding Assessment Results• Determine and Report Assessment Results:
— Present Outbriefs— Publish Reports
37QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Architectural Quality Case Challenges
Huge and Complex System Architectures
Only Small Subset of the Architecture (a.k.a., focus area) is Relevant toany one Quality Factor or Quality Subfactor.
Quality Cases still Contain a Large Amount of Information.
Claims, Arguments, and a large amount of Evidence are typically Text.
Easy to get Lost in Real-World Quality Cases
Hard to know that:
• Arguments Sufficiently Justify Belief in Claims
• Evidence Sufficiently Supports Arguments
Need practical way to Communicate, Summarize, and Act as Index tothe Quality Case Essentials
38QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Case Diagram
A Layered UML Class Diagram that Labels and Summarizes theparts of a Single Quality Case:
• Classes:
— Claims
— Arguments
— Evidence
• Relationships Among Them:
— Aggregation Relationships Between Claims
— “Justifies Belief In” Associations from Arguments to Claims
— “Supports” Associations from Evidence to Arguments
Acts as an Index and Guide to the Quality Case
39QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Case Diagram NotationGoal: Quality Factor A
<<claim>>
justifies belief in
Decision 1<<argument>>
Goal: Quality Subfactor A1
<<claim>>Goal: Quality Subfactor A2
<<claim>>Goal: Quality Subfactor AN
<<claim>>…
Quality Subfactor A2:
Requirement A21 <<claim>>
…Quality Subfactor A2:
Requirement A22 <<claim>>
Quality Subfactor A2:
Requirement A2N <<claim>>
… Decision N<<argument>>
Trade-Off 1<<argument>>
Assumption 1<<argument>>…… Trade-Off N
<<argument>> … Assumption N<<argument>>
supports
Diagram 1<<evidence>>
Diagram N<<evidence>>
Model 1<<evidence>>
Document 1<<evidence>>… Model N
<<evidence>> … Document N<<evidence>>…
40QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Example Partial ArchitecturalPerformance Case Diagram
Goal: Architecture Supports Performance<<claim>>
Architecture Limits Jitter<<claim>>
Architecture Limits Latency
<<claim>>
Real-TimeOperating System
<<argument>>
Architecture Limits Response Time
<<claim>>
justifies belief in
Architecture Supports Schedulability
<<claim>>
Architecture Supports Throughput<<claim>>
Deterministic Scheduling
<<argument>>
Layered Architecture
<<argument>>
Redundant Servers with
Load Balancing<<argument>>
Hardware Selection
<<argument>>
Rate Monotonic Scheduling
<<argument>>
Sampled Approach for Real-Time I/O<<argument>>
COTS I/O Timer Board
<<argument>>
Real-TimeMiddleware
<<argument>>
41QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Architectural Interoperability Case Diagram
C laim : A rchitecture Supports Interoperability G oals
C laim : Physical Interoperability
C laim : Syntax Interoperability
Layered A rchitecture
C laim : Protocol Interoperability
justifies belief in
C laim : Energy Interoperability
C laim : Sem anticsInteroperability
M odular A rchitecture
O pen Interface Standards
Proxies and W rappers
Service O riented A rchitecture (SO A )
Fly-B y-W ire
O ne-W ay C onnections
W iring D iagram
H ardw areSchem atics
C ontext D iagram
C onfiguration D iagram
A llocation D iagram
N etw ork D iagram s
A ctivity or C ollaboration
D iagram s
Interoperability W hitepaper
V endor-Supplied Technical
D ocum entation
Layer D iagram
supports
Argum ents(Architectural
Decisions)
M eets Requirem ents
Evidence
42QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
System:QUASAR assesses System and SubsystemRequirements and Architectures
43QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What is a System?
System
a Major, Cohesive, Executable, and Integrated Set of ArchitecturalElements that Collaborate to Provide the Capability to Perform one ormore related Missions
Systems are Decomposed into Architectural Elements:
• Subsystems• Data Components• Hardware Components• Software Components• People Roles (e.g., Operators, Administrators)• Procedural Components• Facilities, Equipment, Materials
44QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Systems Imply
Multiple Static and Dynamic Logical and Physical “Structures”that exist at Multiple ‘Levels’ in the System:
• Static Functional Decomposition Logical Structure
• Static Subsystem Decomposition Physical Structure
• Hardware, Software, and Data Structures
• Allocation Structure (Software and Data to Hardware)
• Network Structure
• Concurrency (Process) Structure
Multiple Specialty Engineering Focus Areas(e.g., Performance, Reliability, Safety, and Security)
Requirements are Derived and Allocated to Lower-LevelArchitectural Elements
45QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
System and QUASAR Scope(Static Subsystem Decomposition Physical View Only!)
S y s te m o f S y s te m s
S y s te m 1 S y s te m 2 S y s te m 3 S y s te m N
S u b s y s te m 1 S u b s y s te m 2 S u b s y s te m 3 S u b s y s te m N
S e g m e n t 1 S e g m e n t 2 S e g m e n t 3 S e g m e n t N
...
...
...
S c o p e o fQ U A S A R A s s e s s m e n t
T ie r 1
T ie r 2
T ie r 3
T ie r 4
S u b s e g m e n t 3S u b s e g m e n t 2S u b s e g m e n t 1 ... S u b s e g m e n t N
A s s e m b ly 3A s s e m b ly 2A s s e m b ly 1 ... A s s e m b ly N
S u b a s s e m b ly 3S u b a s s e m b ly 2S u b a s s e m b ly 1 S u b a s s e m b ly N...
S W C S C I N...S W C S C I 1
T ie r 5
T ie r 6
T ie r 7
D a ta C I 1 ... D a ta C I N
M a n u a l P ro c e d u re s
F a c ilit ie sH W C I N...H W C I 1T ie r 8
R o le s
S W C 1 ... S W C N
S W U n it 1 ... S W U n it N
H W C 1 ... H W C N
P a rt 1 ... P a rt N
T ie r 9
T ie r 1 0
46QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
System Architectures:Strategic Pervasive Decisions, Inventions,and their Rationales
47QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What is a System Architecture?1
System Architecture
the Most Important, Pervasive, Top-Level, Strategic Inventions,Decisions, Engineering Trade-Offs, associated Rationales, andAssumptions about How a System and its Subsystems will meet theirDerived and Allocated Requirements
48QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What is a System Architecture?2
System Architecture Includes:• The System’s Numerous Static and Dynamic, Logical and
Physical Structures(i.e., Essential Architectural Elements, their Relationships, theirAssociated Blackbox Characteristics and Behavior, and how theyCollaborate to Support the System’s Mission and Requirements)
• Architectural Inventions and Decisions(e.g., Styles, Patterns, and Mechanisms used to ensure that theSystem Achieves its Architecturally-Significant Product and ProcessRequirements (esp. Quality Requirements or ‘ilities’)
• Strategic and Pervasive Design-Level Decisions(e.g., using a Design Paradigm such as Object-Orientation orMandated Widespread use of common Design Patterns)
• Strategic and Pervasive Implementation-Level Decisions(e.g., using a Safe Subset of C++)
49QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Some Example Views of Models of Structures
Physical Composition
View
LogicalFunctional
Decomposition View
Mode and State View
Information View
Data Flow View
Collaboration View
Architectsmust ensure
view and model consistency
Multifaceted architecture having multiple structures requiring multiple models providing multiple views
50QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Architecture vs. Design
DesignArchitecturePervasive (Multiple Components) Local (Single Components)
Tactical Decisions and InventionsStrategic Decisions and Inventions
Lower-Levels of SystemHigher-Levels of System
Huge Impact on Quality, Cost, & Schedule Small Impact on Quality, Cost, & Schedule
Drives Design and Integration Testing Drives Implementation and Unit TestingDriven by Requirements and Higher-Level
ArchitectureDriven by Requirements, Architecture, and
Higher-Level DesignMirrors Top-Level Development Team
Organization (Conway’s Law)No Impact on
Top-Level Development Team Organization
51QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Architectural Documentation Current-State
System Architecture Documents:
• Mostly natural language Text with Visio-like Diagrams
• Logical (functional) and Physical Architecture
DOD Architecture Framework (DODAF):
• All-Views, Operational Views, Systems Views, and Technical StandardsViews for allocating Responsibilities to Systems and Supporting SystemInteroperability
Models (both static and dynamic; logical and physical):
• Tailored UML becoming de facto Industry Standard
• SysML starting to become Popular
Visio Diagrams as Wall Posters
Whitepapers, Reports, and other Specialty-Engineering Documents:
• Performance, Fault Tolerance, Safety, Security
52QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What an Architecture is NOT
A System Architecture is Not an Architectural:
• Plan
• Method(architecting procedures and architecture documentation standards)
• Team Organization Chart(in spite of Conway’s Law)
• Development Schedule
QUASAR assesses Actual Architectures:
• As they Currently Exist (i.e., a Snapshot in Time)
• Not Good Intentions
53QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Systems Architect:Responsible for the Architecture
54QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What is a Systems Architect?1
A Role played by a Systems Engineer, who is Responsible for:
• Developing one or more System or Subsystem Architectures
• Ensuring the Quality of the System or Subsystem Architectures
• Ensuring the Integrity of the System or Subsystem Architecturesduring Design, Implementation, Manufacture, and Deployment(e.g., Installation and Configuration)
• Communicating the System or Subsystem Architectures to theirStakeholders
• Maintaining the System or Subsystem Architectures
55QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
What is a Systems Architect? 2
A Role that:
• Requires Significant:
— Training
— Experience (Apprenticeship)
— Mindset:
o Big Picture
o Generalist
— Communications Ability
• Should Probably be a Job Title
• But may Not be a Job Title
56QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Architecturally-SignificantRequirements:Requirements Driving the Architecture
57QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Architecturally-Significant Requirement
Architecturally-Significant Requirements
any Requirement that has a Significant Impact on a System /Subsystem Architecture
Architecturally-Significant Requirements typically include:
• Quality Requirements, which specify a Minimum Amount of someQuality Factor or Quality Subfactor
• Architectural Constraints
• Primary Mission Functional Requirements
Quality Requirements are often the:
• Most Important
• Least Well Engineered
58QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Requirements
Format
Under condition(s) X, the system/subsystem shall exhibit qualitycriterion Y meeting or exceeding threshold Z.
Bad Example(s)
The system shall be highly reliable, robust, safe, secure, stable, etc.
Good Example (Stability)
Under normal operating conditions*, the system shall ensure that themean time between the failure of mission critical functionality* is atleast 5,000 hours of continuous operation.
* Must be Properly defined in the Project Glossary
59QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quality Requirements – Quality Cases
Quality Model
QualityFactor
QualitySubfactor
System
defines stakeholders minimum acceptablelevel of quality of a
defines the meaning of the quality of a
Subsystem
Quality Requirement
ConditionsQuality
CriterionQuality
Threshold
shallmeet
is applicable during
QualityMeasure
is measured along ais
measuredby
Quality Goal
determines existence of
quantifies a
states stakeholders importance of achieving a
60QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Why Use QUASAR?:Quality, Requirements, and Architecture
62QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Why Use QUASAR?1
Requirements and Architecture are the first two Opportunities to makeMajor Engineering Mistakes.
Architecture and associated Architecturally-Significant RequirementsAffect:
• Project Organization and Staffing (Conway’s Law)
• Design, Implementation, Integration, Testing, and Deployment Decisions
QUASAR emphasizes using a common project-specific Quality Model:
• Quality Factors and Quality Subfactors? Quality Requirements? Quality of Architecture? Quality of System
QUASAR Ensures Specification of Architecturally-SignificantRequirements.
63QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Why Use QUASAR?2
Architecturally-Significant, Quality-Related Requirements andtheir associated Architectural Decisions Drive the System /Subsystem:
• Ultimate Quality
• Development Schedule
• Development Costs
• Sustainment Costs
• Maintainability and Upgradeability
• Acceptance and Usage by Stakeholders
64QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Why Use QUASAR?3
System Quality is Union of Relevant Quality Factors:• Availability
• Functionality
• Interoperability
• Modifiability
• Performance
• Reliability
• Robustness (Error, Failure, and Fault Tolerance)
• Safety
• Security
• Scalability
• Stability
• Testability
• etc.
65QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Why Use QUASAR?4
Determine Actual System/Subsystem Requirements andArchitecture:
• Quality
• Maturity and Completeness
• Integrity and Consistency
• Usability
Identify System/Subsystem Requirements and ArchitecturalDefects Early:
• Fix Defects Early
• Decrease Development and Maintenance Costs
• Decrease Schedule
66QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Why Use QUASAR?5
Identify (and thereby help Manage) Risks:• Requirements Risks• Architecture Risks• System Risks
Provide Acquirer/Management:
• Visibility into
• Oversight over
the System/Subsystem Requirements and Architecture
Determine Compliance :• Requirements and Architecture with Contract (Acquirer) Requirements• Architecture with System/Subsystem (Developer) Requirements
67QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Why Use QUASAR?6
Develop Consensus:
• Among Developers (e.g., Requirements and Architecture Teams)
• Between Acquirer and Developer Organization
QUASAR Helps:
• Requirements Engineers Succeed
• Architects Succeed
• Program Succeed
68QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Philosophy:Reasons to use QUASAR
70QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Assessment Philosophy1
Informal Peer Reviews are Inadequate:
• Too Informal
• Lack of Independent Expert Input
• Requirements and Architecture are too Important
Quality Requirements:
• Most important Architecturally-Significant Requirements
• Largely Drive the System Architecture
• Criteria against which the System Architecture is Assessed
71QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Assessment Philosophy2
Requirements Engineers (REs) should Make Case to Assessors:
• REs should know Stakeholder Needs and Goals
• REs should know What they Did and Why(Architecturally-Significant Requirements, Rationales, & Assumptions)
• REs should Know Where they Documented their Decisions
Architects should Make Case to Assessors:
• Architects should know Architecturally-Significant Requirements
• Architects should know What they Did and Why(Inventions, Decisions, Rationales, Trade-Offs, and Assumptions)
• Architects should know Where Documented their Decisions
72QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Assessment Philosophy3
Assessors should Actively Probe Quality Cases:• Claims Correct and Complete?
Do the Claims include all relevant Quality Factors, Quality Subfactors,Quality Goals, and Quality Requirements?
• Arguments Correct, Complete, Clear, and Compelling?Do the Arguments include all relevant Quality Factors, QualitySubfactors, Quality Goals, Quality Requirements, Inventions,Decisions, Assumptions, and Rationales?
• Arguments Sufficient?Are the Arguments Sufficient to Justify the Claims?
• Evidence Sufficient?Is the Evidence Sufficient to Support the Arguments?
• Current Point in the Schedule?Are the Claims, Arguments, and Evidence appropriate for theCurrent Point in the Schedule?
73QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Method:Phases and Tasks
75QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Method - Phases
Four Phases:
1. System Assessment Initiation (SAI)
For each Subsystem to be assessed:
2. Subsystem Requirements Assessment (SRA)
3. Subsystem Architecture Assessment (SAA)
4. System Assessment Summary (SAS)
Phase 2 and 3 may also apply to system as a whole.
76QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Phases
Subsystem RequirementsAssessment
SubsystemArchitectureAssessment
repeat for each subsystem being assessed
done
no
yes
ongoing
System Assessment
Initiation
System Assessment
Summary
77QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Methods - Tasks
Each Phase consists of same 3 Tasks:
• Preparation
• Meeting
• Follow-Through
78QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Phases and Tasks
T im e (n o t to s c a le )
…
S A SM e e t in g
P r e p .F o l lo w -
T h r o u g h
P h a s e 4 ) S y s te m A s s e s s m e n t S u m m a r y (S A S )
S u b s y s te m 1 A s s e s s m e n ts
S R AM e e tin g
P r e p .F o llo w -
T h ro u g h
P h a s e 2 ) S u b s y s te m R e q u ir e m e n ts A s s e s s m e n t (S R A )
S A AM e e t in g
P r e p .F o l lo w -
T h r o u g h
P h a s e 3 ) S u b s y s te mA r c h ite c tu re A s s e s s m e n t (S A A )
S A IM e e t in g
P r e p .F o llo w -
T h ro u g h
P h a s e 1 ) S y s te m A s s e s s m e n t In it ia t io n (S A I)
S u b s y s te m 2 A s s e s s m e n ts
S R AM e e t in g
P r e p .F o llo w -
T h r o u g h
P h a s e 2 ) S u b s y s te m R e q u ir e m e n ts A s s e s s m e n t (S R A )
S A AM e e tin g
P re p .F o llo w -
T h r o u g h
P h a s e 3 ) S u b s y s te mA r c h ite c tu r e A s s e s s m e n t (S A A )
S u b s y s te m N A s s e s s m e n ts
S R AM e e tin g
P r e p .F o llo w -
T h r o u g h
P h a s e 2 ) S u b s y s te m R e q u ir e m e n ts A s s e s s m e n t (S R A )
S A AM e e tin g
P r e p .F o llo w -
T h ro u g h
P h a s e 3 ) S u b s y s te mA r c h ite c tu r e A s s e s s m e n t (S A A )
79QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Quasar Teams and their Work Products
SystemArchitecture
SubsystemArchitectures
System-Level Architecturally-Significant
Requirements
Architectural Quality Cases
engineer the
Architecture
drive theengineer the
engineer the
makes its
make their
leads the
Assessment Team(s)
Subsystem Architecture
Teams
Top-Level Architecture
Team
SystemRequirements
Team
Subsystem Requirements
Team(s)
engineer the
are derived from the
leads the Architecturally- Significant
(e.g., Quality)Requirements
SubsystemArchitecturally-Significant
Requirements
drive the
drivethe
Requirements Quality Cases
makes its
make their
assess therequirements teams’
assess thequality of the
assess thearchitecture teams’
80QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1:System Assessment Initiation(SAI)
81QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
System Assessment Initiation (SAI)
Subsystem RequirementsAssessment
SubsystemArchitectureAssessment
repeat for each subsystem being assessed
done
no
yes
ongoing
System Assessment
Initiation
System Assessment
Summary
82QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Topics
System Assessment Initiation (SAI) Phase:
• Objectives
• Principles
• Challenges
• Tasks:
— Preparation
— Meeting
— Follow-Through
• Primary Work Products
• Team Memberships
• Lessons Learned
83QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Objectives
Prepare Teams for Requirements and Architecture Assessments
Develop Consensus:
• Scope of Assessments
• Schedule Assessments
• Tailor the Assessment Method and associated Training Materials
Produce and Publish Meeting Outbrief and Minutes
Manage Action Items
Capture Lessons Learned
Tailor/Update QUASAR Method and Training Materials
84QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Principles
It is Important to:
• Develop Consensus among Teams
• Scope the Assessment to meet Project-Specific Needs andResources
• Tailor the Assessment Method to meet specific Needs of theOverall Assessment
Subsystem Assessments must be scheduled to EnsureAvailability of the:
• Requirements and Architecture
• Required Resources (e.g., people and funding)
85QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Challenges1
Acquirer and Development Organizations may Disagree as tothe:
• Need to Independently Perform Quality Assessments
• Relative Importance of Quality Factors, Quality Subfactors, andRelated Goals and Requirements
It can be Difficult to reach Consensus on the Scope of theAssessments in terms of the:
• Number and Identity of Subsystems to Assess
• Number and Identity of Quality Factors and Quality Subfactors
• Tailoring of the QUASAR Method
86QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Challenges2
Quality Assessments of System and Subsystem Architecturesand their Architecturally-Significant Requirements may not havebeen included in the Project:
• Request for Proposal (FRP)
• Contract
• Budget and Schedule
It is often very Difficult to obtain Commitment of Resources:
• Availability of Requirements Engineers and Systems Architects
• Availability of Assessors with Adequate Experience and Expertise
• Consensus on Schedule
• Budget Funding to Pay for the Assessment
87QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Preparation Task
• Management Team staffs Assessment Team
• Process and Training Teams train Assessment Team
• Assessment Team identifies:
• System Requirements Team
• System Architecture Team
• Process and Training Teams train System Requirementsand Architecture Teams
• Assessment, Requirements, and Architecture Teamscollaborate to Organize SAI Meeting(i.e., Attendees, Time, Location, Agenda)
88QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Meeting Task
• Assessment, System Requirements, and System ArchitectureTeams Collaborate to determine Assessment Scope:
• Quality Factors and Quality Subfactors underlying Assessment
• Architecturally-Significant Product and Process Requirements
• Subsystems/Architectural Elements/Focus Areas to Assess(Number and Identity)
• Assessment Resources (e.g., Time, Budget, and Staffing)
• Teams Collaborate to develop Initial Assessment Schedule
• Teams Collaborate to tailor QUASAR Method
• Assessment Team captures Action Items
89QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Follow-Through Task
• Assessment Team develops and presents Meeting Outbrief
• Assessment Team develops, reviews, and distributesMeeting Minutes
• Assessment/Process/Training Teams tailor, internally review,and distribute:
• QUASAR Procedure, Standards, and Templates
• QUASAR Training Materials
• Assessment Team distributes Assessment Schedule
• Teams obtain Needed Resources
• Assessment Team captures Lessons Learned
• Assessment Team Manages Action Items
90QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Work Product Flow
SAI Minutes
SAI Outbrief
QUASARTraining Materials
Lessons Learned
Process Team
Training Team
SystemAssessment
Team
1
*
2
35
*
4
QUASARStds & Procedures
6
RecommendationsSystem
ArchitectureTeam
SystemRequirements
Team
Questions/Answers
Action Item List
6
1
91QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Work Products
Preparatory Materials Meeting
OutbriefMeeting Minutes
AssessmentScope
Assessment Schedule
Method Tailoring
QUASARTrainingMaterials
QUASARStandards & Procedures
Meeting Notes
Lessons Learned
Legend
influencesaggregation
assessor work productdeveloper work product
92QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Team Memberships1
Assessment Team (Assessors):
• Assessment Team Leader
• Meeting Facilitator
• Subsystem Liaisons to:
— Requirements Team
— Architecture Team
• Subject Matter Experts (SMEs)
— Application Domain
— Specialty Engineering
• Acquisition/Customer Observers
• Scribe
93QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Team Memberships2
System Requirements Team (Requirements Engineers):
• Chief System Requirements Engineer
• System Requirements Engineers
• Subsystem Requirements Engineers
System Architecture Team (Architects):
• Chief System Architect
• System Architects
• Subsystem Architects
94QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Lessons Learned1
Ensure Appropriate Team Memberships (e.g., Authority)
Ensure Adequate Resources (e.g., Staffing, Budget, and Schedule)
Obtain Consensus on:
• Assessment Objectives and Scope
• Definitions (e.g., of Quality Factors, Subfactors, and Cases)
Provide Early Training:
• Method Training(QUASAR, Requirements Engineering, and Architecting)
• System/Subsystem Training(Requirements and Architecture)
95QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 1) SAI – Lessons Learned2
QUASAR assessments should be Organized according to aQuality Model that defines Quality Factors (a.k.a., attributes,“ilities’) and their Quality Subfactors such as:
• Availability
• Interoperability
• Performance
— Jitter, Response Time, Schedulability, and Throughput
• Portability
• Reliability
• Safety
• Security
• Usability
96QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2:Subsystem RequirementsAssessment (SRA)
97QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Subsystem Requirements Assessment(SRA)
Subsystem RequirementsAssessment
SubsystemArchitectureAssessment
repeat for each subsystem being assessed
done
no
yes
ongoing
System Assessment
Initiation
System Assessment
Summary
98QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Topics
System Requirements Assessment (SRA) Phase:
• Objectives
• Principles
• Challenges
• Tasks:
— Preparation
— Meeting
— Follow-Through
• Primary Work Products
• Team Memberships
• Lessons Learned
99QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Objectives
Assess Quality and Maturity of the Architecturally-Significant,Quality-Related, Subsystem Requirements including adequacy to:
• Drive the Subsystem Architecture
• Form Foundation for Subsystem Architecture Assessment
Ensure Subsystem Architecture Team will be Prepared to Supportthe coming Subsystem Architecture Quality Assessment
Produce and Publish Meeting Outbrief and Report
Manage Action Items
Capture Lessons Learned
Update QUASAR Method and associated Training Materials
100QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Principles1
Not all Requirements are Architecturally-Significant.
Quality-Related Requirements:
• Are typically Major Drivers of the System Architecture.
• Should be Unambiguous, Feasible, Complete, Consistent, Mandatory,Verifiable, Validatable, etc.
• Should Not Unnecessarily Constrain the Architecture.
Quality Requirements should Specify a Minimum Required Amountof some Quality Factor or Quality Subfactor.
101QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Principles2
Quality Requirements should be Organized according to a QualityModel that defines Quality Factors (a.k.a., attributes, “ilities’) andtheir Quality Subfactors such as:
• Availability
• Interoperability
• Performance
— Jitter, Response Time, Schedulability, and Throughput
• Portability
• Reliability
• Safety
• Security
• Usability
102QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Principles3
Different Quality Factors are Important for Different Subsystems:• Performance is Paramount for Real-Time Subsystems.• Security is more Important for other Subsystems.
Engineering Quality Requirements requires Significant Effort andResources (it cannot be accomplished during a short meeting).
Engineering Architecturally-Significant Requirements is theResponsibility of the Requirements Team –Not the Architecture Team and Not the Assessment Team.
• Architects and Assessors are Not Qualified to Engineer QualityRequirements.
• Many Stakeholders have Different and Inconsistent Quality Needs.• Architecture Assessment Time is Too Late to be Engineering Quality
Requirements.
103QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Challenges1
Many Requirements Engineers are not taught how to EngineerNon-functional Requirements including Quality Requirements.
Although popular, Use Case Modeling is not very Effective forEngineering Quality Requirements.
Quality Requirements often require the Input from SpecialtyEngineering Teams (e.g., Reliability, Safety, and Security), who arenot often adequately involved during Requirements Engineering.
Quality Goals are often Mistakenly Specified as QualityRequirements.
The resulting Architecturally-Significant Requirements are typically:• Incomplete
(missing important Relevant Quality Factors and Subfactors)
• Of Poor Quality (lack important characteristics)
104QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Challenges2
The typical Quality of Derived and Allocated Architecturally-Significant Requirements is Poor:
• Requirements are often Ambiguous.
— “The system shall be safe and secure.”
• Requirements Rarely Specify Thresholds on relevant QualityMeasurement Scales.
— “The system shall have adequate availability.”
• Requirements are often mutually Inconsistent.
— Security vs. usability, performance vs. reliability.
• Many Requirements are Infeasible (or at least Impractical) if takenliterally.
— “The system shall be available 24/7 every day of the year.”
— “The system shall have 99.9999 reliability.”
105QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Challenges3
Requirements are often Unstable.
Specialty Engineering Requirements (e.g., reliability, safety,security) are Often Documented Separately from the FunctionalRequirements.
The Architecturally-Significant Requirements are oftenImproperly Prioritized for Implementation.
The Requirements Engineers often do Not Understand how toPrepare for a Subsystem Assessment.
• Too busy• Not trained• No standards exist• Bias against assessments/audits
106QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Challenges4
Managers believe Schedule Pressures do Not allow Time forRequirements Assessments.
Subsystem Requirements Engineers may Not Understand how to give theAssessment Team what they need to assess the Requirements:
• Claims
• Arguments including Decisions, Trade-Offs, Rationales, andAssumptions
• What is the proper Evidence?
— Official program documentation
— Not plans and procedures
— Not hastily produced PowerPoint slides
107QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Preparation Task
• Process/Training Team trains the Subsystem Requirementsand Architecture Teams significantly prior to the SRA Meeting.
• Subsystem Requirements and Subsystem Architecture Teamsprovide Preparatory Materials to the Subsystem Assessment Teamsignificantly prior to the SRA Meeting:
• Summary Presentation Materials
• Requirements Quality Cases(including electronic access to evidentiary materials)
• Example of Planned Architectural Quality Case
• Subsystem Assessment Team reviews these Preparatory Materialsprior to the SRA Meeting.
108QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Meeting Task
• Subsystem Requirements Team presents:• System Overview• Requirements Overview• Requirements Quality Cases
• Subsystem Assessment Team assesses Quality and Maturity ofRequirements:
• Completeness of Quality Cases
• Quality of Quality Cases
• Subsystem Architecture Team presents Example ArchitecturalQuality Case
• Subsystem Assessment Team recommends Improvements
• Subsystem Assessment Team manages Action Items
109QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Follow-Through Task
Subsystem Assessment Team:• Develops Consensus Regarding Subsystem Requirements Quality
• Produces, Reviews, and Presents Meeting Outbrief
• Produces, Reviews, and Publishes Requirements Assessment Report
• Captures Lessons Learned
• Manages Action Items
Subsystem Requirements Team:Addresses Risks Raised in Requirements Assessment Report
Process Team:Updates Assessment Method (e.g., Standards and Procedures)
Training Team:Updates Training Materials (if appropriate)
110QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Work Product Workflow
S ubsystemA rchitecture
Team
S ubsystemR equirem ents
Team
S ubsystemA ssessm ent
Team
5
6
*
Lessons Learned
P rocess Team
Train ing Team
7
Q U A S A RTraining M ateria ls
Q U A S A RS tds & P rocedures
S R A R eport Tem plate
S R A P resentation M ateria ls
R equirem ents Q uality C ases and
D raft R epresentative A rchitec turalQ uality C ase
Q uestions /A nsw ers
R ecom m endations
A ction Item L ist
S R A R eport
S R A O utbrief
1
1
3
*
8
8
8S R A P repara tory
M ateria ls
2
4
6
1
111QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Work Products
SRA Preparatory Materials
SRA Presentation
Materials
Assessor Notes
Requirements Support Matrix
Models
ClaimsAssociated Arguments
Supporting Evidence
Diagrams
DocumentsSRA Assessment
Outbrief
SRA Assessment Report
System / SubsystemOverview
Text
RequirementsOverview
RequirementsQuality Cases
Meeting Agenda with Location
RqmtsQuality Case
Diagrams
Draft Architecture Quality Case
Legend
influencesaggregationspecialization
assessor work productRE work product
Action Item List
Lessons Learned
112QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Team Memberships
Subsystem Requirements Team:
• Subsystem Requirements Engineers
• Subject Matter Experts (if appropriate):
— Specialty Engineering Experts
— Application Domain Experts
Subsystem Architecture Team:
• Subsystem Architects
• Subject Matter Experts (if appropriate):
— Specialty Engineering Experts
— Application Domain Experts
113QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Assessment Team
Subsystem Assessment Team:
• Assessment Team Leader
• Meeting Facilitator
• Subsystem Liaisons
• Subject Matter Experts
• Acquisition Observers
• Scribe
Must include members having Experience and Expertise in:• Requirements Engineering including Quality Requirements• QUASAR (with all members having been trained in the method)• Subsystem Application Domain(s)
(e.g., avionics, sensors, telecommunications, or weapons)
114QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SRA – Lessons Learned
Select, Define, and Prioritize Quality Factors and QualitySubfactors (e.g., as Critical, Important, Desirable, or Relevant).
Concentrate on Quality-related Requirements(i.e., Merely Listing Quality Factors is Not Sufficient).
Architecturally-Significantly Quality Requirements must havecertain Properties.
Iterative/Incremental Development implies Iterative/IncrementalRequirements Assessments.
Hold Meeting Sufficiently Early for Quality Requirements to Drivethe Architecture.
115QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3:Subsystem ArchitectureAssessment (SAA)
116QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Subsystem Architecture Assessment(SAA)
Subsystem RequirementsAssessment
SubsystemArchitectureAssessment
repeat for each subsystem being assessed
done
no
yes
ongoing
System Assessment
Initiation
System Assessment
Summary
117QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Topics
System Architecture Assessment (SAA) Phase:
• Objectives
• Principles
• Challenges
• Tasks:
— Preparation
— Meeting
— Follow-Through
• Primary Work Products
• Team Memberships
• Lessons Learned
118QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Objectives
Assess Quality of Subsystem Architecture in terms of:
• Architectures Support for its Derived and Allocated Architecturally-Significant Requirements
• Architectural Quality Cases
119QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Principles
The Subsystem Architects should know:• What Quality Goals and Requirements drove the Development of
their Architectures.
• What Architectural Decisions they made and Why.
• Where they documented their Architectural Decisions.
The Subsystem Architects should already have Documented thisInformation as a Natural Part of their Architecting Method
Little New Documentation should be Necessary for the SubsystemArchitects to make their Cases to the Subsystem AssessmentTeam.
The Subsystem Architects are Responsible for making their ownCases that their Architectures Sufficiently Support their Derivedand Allocated Quality Requirements.
120QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Challenges1
Architects may not have developed Quality Cases as a NaturalPart of their Architecting Process:
• Architectural Documentation are typically not organized by QualityFactors.
• Quality Case Evidence is often buried in and scattered throughoutmassive amounts of architectural documentation.
• Architectural Models (e.g., UML) often do not address Support forQuality Requirements.
Architecture Assessments may not be:
• Mandated by Contract or Development Process
• Scheduled and Funded
121QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Challenges2
Managers feel Schedule Pressures do not allow time forArchitecture Assessments.
Architects often do not understand how to prepare for aSubsystem Assessment:
• Too Busy• Not Trained• No Standards Exist• Bias against Assessments/Audits
Architecturally-Significant Requirements are Rarely WellEngineered.
Architectural Documentation often varies Widely in Quality andCompleteness.
122QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Challenges3
Architecturally-Significant Requirements (esp. QualityRequirements) are rarely traced to the Architectural Elements thatCollaborate to Implement Them.
Architectures are rarely assessed to Determine if they truly meettheir Poorly-Specified Architecturally-Significant Requirements.
123QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Preparation Task
• Subsystem Assessment Team provides Assessment Checklist
• Subsystem Architecture Team gathers (generates) and makesAvailable Preparatory Materials:• Subsystem Architecture Overview
• Updated Quality Requirements
• Quality Cases including Claims, Arguments, and Evidence
• Subsystem Architecture Team gathers (generates) and makesAvailable Presentation Materials
• Subsystem Assessment Team:• Reads Materials
• Generates RFIs and RFAs
• Teams collaborate to Organize Assessment Meeting(Attendees, Time, Location, Agenda, Invitation)
124QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Meeting Task
• Subsystem Architecture Team:
• Introduces Subsystem Architecture(e.g., Purpose, Location, Context, and Major Functions)
• Briefly reviews Architecturally-Significant Requirements
• Briefly introduces Subsystem Architecture(e.g., Most Important Architectural Components, Relationships,Decisions, Mechanisms, Trade-Offs, and Assumptions)
• Present Architectural Quality Cases(i.e., Claims, Arguments, and Evidence)
• Subsystem Assessment Team:
• Probes Architecture (Architectural Quality Case by Quality Case)
• Manages Action Items
125QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Follow-Through Task
Subsystem Assessment Team:• Develops Consensus regarding Subsystem Architecture Quality
• Produces, reviews, and presents Meeting Outbrief
• Produces, reviews, and publishes Architecture Assessment Report
• Captures Lessons Learned
• Manages Action Items
Subsystem Architecture Team:Addresses Risks Raised in Architecture Assessment Report
Process Team:Updates Assessment Method (e.g., Standards and Procedures)
Training Team:Updates Training Materials (if appropriate)
126QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Work Product Workflow
Questions/Answers
SubsystemArchitecture
Team
SubsystemAssessment
Team
5
4
5
*
*
3
Recommendations
Action Item List
SAA Report
SAA Outbrief
QUASARTraining Materials
QUASARStds & Procedures
SRA Report Template
SAA Presentation Materials
Introductory Material and Architectural
Quality Cases
SAA Preparatory Materials
Lessons Learned6
Process Team
Training Team
1
1
7
7
7
2
1
127QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Primary Work Products
SAA Presentation
Materials
Architecture Support Matrix
Models
ClaimsAssociated Arguments
Supporting Evidence
Diagrams
DocumentsSAA Assessment
Outbrief
SAA Assessment Report
Architecturally- Significant
Requirements Review
Text
ArchitectureOverview
Architectural Quality Cases
Legend
influencesaggregationspecialization
assessor work productarchitect work product
SAA Preparatory Materials
ArchitectureQuality Case
Diagrams
Meeting Agenda with Location
Assessor Notes
Action Item List
Lessons Learned
128QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAA – Team Memberships
Subsystem Architecture Team:
• Subsystem Architects
• Subject Matter Experts (if appropriate):
— Specialty Engineering Experts
— Application Domain Experts
129QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Subsystem Assessment Team
Subsystem Assessment Team:
• Assessment Team Leader
• Meeting Facilitator
• Subsystem Liaisons
• Subject Matter Experts
• Scribe
Must include members having Experience and Expertise in:• System Architecting and System Architectures
• QUASAR (with all Members having been trained in the Method)
• Subsystem Application Domain(s) such as Avionics, Sensors,Telecommunications, or Weapons
130QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SAA – Lessons Learned1
Iterative/Incremental Development implies Iterative/IncrementalArchitecture Assessments.
Provide Initial Overview of Subsystem Architecture:
• Keep Overview Short
• Present Most Important Architectural Decisions, Trade-Offs betweenQuality Factors and Subfactors, and Assumptions
• Mount Diagrams on Meeting Room Walls (and Leave Them Up!)
• Highlight Primary Architectural Decisions
Focus on Assessing the Existing Architecture
Avoid a “Trust Me” Mentality
131QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SAA – Lessons Learned2
Organize Presentation by:
• Quality Factors and Quality Subfactors
• Architectural Components within the Subsystem
Do Not Restrict Evidence to Scenarios.
Present Both Logical (Functional) Architecture and PhysicalArchitectural Structure.
Keep Evidence Presented and Requested within AssessmentScope.
Ensure Availability of Actual Architects.
Architects must have Electronic Access to Evidence to presentExisting, Official Documentary Evidence.
132QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 2) SAA – Lessons Learned3
Take Development Cycle, Project Schedule, and ArchitecturalMaturity into Account.
Emphasize Assessment Results over RecommendingArchitectural Improvements.
Ensure Reasonable Assessment Size and Schedule.
Ensure Adequate Pre-Meeting Preparation.
All Architectural Tiers are not Equal:
• Size, Complexity, Criticality, and Quality Factors/Subfactors
• Apply Different Emphasis at Different Levels of the Hierarchy.
Differentiate Architecture from Design.
Use Scenarios for Testing rather than introducing the Architecture.
133QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4:System Assessment Summary(SAS)
134QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
System Assessment Summary (SAS)
Subsystem RequirementsAssessment
SubsystemArchitectureAssessment
repeat for each subsystem being assessed
done
no
yes
ongoing
System Assessment
Initiation
System Assessment
Summary
135QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Topics
System Assessment Summary (SAS) Phase:
• Objectives
• Principles
• Challenges
• Tasks:
— Preparation
— Meeting
— Follow-Through
• Primary Work Products
• Team Memberships
• Lessons Learned
136QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Objectives
Collect previous Subsystem Architecture Assessment Results
Create System Architecture Assessment Summary Results
Capture Method Lessons Learned
Update Assessment Method and Training Materials
137QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Principles
All Subsystems are Not Equally Important.
All Quality Factors and Subfactors are Not Equally Important forDifferent Subsystems.
Different Stakeholders want Different Summaries.
138QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Challenges
How should Subsystem Findings be Summarized without endingup Comparing Apples and Oranges?
• Across Subsystems:
— Average Subsystem Quality
— Worst Subsystem Quality
— Union of Subsystem Qualities (i.e., show all subsystems)
• By Quality Factor and Quality Subfactor:
— Average Value
— Worst Value
— Union of Values (i.e., show all values)
Executive management may Demand Simplistic Single NumberSummary of System Requirements and Architecture Quality.
139QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Preparation Task
System Assessment Team:
• Collects Subsystem Assessment Results
• Summarizes Subsystem Assessment Results
— Develops Subsystem Support Matrix
• Identifies Primary Stakeholders
• Produces, Reviews, and Distributes:
— System Quality Assessment Summary Report
— Preparatory Materials
— Meeting Agenda
• Organizes Meeting
140QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Meeting Task
System Assessment Team:
• Restates Assessment Objectives
• Summarizes QUASAR Method
• Summarizes Assessment Scope
• Summarizes Quality of System and Subsystem Requirements
• Summarizes Quality of System and Subsystem Architectures
• Solicits Feedback
System Requirements and Architecture Teams:
Provide Feedback
141QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Follow-Through Task
System Assessment Team:• Develops Consensus regarding System Requirements and
Architecture Quality
• Produces, reviews, and publishes System Assessment Report
• Captures Lessons Learned
• Manages Action Items
System Requirements and Architecture Teams:Address Risks Raised in System Assessment Report
Process Team:Updates Assessment Method (e.g., Standards and Procedures)
Training Team:Updates Training Materials (if appropriate)
142QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Work Product Workflow
System Quality Assessment
Summary Report
Action Item List
Lessons Learned
Process Team
Training Team
SubsystemAssessment
Team
3
4
QUASARTrainingMaterials
*
*
5
5QUASAR
Standards & Procedures
1
2
Recommendations
System Requirements
Team
SystemArchitecture
Team
System Assessment Summary Briefing
Materials2
1
SystemManagement
Team
Questions/Answers
143QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Work Products
Preparatory Materials
System Quality Assessment
Summary Report
RequirementsQuality
Architecture Quality
Lessons Learned
Assessment Objectives
QUASAR Method
QUASAR Results
Action Item List
QUASAR Training Materials
QUASAR Standards,
Procedures, & Templates
System Assessment Summary Briefing
Materials
Legend
influencesaggregation
assessor work product
144QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAS – Team Memberships
System Requirements Team (Requirements Engineers):
• System Chief Requirements Engineer
• System Requirements Engineers
• Subsystem Requirements Engineers
System Architecture Team (Architects):
• System Chief Architect
• System Architects
• Subsystem Architects
System Management Team:
• System Program Manager
• System Technical Leader
145QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 3) SAS – Team Memberships
System Assessment Team:
• Assessment Team Leader
• Meeting Facilitator
• Subsystem Liaisons
• Subject Matter Experts
• Scribe
146QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Phase 4) SAS – Lessons Learned
A Single Overall Summary Assessment Result can be OverlySimplistic.
Identify Current Problem/Risk Areas so that they can be Fixed.
System Assessment Summation should probably be Ongoing aspart of an Incremental, Iterative Development Cycle.
147QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Benefits:What you can expect to gain
149QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Benefits1
Provides Acquirer Visibility into (and supports oversight of) theQuality of the Requirements and Architecture
Supports Certification and Accreditation
150QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Benefits2
Supports Process Improvement:
• Solves Major Requirements and Architecture Problems
Provides Flexibility:
• Any Effective Requirements Engineering and Architecting Methods
• Uses Existing Requirements and Architecture Work Products(i.e., almost no new work products required)
• Any Subsystems based in Need and Risk(i.e., fits any system size, budget, schedule, and tier)
• Any Quality Factors and Quality Subfactors
151QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR:Today and Tomorrow
153QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Today
In-use on Largest DoD Acquisition Program
QUASAR Version 1 Handbook Publishedhttp://www.sei.cmu.edu/publications/documents/06.reports/06hb001.html
Provided as SEI Service by Acquisition Support Program (ASP)
Tutorials at Conferences
154QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Handbook
Intended Audiences:• Acquisition Personnel• Developers (Architects and Requirements Engineers)• Subject Matter Experts (domain, specialty engineering)• Consultants• Trainers
Objectives:• Completely Document the QUASAR Method (Version 1)• Enable Readers to start using QUASAR
Description:• Very Complete• Too Comprehensive to be Good First Introduction
155QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Tomorrow – Technical Plans
Quality Factors across Multiple Subsystems:
• Multiple Cross-Cutting Structures and Models
• Multiple Subsystems Collaborate to Achieve Quality Requirements
Development of Catalog of Quality Factor-Specific ArchitecturalStyles, Patterns, and Mechanisms to use as Standardized QualityCase Arguments
Improve Objective Determination of “Sufficient Quality”
Expand Quality Cases Beyond Requirements and Architecture
156QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
QUASAR Tomorrow - Productization
More Conference Tutorials and Classes
Expanded QUASAR Training Materials
QUASAR Articles
Use and Validation on more Programs
QUASAR Book
157QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
How the SEI Can Help You
QUASAR is Ready for Use Now.
QUASAR Handbook and Training Materials can be downloadedfrom SEI Website.
The SEI Acquisition Support Program (ASP) offers QUASAR as aService:
• Consulting and Training
• Facilitation of QUASAR Assessments
• Recommended RFP and Contract Language
158QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Contact Information
For more information, contact:
Donald Firesmith
Acquisition Support Program
Software Engineering Institute
159QUASAR TutorialDonald Firesmith, 28 March 2007© 2007 Carnegie Mellon University
Software Engineering Institute CarnegieMellon
Software Engineering Institute I CarnegieMellon
Top Related