Bold information should be present, the other parts are optional.
Information | Meaning |
---|---|
Name/Role | who or which part of an organization has an interest in the system or its architecture? Sometimes you name specific people, quite often you’ll stick to roles |
Knowledge | What do these stakeholders know about the system or its associated processes? |
Expected deliverables | What do these stakeholders expect from the architecture or its documentation? Please don’t confuse this with the system requirements. See question C-1-5 (deliverables) below. |
Relevance (priority) | This is critical information: Some stakeholders will be relevant or required for production acceptance or sign-off - but: Explicitly stating relevance or priority might frustrate, irritate or even instigate those with lower priorities… You need to consider the political consequences of putting this information in your documentation - but the team should definitely know about stakeholders’ relevance. |
Contact | As trivial as a phone number or email address, so you or the team can contact this stakeholder. |
Comment | Any other information people might need concerning this stakeholder. |