This chapter discusses how we break down project requirements into architectural characteristics.
Example project requirements
Project requirements should usually come with the following sections:
- Audience or users
- Requirements that the audience or users have for the software system. These are usually business oriented and don’t have to be technical, ever.
- Any additional context the development team needs to understand the requirements document.
Defining architectural characteristics
Architectural characteristics are defined in three (3) parts:
- Explicit - specifies a non-domain design consideration
- Implicit - influences some structural aspect of the design
- Critical - important to application success and used as filtering criteria to avoid overengineering
Sourcing architectural characteristics
Architectural characteristics for your solution don’t appear out of thin air - they can be derived three (3) different sources:
- The problem domain - analyzing the problem domain and understanding what characteristics apply to the solution.
- Environmental awareness - having a good understanding of the environment you’re operating in.
- Holistic domain knowledge - knowing the problem domain from past experience.