-
-
Notifications
You must be signed in to change notification settings - Fork 1
Introduction and Goals
Short description of the functional requirements, driving forces, extract (or abstract) of requirements. Link to (hopefully existing) requirements documents (with version number and information where to find it).
From the point of view of the end users a system is created or modified to improve support of a business activity and/or improve the quality.
Short textual description, probably in tabular use-case format. If requirements documents exist this overview should refer to these documents.
Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
What is template-repo?
- Template for future repositories
- Uses Scrum as project management model
Essential Features
- Feature 1
- Feature 2
Motivation
- Make life better
Quality goals are defined with ISO 25010
The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. We really mean quality goals for the architecture. Don't confuse them with project goals. They are not necessarily identical.
You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. Make sure to be very concrete about these qualities, avoid buzzwords. If you as an architect do not know how the quality of your work will be judged...
Quality Goal | Motivation / Description |
---|---|
Fast export of data (Performance) | ... |
Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
- should know the architecture
- have to be convinced of the architecture
- have to work with the architecture or with code
- need the documentation of the architecture for their work
- have to come up with decisions about the system or its development
You should know all parties involved in development of the system or affected by the system. Otherwise, you may get nasty surprises later in the development process. These stakeholders determine the extent and the level of detail of your work and its results.
Table with role names, person names, and their expectations with respect to the architecture and its documentation.
Name | Role | Contact | Matterns and concerns |
---|---|---|---|
... | ... | ... | ... |
README | Contributing | Code of Conduct | Support | Funding | Security | License |
- Home of the Wiki
- Roadmap
- API Reference
- Glossary
- Contributor Guide
- Code of Conduct
- Support
- Funding
- Security
- License
- Description of Core Essence
- Cost Estimates
- Staffing Estimates
- Predicted Benefits
- Risks
- Scheduled Milestones
- Definition of Ready
- Definition of Done
- Project Decisions
- Technological Decisions
- Sprint Reviews
- Sprint Retrospectives
- Continuous Integration
- Continuous Deployment
- Operations Troubleshooting
- External Systems
- Style Guide
- Specific Views
- View 1
- ...
- About
- Introduction and Goals
- Constraints
- Context
- Solution Strategy
- Building Block View
- Runtime View
- Deployment View
- Cross Cutting Concepts
- Design Decisions
- ADRXX Template
- ...
- Quality Requirements
- Risks and Technical Debt
- Glossary
- Reference Manuals
- Support Guides
- Release Notes