Bold information should be present, the other parts are optional.
|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.|