Change LG 02-01 (neu) "Relate the Role of Software Architects to Other Stakeholders" and change the focus to "Stakeholder Concerns and their Impact on Software Architecture"
rhoadesre opened this issue · comments
Stakeholder concerns aren't addressed concretely in the current curriculum and, in my experience, have a great impact on the architecture, even if they can't be directly translated into requirements. I propose to change the focus and the name of the current learning goal "Relate the Role of Software Architects to Other Stakeholders" to "Stakeholder Concerns and their Impact on Software Architecture".
Proposed text - depict stakeholders and concerns in a table
- Architects can identify stakeholders and their concerns, as well as their impact on the software architecture or the design and development process.
- Examples of stakeholders and concerns are as follows:
| Stakeholder | Stakeholder Concern |
|---|---|
| product management and product owners | e.g., required time and feasibility for the implementation of the requirements |
| project managers | e.g., required time and budget for the implementation, associated risks of the chosen architectural approach |
| requirement engineers (requirements- or business analysts, requirements managers, system analysts, business owners, subject-matter experts, etc.) | e.g., fulfillment of the requirements, e.g., impact of the system or current processes and daily work activities |
| developers | e.g., components and interfaces to be implemented, protocols, technology constraints |
| quality assurance and testers | e.g., components to be tested |
| IT operators and administrators (applies primarily to production environment or data centers for information systems), hardware developers | e.g., infrastructure requirements required to run the system, backup and archival requirements |
| enterprise architects and architecture board members | e.g., compatibility of the system within the IT landscape, conformity to company-wide guidelines |
- Architects understand that not all stakeholder concerns can be translated into requirements, but may nevertheless need to be considered.
- Architects can use stakeholder concerns to validate requirements and constraints on the architecture
- Architects are able to determine the impact of the stakeholder concerns on the architecture or on the design and development process.
- Architects are able to determine how the architecture should be documented (and perhaps designed) to address the stakeholder concerns.
FLWG decided: will become new LG in (new) section 2 (requirements).
Wording tbd
was accidetially moved to section 1 instead of 2...
@skogsbaer pushed the change, moved it to chapter 2
ToDo:
- Remove bullet point for the sentence "Examples of stakeholders .... ".
- Make the examples R3