Requirements should be SMART (e.g., specific metrics). Concerns are represented in the architecture by these requirements. Within that concern, stakeholders may have many distinct requirements: different classes of users may have very different reliability requirements for different capabilities of the system.Ĭoncerns are the root of the process of decomposition into requirements. For example, if the only viewpoint selected by an architect is a structural viewpoint, then reliability concerns are almost certainly not being addressed, since they cannot be represented in a structural model. The reason why architects should identify concerns and associate them with viewpoints, is to ensure that those concerns will be addressed in some fashion by the models of the architecture. So, system reliability might be a concern/area of interest for some stakeholders. Note: The terms "concern" and "requirement" are not synonymous. They enable the architecture to be communicated to and understood by the stakeholders, so they can verify that the system will address their concerns. In summary, then, architecture views are representations of the overall architecture in terms meaningful to stakeholders. Making this distinction between the content and schema of a view may seem at first to be an unnecessary overhead, but it provides a mechanism for re-using viewpoints across different architectures. ISO/IEC 42010:2007 encourages architects to define viewpoints explicitly.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |