CPSA Architectural Goals and Constraints 4 — Questions and Answers
Question 1: An architect is told 'the system must use the company's existing Oracle database.' How should this be treated in architecture documentation?
- As a fixed technical constraint that bounds all data-related design decisions (Correct answer)
- As a recommendation that can be overridden with sufficient justification
- As a functional requirement that defines what the system must do
- As a non-functional requirement with a measurable threshold
Correct answer: As a fixed technical constraint that bounds all data-related design decisions
Mandated technology choices from the organization are fixed technical constraints that must be accepted and documented as non-negotiable boundaries.
Question 2: What is the consequence of ignoring the tension between modifiability and performance goals during initial architecture design?
- Costly redesign when performance optimizations break the modular structure (Correct answer)
- The system automatically resolves the tension during deployment
- Performance always wins because it is more important than modifiability
- Modifiability becomes irrelevant once the system is in production
Correct answer: Costly redesign when performance optimizations break the modular structure
Ignoring goal tensions early leads to expensive rework when performance-driven tight coupling conflicts with the modularity needed for future modifications.
Question 3: In the context of CPSA, what is a 'quality scenario'?
- A concrete, measurable description of how a quality attribute must be exhibited under specific conditions (Correct answer)
- A test case that validates functional behavior of a component
- A user story describing business value from the end-user perspective
- A performance benchmark run against a deployed system
Correct answer: A concrete, measurable description of how a quality attribute must be exhibited under specific conditions
A quality scenario specifies stimulus, source, environment, artifact, response, and response measure to make quality requirements concrete and testable.
Question 4: Which factor most often causes architectural goals to conflict with each other in practice?
- Different stakeholders optimizing for different success criteria (Correct answer)
- Insufficient programming experience on the development team
- Lack of version control in the development process
- Inadequate hardware resources in the production environment
Correct answer: Different stakeholders optimizing for different success criteria
Goal conflicts typically arise because stakeholders with different roles—security teams, product owners, operations—each prioritize quality attributes aligned with their own concerns.
Question 5: A startup requires rapid feature delivery, accepting more technical debt. How does this business constraint affect architectural decisions?
- It favors simpler, less modular designs that speed delivery over long-term maintainability (Correct answer)
- It mandates microservices for maximum team independence
- It requires formal architecture reviews before every commit
- It forces adoption of the most mature and proven technology stack
Correct answer: It favors simpler, less modular designs that speed delivery over long-term maintainability
Time-to-market pressure as a business constraint shifts the tradeoff toward simpler designs that reduce initial development time even at the cost of future modifiability.
Question 6: Which practice ensures that architectural constraints remain visible and are not accidentally violated during development?
- Automated architecture fitness functions and compliance checks in CI/CD pipelines (Correct answer)
- Verbal communication of constraints in team stand-up meetings
- Printing constraints on a poster in the team room
- Including constraints only in the final project report
Correct answer: Automated architecture fitness functions and compliance checks in CI/CD pipelines
Automated fitness functions verify architectural constraints continuously, catching violations as soon as code is committed rather than during late-stage reviews.
Question 7: What distinguishes a 'soft goal' from a 'hard constraint' in software architecture?
- A soft goal is a desired quality that can be traded off; a hard constraint is a non-negotiable boundary (Correct answer)
- A soft goal applies only to user interfaces; a hard constraint applies to databases
- A soft goal is defined by developers; a hard constraint is defined by end users
- A soft goal requires more documentation than a hard constraint
Correct answer: A soft goal is a desired quality that can be traded off; a hard constraint is a non-negotiable boundary
Soft goals represent desirable qualities where tradeoffs are acceptable, while hard constraints are absolute boundaries that the architecture must never violate.
CPSA Architectural Goals and Constraints 4
An architect is told 'the system must use the company's existing Oracle database.' How should this be treated in architecture documentation?