The identification of transactions and data are part of every software sizing exercise. Processes, and sometimes data, are impacted by logical location. For example, the process “Authorize Shipment” might take place at both corporate headquarters and at a warehouse location. In the corporate office, it might involve price and credit checks. In the warehouse, it might involve a weight check. What at first appears to be the same process is actually different depending upon where it is being performed. Likewise, the databases that support these two processes would be different. Therefore, it makes sense to identify the locations before trying to identify the transactions and data. Then, when a
process is identified, decisions can be made whether there are one or more transactions depending upon how they are executed at each location. Something similar can be considered about the structure of a data item at different logical locations.
Locations are logically distinct types of areas where a subset of processes are done. Examples might be “On the Road,” where information is only accessed; “branch offices,” where orders are taken; and “headquarters,” where data is collected. Even when the same process is performed in two locations, it may be done differently. For example, sales in a branch office may always require on-the-spot payment, while sales at headquarters may also allow the customer to make a purchase by issuing a purchase order. Similar data may in fact be different in different logical locations. For example, customer data may consist simply of purchase and payment information in the branch office. At headquarters, customer data may also include credit information.
There is a many-to-many relationship between logical locations and physical areas. For example, there may be many physical branch offices that are logically equivalent, thus the location would simply be branch office, not 123 Main Street, 456 Broadway, etc. The headquarters location might also have a branch office in the same building. That building would correspond to two logical locations: headquarters and a branch office. Note that physical locations are not typically considered when sizing software. Whether an application is used in 100 branch offices or 1000, the software size is usually considered the same.
Locations are related to roles. Supervisors may have a number of automated processes supporting them. However, those processes may be different for a warehouse supervisor than for a branch office supervisor. Therefore, user stores might be written for warehouse supervisors or branch office supervisor. For example, “As a warehouse supervisor, I can get a pick list for any of my subordinates.” Agile developers sometimes refer to this as decorating the role. Sister Mary would have referred to these as adjectives because they modified the roles. In any case, they are related to the concept of a role.
Locations usually have data storage associated with them. For example, the accounts payable component of an accounting system might be the only place where a vendor file is maintained. Smartphones might have the same data file that a mainframe has, but the smartphone may have less attributes for each record. In addition, the smartphone version of the file might only have the data records that are of interest to that smartphone user.