The concept of “role” is more often used in professional activities than in personal life (however, all reasoning applies to personal projects too). In work, we are talking mainly about project activities; therefore, the concept of project role is used. A project role is a role played by a person in some project (if the performer is an inanimate object, we will not use the concept of “project role” but say “role”). It is performed by a person who somehow affects or is related to the system created in the project. We can say that the project roles are concerned about something. They have specific concerns about the system.
People who somehow influence the system or whose concerns may be affected by the system.
Concerns — Internal / External — Requirements/Needs
In systems thinking, internal and external project roles are distinguished.
Internal project roles are the roles that are performed by members of the project team and all collaborators, for example, suppliers, outsourced employees, etc. Internal project roles conceive, create and maintain the system’s operation, repair and maintenance, and dispose of it. If related to the automobile system, internal project roles are the plant manager, design engineer, assembly line worker, service station specialist, marketers, repairers, designers, testers, component suppliers, liquidators, etc. All of them are members of a large team that works with the automobile system at all life cycle stages, from the conception of a car to its elimination.
External project roles are considered to be roles that interact with the finished system. That means that the roles affect the system or the system affects these project roles. For example, external project roles are the driver, passenger, pedestrian, ecologist, and others related to the car system. The following external project roles can also be distinguished: client, competitor, tax officer, hacker, thief, etc. At the same time, the system’s clients must be divided into several sub-roles, which are specific to each system and/or field of activity. For example, a client may be a payer, operator, unpacker, etc. For any system, you can select a client, so to more accurately describe the client’s actions, it is necessary to define the role more specifically. Do not dwell on the common mention of the word “client” for all systems. Behind the “client” is a large number of specific roles that must be kept in mind when working with a system.
The person in the project role makes the appropriate decisions and is responsible for them. Or, as they say, puts his “skin in the game”. The consequences of these decisions are changes in the project activity, that is, how the project role changes the world.
We do not consider humans as project roles if their actions do not change the physical world. We cannot say that a person plays the role of a requirements engineer if he only writes down the wishes of customers (That is, he did only part of the actions of the practice of an on-demand engineer. Often, people perform only preparatory actions, and then their boss makes the real decisions. Then the boss will be an on-demand engineer, and you are just an analyst-secretary who writes down the wishes.) but did not work with these requirements and did not sign the list of requirements. And if a person thoroughly performs the practice (in this case, the practice of requirements engineering), which results in a working product list of requirements, then we can say that he plays the role of requirements engineer. The appearance of a working product approved by the project role changes the physical world. At the very least, the system architect will receive input data for his work, and the architect’s idea of activity will change.