A lot of architecture such as with UML builds on an actor model. Also when we model and improve business processes a solid understanding of various attribution errors should be standard in the assessment. However I have usually not seen even the most common techniques of the actor observer asymmetry taken into account. Actually the actor observer asymmetry is a classic instance why projects that are just implementing the vanilla approach by ERP software are often so successful.
So when looking at any actor driven information we always first need to make the distinction if the person that describes the process or is describing potential improvements is part of the acting or part of the process or only acts as an observer. Both groups are prone on errors, but they are usually very distinct ones. An actor describing any process will always try to put the process into a favourable light and explain any difficulties as situational and not part of a generalisation. However if the model is ever checked against reality (which rarely happens as most business owners are avoiding this kind of embarrassment) about 50 % of the time spent is not spent on the modelled actions use cases as it is seen as a situational occurrence even if it happens on a regular term.
Frequently the events that lead to those situational explained activities are social driven such as that during a set-up of a new account both sides will spent time on a social chit chat. The problem behind this is that often areas of large improvements are missed, as well as important and useful information not recorded. As sample of the later is that in the social chit chat the clark may learn vital informations on the new company far beyond that what he is recording such as further business opportunities or real risks.
The observer lead gathering tends to other problems such an extrapolations of the presence into the future and as such usually ignores any situational influences. This means that for the observer any other behaviour to the one he experienced is unlikely to happen, which is the pattern as a boss getting the first impression on the day he starts of an employee. So activities mapped of an observer are often too strict and misleading to establish an average.
Now you might think that the answer is in a mix of both ways, but that usually only ends up in long unfruitful discussions. Instead both sides need to be awre of the typical traps in their likely attribution errors and start implementing mitigations to this bias. An example for this could be a varied sample size over time for the observer and a de-priortisation of the first impression. However this kind of training requires professional help to overcome the inherrit attribution errors and that is what most architects as well as most requirements analysts have never done and as such the errors will keep on even if the requirement gathering processes are getting better all the time.