Roles are logically distinct types of people who do a subset of the processes that an application supports. Examples might be clerical users, who do data entry; supervisors, who schedule and authorize actions; and executives, who review management reports. Even when the same process is performed by people with different roles, it may be done differently. For example, both a cashier and a credit analyst may input customer data, but the details being input may be different.
Agile developers have a head start on this step. This is because user stories usually start with a role. For example, “As a trader, I can enter the purchase, stop and target prices of a trade at the same time.” Some agile practitioners use a list of personal names. For example, they may use the name Terri to represent a trader. Then the user story becomes “Terry can enter the purchase, stop and target prices of a trade at the same time.” In either case, they have identified a role.
The identification of elementary processes is part of every functional or non-functional sizing. Since processes are impacted by logical roles, it makes sense to identify the roles before trying to identify the elementary processes. This is because the existence of multiple roles may dictate that two elementary processes that look the same are, in fact, different. For example, there may be a transaction to “display employee information.” However if employee and supervisor are two different roles, then “display employee information” may be two transactions: “display employee information to employee” and “display employee information to supervisor.” The latter might include salary information that the former transaction does not. Thus, when a process is identified, decisions can be made whether there are one or more transactions depending upon how they are executed by each role.
Estimators must be careful of the opposite situation. A web application might have two types of users: Free Users and Premium Users. Most of the things that a Free User can do, a Premium User can do also. In fact they do it in the same way. The estimator must be careful not to double count these capabilities. The easiest way to work with situations like these is to have a hierarchy of roles. The real roles are Free Users and Premium Users. They each of capabilities. Sometimes they have the same capability, but the processes and data involved are different. The User role is an artificial role where all of the capabilities that are the same for Free User and Premium User can be captured. For example, if both Free Users and Premium Users can display information about a security, and the data displays are the same, then instead create a user story like “As a user, I can display security information.” In reality there is no such role as a user. The role user means that it applies equally well to both a Free User and a Premium User. The estimator must realize that there is only one elementary process that must be estimated in this case.
There is a many-to-many relationship between logical roles and physical people. For example, there may be many customer service representatives that have the same type of interactions with the application. However, some of those customer service representatives might also be supervisors. These people might have additional capabilities available to them.