- activity-diagram 4
- adr 3
- assumption 1
- atam 2
- blackbox 4
- bpmn 1
- building-block 30
- business-context 3
- cluster 2
- cohesion 1
- concept 16
- constraint 5
- context 19
- criteria 2
- decision 11
- deployment-view 11
- domain 3
- essential 24
- example 3
- external-interface 7
- functional-requirement 6
- glossary 7
- goal 1
- hardware 3
- hierarchy 8
- i18n 1
- infrastructure 2
- interface 5
- iso-25010 2
- lean 30
- mapping 6
- plantUML 2
- port 1
- problem 6
- quality 18
- quality-goal 5
- quality-scenario 7
- quality-tree 4
- requirement 22
- risk 7
- runtime-scenario 5
- runtime-view 12
- scenario 21
- sequence-diagram 2
- solution-strategy 7
- source-code 11
- stakeholder 10
- table 2
- technical-context 5
- technical-debt 1
- test 2
- thorough 9
- tooling 1
- translation 1
- view 1
- whitebox 4
activity-diagram
- Tip 1-6: Use activity diagrams to describe functional requirements!
- Tip 1-9: Use (semi) formal text to describe functional requirements!
- Tip 6-7: Use activity diagrams with swimlanes to describe or specify runtime scenarios!
- Tip 6-8: Use activity diagrams with partitions to describe or specify runtime scenarios!
adr
- Tip 9-8: Decisions should have a timestamp!
- Tip 9-9: Follow the _suggestions for good ADRs_
- Tip 9-10: Use lightweight tooling to support creation of ADRs
assumption
atam
- Tip 10-8: Use (quality) scenarios for architecture analysis or evaluation!
- Tip 11-3: Identify problems or risks by qualitative evaluation!
blackbox
- Tip 5-1: Use common structures for sections of the building block view!
- Tip 5-5: Describe the responsibility or purpose of every (important) blackbox!
- Tip 5-6: Hide the inner workings of blackboxes!
- Tip 5-7: Use tables to efficiently document/specify blackboxes!
bpmn
building-block
- Tip 5-1: Use common structures for sections of the building block view!
- Tip 5-2: Organize the building block view hierarchically!
- Tip 5-3: Always describe level-1 of the building block view ('Level-1 is your friend')!
- Tip 5-4: Ensure consistency of external interfaces to level-1
- Tip 5-5: Describe the responsibility or purpose of every (important) blackbox!
- Tip 5-6: Hide the inner workings of blackboxes!
- Tip 5-7: Use tables to efficiently document/specify blackboxes!
- Tip 5-8: Justify every whitebox structure!
- Tip 5-9: Use runtime views to explain or specify whiteboxes!
- Tip 5-10: Use crosscutting concepts to describe or specify similarities in building blocks!
- Tip 5-11: Show multiple levels of the building block view!
- Tip 5-12: Refine building-blocks consistently!
- Tip 5-13: Explain the mapping of source-code to building blocks!
- Tip 5-14: Explain where to find the source code of your building blocks!
- Tip 5-15: Align the mapping of source-code to building-blocks along the directory and file structure!
- Tip 5-16: Map building blocks according to modularization constructs of your programming language!
- Tip 5-17: 'Cohesion' shall be the primary driver when creating architecture building blocks!
- Tip 5-18: Ensure **every** piece of source code can be located in the building block view!
- Tip 5-19: In exceptional cases include third-party software in the building block view!
- Tip 6-10: Use both small and large building blocks in scenarios!
- Tip 5-20: Clearly indicate third-party elements in the building block view!
- Tip 5-21: Describe or specify internal interfaces with minimal effort!
- Tip 5-22: Document or specify interfaces with unit-tests!
- Tip 5-23: Document or specify interfaces with runtime scenarios!
- Tip 5-24: Use building-block level-1 for **other** information!
- Tip 5-25: If useful, refine several building blocks at once!
- Tip 5-26: Make the origin of lower-level building blocks explicit!
- Tip 5-27: Refine only a few building blocks!
- Tip 5-28: Explain concepts instead of building blocks!
- Tip 8-11: (Hyper)Link between Building Blocks and Concepts!
business-context
- Tip 3-10: Differentiate business and technical context!
- Tip 3-11: In the business context, show data flows (instead of dependencies)!
- Tip 3-17: Combine business context with technical information!
cluster
- Tip 1-4: Create an overview by grouping or clustering requirements!
- Tip 3-7: If many external systems are involved, aggregate (cluster) them by explicit criteria!
cohesion
concept
- Tip 4-1: Explain the solution strategy as compact as possible (e.g. as list of keywords)!
- Tip 4-2: Describe the solution approaches as a table!
- Tip 4-4: In the solution strategy, refer to concepts, views or code!
- Tip 8-1: Explain the Concepts!
- Tip 8-2: Concepts are approaches, rules, principles, tactics, strategies etc...
- Tip 8-3: Restrict documentation of concepts to the most important topics!
- Tip 8-4: In concepts, explain HOW it works!
- Tip 8-5: Document business or domain models!
- Tip 8-6: Combine business or domain models with the glossary!
- Tip 8-7: Document (at least) the (business or domain) data model!
- Tip 8-8: Document concepts with source code!
- Tip 8-9: Document decisions instead of concepts!
- Tip 5-10: Use crosscutting concepts to describe or specify similarities in building blocks!
- Tip 8-10: Use the collection from arc42 as checklist for concepts!
- Tip 5-28: Explain concepts instead of building blocks!
- Tip 8-11: (Hyper)Link between Building Blocks and Concepts!
constraint
- Tip 2-1: Consider the constraints of other systems within the organization!
- Tip 2-2: Clarify the consequences of constraints!
- Tip 2-3: Document organizational constraints!
- Tip 2-4: Document design and development constraints!
- Tip 2-5: Differentiate different categories of constraints!
context
- Tip 3-1: Explicitly demarcate your system from its environment!
- Tip 3-2: Show the context as diagram!
- Tip 3-3: Combine the context diagram with a table!
- Tip 3-4: Explicitly indicate risks in the context!
- Tip 3-5: Restrict the context to an overview, avoid too many details!
- Tip 3-6: Simplify the context by categorization!
- Tip 3-7: If many external systems are involved, aggregate (cluster) them by explicit criteria!
- Tip 3-8: Aggregate (cluster) similar neighbour systems with ports!
- Tip 3-9: Show all (all!) external interfaces!
- Tip 3-10: Differentiate business and technical context!
- Tip 3-11: In the business context, show data flows (instead of dependencies)!
- Tip 3-12: Show external influences in the context!
- Tip 3-13: Show transitive dependencies in the context!
- Tip 3-14: Pay attention to quality requirements at external interfaces!
- Tip 3-15: Show the technical context (in case hardware is central to your system)!
- Tip 3-16: Use the technical context to describe protocols or channels!
- Tip 3-17: Combine business context with technical information!
- Tip 3-18: Explain the relationship between domain interfaces and their technical realization!
- Tip 3-19: Defer technical context to the deployment view!
criteria
- Tip 3-7: If many external systems are involved, aggregate (cluster) them by explicit criteria!
- Tip 9-2: Document decision criteria!
decision
- Tip 7-2: Explain hardware and infrastructure decisions!
- Tip 9-1: Document only architecturally relevant decisions!
- Tip 9-2: Document decision criteria!
- Tip 9-3: Provide reasons for important decisions!
- Tip 9-4: Document decisions as mind-map or as table!
- Tip 9-5: Document decisions as `Architecture Decision Record` (ADR)!
- Tip 9-6: Document rejected alternatives!
- Tip 9-7: Document decisions informally as a blog (RSS-feed)!
- Tip 9-8: Decisions should have a timestamp!
- Tip 9-9: Follow the _suggestions for good ADRs_
- Tip 9-10: Use lightweight tooling to support creation of ADRs
deployment-view
- Tip 7-1: Document your technical infrastructure (hardware)!
- Tip 7-2: Explain hardware and infrastructure decisions!
- Tip 7-3: Document the various environments!
- Tip 7-4: Document the deployment view hierarchically!
- Tip 7-5: Document the mapping of building-blocks to hardware!
- Tip 7-6: Use UML deployment diagrams to document software/hardware mapping!
- Tip 7-7: Use tables to document software/hardware mapping!!
- Tip 7-8: Explain your nodes!
- Tip 7-9: Explain what (else) is relevant for productive use (aka operation) of the system!
- Tip 3-19: Defer technical context to the deployment view!
- Tip 7-10: Leave hardware decisions to hardware-experts!
domain
- Tip 8-5: Document business or domain models!
- Tip 8-6: Combine business or domain models with the glossary!
- Tip 8-7: Document (at least) the (business or domain) data model!
essential
- Tip 2-5: Differentiate different categories of constraints!
- Tip 3-2: Show the context as diagram!
- Tip 3-3: Combine the context diagram with a table!
- Tip 3-5: Restrict the context to an overview, avoid too many details!
- Tip 3-9: Show all (all!) external interfaces!
- Tip 4-2: Describe the solution approaches as a table!
- Tip 5-2: Organize the building block view hierarchically!
- Tip 5-3: Always describe level-1 of the building block view ('Level-1 is your friend')!
- Tip 5-5: Describe the responsibility or purpose of every (important) blackbox!
- Tip 5-6: Hide the inner workings of blackboxes!
- Tip 6-1: Always map existing building blocks to the activities within runtime scenarios!
- Tip 6-2: Document only a few runtime scenarios!
- Tip 8-1: Explain the Concepts!
- Tip 8-7: Document (at least) the (business or domain) data model!
- Tip 9-2: Document decision criteria!
- Tip 9-3: Provide reasons for important decisions!
- Tip 12-1: Take the glossary seriously!
- Tip 1-11: Always work with explicit quality requirements!
- Tip 1-12: Explain quality requirements through scenarios!
- Tip 1-13: If you do not get quality requirements, make your assumptions *explicit*!
- Tip 1-19: Search broadly for stakeholders!
- Tip 1-20: Describe the expectations of stakeholders!
- Tip 1-21: Maintain a stakeholder table!
- Tip 5-13: Explain the mapping of source-code to building blocks!
example
- Tip 8-4: In concepts, explain HOW it works!
- Tip 8-8: Document concepts with source code!
- Tip 1-15: Use examples to work out quality goals together with your stakeholders!
external-interface
- Tip 3-1: Explicitly demarcate your system from its environment!
- Tip 3-2: Show the context as diagram!
- Tip 3-6: Simplify the context by categorization!
- Tip 3-9: Show all (all!) external interfaces!
- Tip 5-4: Ensure consistency of external interfaces to level-1
- Tip 11-2: Analyze (external) interfaces for problems and risks!
- Tip 3-14: Pay attention to quality requirements at external interfaces!
functional-requirement
- Tip 1-4: Create an overview by grouping or clustering requirements!
- Tip 1-6: Use activity diagrams to describe functional requirements!
- Tip 1-7: Use BPMN diagrams to describe functional requirements!
- Tip 1-8: Use a numbered list to describe functional requirements!
- Tip 1-9: Use (semi) formal text to describe functional requirements!
- Tip 1-10: Use 'exemplary business process models' to describe functional requirements!
glossary
- Tip 8-6: Combine business or domain models with the glossary!
- Tip 12-1: Take the glossary seriously!
- Tip 12-2: Document the glossary as a table!
- Tip 12-3: Amend the glossary by a (graphical) model!
- Tip 12-4: Include translations in the glossary!
- Tip 12-5: Keep the glossary compact! Avoid trivia.
- Tip 12-6: Make your 'product owner' or 'project manager' responsible for the glossary
goal
hardware
- Tip 7-1: Document your technical infrastructure (hardware)!
- Tip 7-2: Explain hardware and infrastructure decisions!
- Tip 7-8: Explain your nodes!
hierarchy
- Tip 5-2: Organize the building block view hierarchically!
- Tip 5-3: Always describe level-1 of the building block view ('Level-1 is your friend')!
- Tip 7-4: Document the deployment view hierarchically!
- Tip 5-11: Show multiple levels of the building block view!
- Tip 5-12: Refine building-blocks consistently!
- Tip 5-25: If useful, refine several building blocks at once!
- Tip 5-26: Make the origin of lower-level building blocks explicit!
- Tip 5-27: Refine only a few building blocks!
i18n
infrastructure
- Tip 7-1: Document your technical infrastructure (hardware)!
- Tip 3-17: Combine business context with technical information!
interface
- Tip 11-2: Analyze (external) interfaces for problems and risks!
- Tip 3-18: Explain the relationship between domain interfaces and their technical realization!
- Tip 5-21: Describe or specify internal interfaces with minimal effort!
- Tip 5-22: Document or specify interfaces with unit-tests!
- Tip 5-23: Document or specify interfaces with runtime scenarios!
iso-25010
lean
- Tip 3-5: Restrict the context to an overview, avoid too many details!
- Tip 3-6: Simplify the context by categorization!
- Tip 4-1: Explain the solution strategy as compact as possible (e.g. as list of keywords)!
- Tip 4-2: Describe the solution approaches as a table!
- Tip 4-5: Let the solution strategy grow iteratively / incrementally!
- Tip 5-3: Always describe level-1 of the building block view ('Level-1 is your friend')!
- Tip 5-6: Hide the inner workings of blackboxes!
- Tip 6-2: Document only a few runtime scenarios!
- Tip 6-3: Document 'schematic' (instead of detailed) scenarios!
- Tip 6-9: Use a textual notation to describe runtime scenarios!
- Tip 7-7: Use tables to document software/hardware mapping!!
- Tip 8-1: Explain the Concepts!
- Tip 8-9: Document decisions instead of concepts!
- Tip 9-1: Document only architecturally relevant decisions!
- Tip 9-7: Document decisions informally as a blog (RSS-feed)!
- Tip 12-2: Document the glossary as a table!
- Tip 12-5: Keep the glossary compact! Avoid trivia.
- Tip 12-6: Make your 'product owner' or 'project manager' responsible for the glossary
- Tip 1-16: Describe only the top 3-5 quality goals in the introduction!
- Tip 1-22: Skip the stakeholder table if your management already maintains it!
- Tip 1-23: Classify your stakeholders by interest and influence!
- Tip 3-17: Combine business context with technical information!
- Tip 3-19: Defer technical context to the deployment view!
- Tip 5-10: Use crosscutting concepts to describe or specify similarities in building blocks!
- Tip 5-15: Align the mapping of source-code to building-blocks along the directory and file structure!
- Tip 6-10: Use both small and large building blocks in scenarios!
- Tip 7-10: Leave hardware decisions to hardware-experts!
- Tip 8-10: Use the collection from arc42 as checklist for concepts!
- Tip 5-21: Describe or specify internal interfaces with minimal effort!
- Tip 8-11: (Hyper)Link between Building Blocks and Concepts!
mapping
- Tip 7-5: Document the mapping of building-blocks to hardware!
- Tip 7-6: Use UML deployment diagrams to document software/hardware mapping!
- Tip 5-13: Explain the mapping of source-code to building blocks!
- Tip 5-14: Explain where to find the source code of your building blocks!
- Tip 5-15: Align the mapping of source-code to building-blocks along the directory and file structure!
- Tip 5-16: Map building blocks according to modularization constructs of your programming language!
plantUML
- Tip 1-9: Use (semi) formal text to describe functional requirements!
- Tip 8-7: Document (at least) the (business or domain) data model!
port
problem
- Tip 11-1: Search for problems and risks with different stakeholders!
- Tip 11-2: Analyze (external) interfaces for problems and risks!
- Tip 11-3: Identify problems or risks by qualitative evaluation!
- Tip 11-4: Analyze _processes_ for problems and risks!
- Tip 11-5: Analyze data or data structures for problems and risks!
- Tip 11-6: Analyze source-code for problems and risks!
quality
- Tip 4-3: Describe solution approaches in context of quality requirements!
- Tip 9-1: Document only architecturally relevant decisions!
- Tip 9-4: Document decisions as mind-map or as table!
- Tip 10-1: Keep the quality goals in arc42-section 1.2 short!
- Tip 10-2: Document and explain the specific quality tree!
- Tip 10-3: Use a mind-map as quality tree!
- Tip 10-5: Consider usage or application (quality) scenarios!
- Tip 10-6: Consider change (quality) scenarios!!
- Tip 10-7: Consider fault/error/failure (quality) scenarios!!
- Tip 10-8: Use (quality) scenarios for architecture analysis or evaluation!
- Tip 1-11: Always work with explicit quality requirements!
- Tip 1-12: Explain quality requirements through scenarios!
- Tip 1-13: If you do not get quality requirements, make your assumptions *explicit*!
- Tip 1-14: Use checklists for quality requirements!
- Tip 1-15: Use examples to work out quality goals together with your stakeholders!
- Tip 1-16: Describe only the top 3-5 quality goals in the introduction!
- Tip 1-17: Combine quality goals with the action points of the 'solutions strategy' section!
- Tip 1-24: Make use of the (open-source) collection of quality requirements examples!
quality-goal
- Tip 4-2: Describe the solution approaches as a table!
- Tip 10-1: Keep the quality goals in arc42-section 1.2 short!
- Tip 1-16: Describe only the top 3-5 quality goals in the introduction!
- Tip 1-18: Defer detailed and complete quality requirements to arc42 section 10!
- Tip 3-14: Pay attention to quality requirements at external interfaces!
quality-scenario
- Tip 4-3: Describe solution approaches in context of quality requirements!
- Tip 10-1: Keep the quality goals in arc42-section 1.2 short!
- Tip 10-5: Consider usage or application (quality) scenarios!
- Tip 10-6: Consider change (quality) scenarios!!
- Tip 10-7: Consider fault/error/failure (quality) scenarios!!
- Tip 10-8: Use (quality) scenarios for architecture analysis or evaluation!
- Tip 1-24: Make use of the (open-source) collection of quality requirements examples!
quality-tree
- Tip 10-2: Document and explain the specific quality tree!
- Tip 10-3: Use a mind-map as quality tree!
- Tip 10-4: Use the quality tree as checklist!
- Tip 1-14: Use checklists for quality requirements!
requirement
- Tip 1-1: Give a compact summary of requirements and driving forces!
- Tip 1-2: Limit yourself to the essential tasks and use cases!
- Tip 1-3: Highlight the business goals of the system!
- Tip 1-4: Create an overview by grouping or clustering requirements!
- Tip 1-5: Make sure you can reference (existing) requirements!
- Tip 1-6: Use activity diagrams to describe functional requirements!
- Tip 1-7: Use BPMN diagrams to describe functional requirements!
- Tip 1-8: Use a numbered list to describe functional requirements!
- Tip 1-9: Use (semi) formal text to describe functional requirements!
- Tip 1-10: Use 'exemplary business process models' to describe functional requirements!
- Tip 1-11: Always work with explicit quality requirements!
- Tip 1-12: Explain quality requirements through scenarios!
- Tip 1-13: If you do not get quality requirements, make your assumptions *explicit*!
- Tip 1-14: Use checklists for quality requirements!
- Tip 1-15: Use examples to work out quality goals together with your stakeholders!
- Tip 1-16: Describe only the top 3-5 quality goals in the introduction!
- Tip 1-17: Combine quality goals with the action points of the 'solutions strategy' section!
- Tip 1-18: Defer detailed and complete quality requirements to arc42 section 10!
- Tip 1-19: Search broadly for stakeholders!
- Tip 1-20: Describe the expectations of stakeholders!
- Tip 1-22: Skip the stakeholder table if your management already maintains it!
- Tip 1-24: Make use of the (open-source) collection of quality requirements examples!
risk
- Tip 3-4: Explicitly indicate risks in the context!
- Tip 11-1: Search for problems and risks with different stakeholders!
- Tip 11-2: Analyze (external) interfaces for problems and risks!
- Tip 11-3: Identify problems or risks by qualitative evaluation!
- Tip 11-4: Analyze _processes_ for problems and risks!
- Tip 11-5: Analyze data or data structures for problems and risks!
- Tip 11-6: Analyze source-code for problems and risks!
runtime-scenario
- Tip 6-1: Always map existing building blocks to the activities within runtime scenarios!
- Tip 6-2: Document only a few runtime scenarios!
- Tip 6-3: Document 'schematic' (instead of detailed) scenarios!
- Tip 6-4: Document detailed scenarios (with caution)!
- Tip 5-23: Document or specify interfaces with runtime scenarios!
runtime-view
- Tip 5-9: Use runtime views to explain or specify whiteboxes!
- Tip 6-1: Always map existing building blocks to the activities within runtime scenarios!
- Tip 6-2: Document only a few runtime scenarios!
- Tip 6-3: Document 'schematic' (instead of detailed) scenarios!
- Tip 6-4: Document detailed scenarios (with caution)!
- Tip 6-5: Use scenarios primarily to `discover` building blocks, not so much for documentation!
- Tip 6-6: Describe excerpts of scenarios (partial scenarios)!
- Tip 6-7: Use activity diagrams with swimlanes to describe or specify runtime scenarios!
- Tip 6-8: Use activity diagrams with partitions to describe or specify runtime scenarios!
- Tip 6-9: Use a textual notation to describe runtime scenarios!
- Tip 6-10: Use both small and large building blocks in scenarios!
- Tip 6-11: Use sequence diagrams to describe or specify runtime scenarios!
scenario
- Tip 4-2: Describe the solution approaches as a table!
- Tip 6-1: Always map existing building blocks to the activities within runtime scenarios!
- Tip 6-2: Document only a few runtime scenarios!
- Tip 6-3: Document 'schematic' (instead of detailed) scenarios!
- Tip 6-4: Document detailed scenarios (with caution)!
- Tip 6-5: Use scenarios primarily to `discover` building blocks, not so much for documentation!
- Tip 6-6: Describe excerpts of scenarios (partial scenarios)!
- Tip 6-7: Use activity diagrams with swimlanes to describe or specify runtime scenarios!
- Tip 6-8: Use activity diagrams with partitions to describe or specify runtime scenarios!
- Tip 6-9: Use a textual notation to describe runtime scenarios!
- Tip 10-5: Consider usage or application (quality) scenarios!
- Tip 10-6: Consider change (quality) scenarios!!
- Tip 10-7: Consider fault/error/failure (quality) scenarios!!
- Tip 10-8: Use (quality) scenarios for architecture analysis or evaluation!
- Tip 1-12: Explain quality requirements through scenarios!
- Tip 1-15: Use examples to work out quality goals together with your stakeholders!
- Tip 1-16: Describe only the top 3-5 quality goals in the introduction!
- Tip 6-10: Use both small and large building blocks in scenarios!
- Tip 6-11: Use sequence diagrams to describe or specify runtime scenarios!
- Tip 5-23: Document or specify interfaces with runtime scenarios!
- Tip 1-24: Make use of the (open-source) collection of quality requirements examples!
sequence-diagram
- Tip 6-6: Describe excerpts of scenarios (partial scenarios)!
- Tip 6-11: Use sequence diagrams to describe or specify runtime scenarios!
solution-strategy
- Tip 4-1: Explain the solution strategy as compact as possible (e.g. as list of keywords)!
- Tip 4-2: Describe the solution approaches as a table!
- Tip 4-3: Describe solution approaches in context of quality requirements!
- Tip 4-4: In the solution strategy, refer to concepts, views or code!
- Tip 4-5: Let the solution strategy grow iteratively / incrementally!
- Tip 4-6: Justify the solution strategy!
- Tip 1-17: Combine quality goals with the action points of the 'solutions strategy' section!
source-code
- Tip 4-4: In the solution strategy, refer to concepts, views or code!
- Tip 5-2: Organize the building block view hierarchically!
- Tip 8-4: In concepts, explain HOW it works!
- Tip 8-8: Document concepts with source code!
- Tip 11-6: Analyze source-code for problems and risks!
- Tip 5-13: Explain the mapping of source-code to building blocks!
- Tip 5-14: Explain where to find the source code of your building blocks!
- Tip 5-15: Align the mapping of source-code to building-blocks along the directory and file structure!
- Tip 5-16: Map building blocks according to modularization constructs of your programming language!
- Tip 5-17: 'Cohesion' shall be the primary driver when creating architecture building blocks!
- Tip 5-18: Ensure **every** piece of source code can be located in the building block view!
stakeholder
- Tip 2-2: Clarify the consequences of constraints!
- Tip 9-1: Document only architecturally relevant decisions!
- Tip 9-2: Document decision criteria!
- Tip 9-4: Document decisions as mind-map or as table!
- Tip 11-1: Search for problems and risks with different stakeholders!
- Tip 1-19: Search broadly for stakeholders!
- Tip 1-20: Describe the expectations of stakeholders!
- Tip 1-21: Maintain a stakeholder table!
- Tip 1-22: Skip the stakeholder table if your management already maintains it!
- Tip 1-23: Classify your stakeholders by interest and influence!
table
- Tip 4-2: Describe the solution approaches as a table!
- Tip 5-7: Use tables to efficiently document/specify blackboxes!
technical-context
- Tip 3-10: Differentiate business and technical context!
- Tip 3-15: Show the technical context (in case hardware is central to your system)!
- Tip 3-16: Use the technical context to describe protocols or channels!
- Tip 3-17: Combine business context with technical information!
- Tip 3-19: Defer technical context to the deployment view!
technical-debt
test
- Tip 8-8: Document concepts with source code!
- Tip 5-22: Document or specify interfaces with unit-tests!
thorough
- Tip 1-5: Make sure you can reference (existing) requirements!
- Tip 6-4: Document detailed scenarios (with caution)!
- Tip 9-6: Document rejected alternatives!
- Tip 10-4: Use the quality tree as checklist!
- Tip 12-4: Include translations in the glossary!
- Tip 1-14: Use checklists for quality requirements!
- Tip 1-18: Defer detailed and complete quality requirements to arc42 section 10!
- Tip 1-21: Maintain a stakeholder table!
- Tip 3-16: Use the technical context to describe protocols or channels!