Once you’ve identified requirements with architectural significance, record them in an ASR Workbook. At the beginning of a new software system, the ASR Workbook is a living document and changes rapidly. As the architecture coalesces, you’ll edit the workbook less frequently but reference it more often. Executable tests and source could eventually supplant portions of the ASR Workbook as a source of truth, though the document will remain an important historical record.
The ASR Workbook provides context and information for programmers, testers, and of course, architects. The more people who understand the ASRs, the less architectural oversight will be required.
Here is a sample ASR Workbook outline. Use the outline as a checklist for planning requirements elicitation.
Sample ASR Workbook Outline |
---|
Purpose and Scope |
Intended Audience |
Business Context |
Stakeholders |
Business Goals |
Architecturally Significant Requirements |
Technical Constraints |
Business Constraints |
Quality Attribute Requirements |
Top Scenarios |
Influential Functional Requirements |
Top Users or User Personas |
Use Cases or User Stories |
Appendix A: Glossary |
Appendix B: Quality Attributes Taxonomy |
Use the ASR Workbook to introduce architectural concepts to your team and stakeholders. Briefly teach readers what business goals, constraints, quality attributes, and influential functional requirements are, and they’ll have a finer appreciation for the information in the document.
3.145.97.104