A.3 Scope Decisions

Our definition of system context gives us sufficient basis to make a number of scope decisions with the stakeholders. The first is that the stakeholders direct us to design the system from the viewpoint of a user . This is an essential direction, as we had considered the complex business requirements that emanate from the accounting system that could underpin the system. The stakeholders require a strong accounting underpinning for their business, but are content to keep the two systems separate. There is little data duplicated between their book of record (accounting system) and the real estate system, and they decline the added expense of adding either accounting functionality or data integration between the two systems.

The second directive from the stakeholders is that they view the system to as a "collect and report system." The philosophy will be to build a system to collect data that implements the business rules they define with the dual objectives of making this data "safe" (it will not be lost or forgotten) and providing specialized views of the data for various actors to make business decisions against (for example, the ability to compare the returns across investments and the ability to know what buildings are historically underutilized from a leasing perspective).

Our next steps are to find out as much information about how the various actors want to interact with the system, and the capabilities they require from it. The results of this work lead us to expand our use cases to the following. We break up our use case diagram into three, for a better fit.

This expands the set of use cases from 2 to 23. When we approached the problem of eliciting these requirements, our initial take was that there would be requirements to collect regarding the data entry for both property and tenants, so we dug in that direction first to see what we would come up with.

Figure A.2. Data Entry Expanded

Figure A.3. Reporting Expanded

Figure A.4. Maintenance Expanded

A.3.1 List of Use Cases

Category	Use Case
Data Entry	Import Data
	Establish Cash Flow Schedule
	Lease Property
	Record Transactions
	Enter Tenant Details
	Dispose of Property
	Establish Units
	Enter Property Details
	Establish Capital Schedule
	Enter Investment Details
Reporting	Report Top Ten Properties
	Calculate Returns
	Report Properties per MSA
	Report Expected Rate of Return
	Report Exposure
	Create Reports
	Report Property Utilization
	Report Open Units per MSA
	Report Leases Expiring
Maintenance	Import Index Information
	Set Up MSA
	Set Up Users

Use Case A.3 Enter Tenant Details

Use Case Name :	Enter Tenant Details
Description:	The real estate system tracks who is leasing a property; the system stores a set of details of each tenant (lease holder) for billing, tracking, and exposure reasons.
Actors:	Operations manager
Triggers:	A new tenant or potential tenant has been found for a property lease. This could be initiated from the lease property use case. Additional or changed information has been found for an existing tenant.
Preconditions:	None
Basic Course of Events:	The operations manager navigates to the tenant area. The operations manager enters the identification information for a tenant: First name, last name, and SSN for an individual, or Company name and federal tax ID for an institution or organization The system checks for existing matching entries. The system displays a data entry template that is populated with any existing information. The template differs for individuals and organizations. <Insert list of data items required.> The operations manager enters each data item. The system validates data according to the data entry rules (dates, and so on). When satisfied with the data entry, the operations manager commits the changes. The system validates that the data set is complete. The system stores the changes and if validation passed, the tenant is marked as validated .
Exceptions:	3. If the system finds a duplicate, alert the actor and display the existing tenant record. 7. If the actor is not satisfied with the changes, he optionally may abandon the changes. The system reverts to the previously stored record, if one existed. 8. If mandatory data is missing, the system alerts the actor and explains the omission. If the tenant refers to a current lessee (that is, a tenant with an active lease) and the system will not accept changes, that will cause the tenant to lose validation status.
Postconditions:	If the data is complete and valid, the system has a validated tenant.
Business Rules:	<Insert field and form level validation details.>
Technical Requirements:	This functionality will be used from the main office only, as the operations manager does not work from other locations. The set of the data needed about a tenant has changed several times during our business; the property manager will require the flexibility to add and remove direct and derived data regarding tenants. It is anticipated that only one person will update a tenant at one time; the system does not need to support simultaneous updates to tenant information. The system should store the history of all changes to tenants together with the identity of the actor making the changes and the date and time of the work.

Use Case A.4 Enter Investment Details

Use Case Name:	Enter Investment Details
Description:	This system tracks details of real estate investments with an emphasis on lease management. Each investment is made up of the capital committed to the project by the manager and the cash flow generated by leasing parts of the investment to individuals or organizations. Each investment could span several properties.
Actors:	Property manager Operations manager
Triggers:	A new investment is entered into. Additional details of an investment become available. Changes to investment details are required. A property manager wants to review the details of an investment.
Preconditions:	None
Basic Course of Events:	The actor navigates to the investment details area. Investments are identified by a name and system-assigned number; the name sometimes relates to the name of a property. The actor selects the investment from a system-displayed list or enters a new investment name. If the system located the investment, it retrieves the details and displays them. The actor enters the following identifying details of the investment: Name Location Category (Residential SFH, residential multi-family home, retail, or office) Property manager (select from a displayed list) The actor enters the capital commitment schedule. The actor enters date, capital, source, amount, estimate high, estimate low, and notes. The actor enters free-form notes. The actor enters other details including any contract numbers and contacts for other people and companies involved in the investment. When the actor is satisfied with the changes, the actor commits them, and the system responds by checking that all mandatory information about a deal is entered.
Exceptions:
Postconditions:
Business Rules:
Technical Requirements:

Use Case A.5 Enter Property Details

Use Case Name:	Enter Property Details
Description:	A property, related to an investment that is, or will be, managed by the company, needs to have details tracked. The use case is responsible for collecting this information. Properties are made unique by their address and the investment identity that created the property.
Actors:	Operations manager
Triggers:	Use case Enter Investment Details. Additional or changed information becomes available about a property.
Preconditions:	An investment has been made and entered that relates to a property.
Basic Course of Events:	The operations manager navigates to the property details area. The operations manager selects a property to work on, or chooses to create a new property. To locate an existing property the operations manager may Select from a list of property names and addresses and associated investment identities Search using property name, category, and address If the property is new, the system prompts the operations manager to enter a name and address and to select an investment. The system displays any data collected. The operations manager enters the following data: Note: team needs to analyze and define the set of data being collected. MSA (Metropolitan Statistical Area) If the operations manager wishes, the property may be divided into a set of one or more units.
Exceptions:	The combination of property name, address, and investment must be unique. The system checks the property address. If the address is used for an existing property, the system alerts the operations manager and asks if the properties are related by an investment.
Postconditions:	The property becomes available for reporting and leasing.
Business Rules:	An investment may include many properties. Each investment includes at least one unit.
Technical Requirements:	The list of MSAs must be kept up-to-date with data provided by the United States Postal Service. Currently all investments have been made within the United States.

Use Case A.6 Establish Units

Use Case Name:	Establish Units
Description:	For the purposes of leasing, a property consists of one or more units. The definition of units is flexible within the system as the category of the investment causes it to change. For example, in a SFH (Single Family Home) development, a unit is a home/lot; in a shopping mall a unit is a store or a vendor kiosk location.
Actors:	Operations manager
Triggers:	An existing property is having its units reevaluated and changed. A new property is being leased.
Preconditions:	The property exists in a system.
Basic Course of Events:	The operations manager navigates to the units area from the Enter Property Details use case. The operations manager reviews the set of units already established (by default there will be at least one). The operations manager chooses to add, modify, or delete a unit. The system prompts the operations manager for the following information: Unit identity Unit description (for example, lot number) Size in square feet Notes (operations manager uses this to capture distinguishing information) Related documents (for example, a reference to a page in a plan or a blueprint)
Exceptions:	None
Postconditions:	The set of units is available to the system for reporting and leases.
Business Rules:	A unit may not be deleted if it has an active tenant.
Technical Requirements:	None
Notes:	Many of our buildings have intricate maps drawn of the unit layout. A nice-to-have requirement is the ability to store these diagrams and to associate them with the unit record. This is considered nice-to-have as the majority of the selling work is performed by commercial real estate agents .

Use Case A.7 Lease Property

Use Case Name:	Lease Property
Description:	A property unit has been leased by a lessee. This use case allows the details of the lease to be recorded.
Actors:	Operations manager
Triggers:	A real estate management company informs the operations manager that a unit has been leased or that a change to a lease has been effected.
Preconditions:	The property and its units have been established in the system.
Basic Course of Events:	The operations manager navigates to the lease section ”either directly, or by navigating to the property section first. The system responds by displaying the set of units in the property together with their current lease status. The operations manager may choose to alter an existing lease or to enter a new lease. The system prompts the operations manager for the following: Tenant details including identity, address, source of credit rating Lease details including contract number and unit identity
Exceptions:	None
Postconditions:	The status of unit and tenant is available for reporting.
Business Rules:	A unit may not be leased to a new tenant without current leases being terminated .
Technical Requirements:	None

Use Case A.8 Import Data

Use Case Name:	Import Data
Description:	External partners manage some of the properties. Typically, the external partners are joint owners of a property with the company ”they own part of the property and they are responsible for maintaining and leasing the entire property. On a schedule, they provide data and often money to the company as per their agreement. This use case takes the data an external partner provides and imports it into the system where it will be stored and available for reporting.
Actors:	External partner Operations manager
Triggers:	External partners provide data on a regular schedule as stipulated by a contract. Each reporting period they prepare data and submit it to the company, triggering this use case.
Preconditions:	An agreement is in place between the external partner and the company.
Basic Course of Events:	The operations manager receives a set of data or notification that a set of data is created from the external partner. The operations manager locates the property referred to by the data. The operations manager navigates to the import external partner data. The system responds by requesting the location of the external data. The operations manager provides the location. The system validates that the data refers to the correct property. The system reads the following data for a property: A series of cash amounts with corresponding dates A series of capital payments with corresponding dates The system associates this information with the property. The system displays the imported data to the operations manager for approval. The operations manager examines the data and either approves it or cancels the operation. If the data is approved, the system stores the data.
Exceptions:	5. If the system is unable to locate or access the data, the system alerts the operations manager and waits for an operations manager to provide an alternative location or to cancel the operation. 6. If the data does not refer to the expected property, the system alerts the operations manager and the use case terminates.
Postconditions:	None
Business Rules:	None
Technical Requirements:	Only one method of data transfer will be supported. This is to reduce system complexity and staff-training issues. A stakeholder stated that the external partners have very little technology and business automation, and suggested that a spreadsheet format would be a suitable mechanism.

Use Case A.9 Establish Cash Flow Schedule

Use Case Name:	Establish Cash Flow Schedule
Description:	When a tenant leases a property unit, we predict that he or she will make a series of timely rent payments. The company uses this data to predict the return on a property.
Actors:	Operations manager
Triggers:	A property unit is leased. A change to a property unit lease occurs (for example, the rent is increased).
Preconditions:	A property is leased to a tenant. A property lease terminates or attributes of the lease involving time or money change. Invoked by the lease property use case.
Basic Course of Events:	The operations manager locates the property/unit. The operations manager navigates to the cash flow functional area. The system displays the existing cash flow schedule for the tenant, if one exists. This is made up of a sequence of dates, each with a dollar cash flow. The operations manager adds, modifies, and deletes cash flows until satisfied that the series properly represents the terms of the lease.
Exceptions:	4. The system checks each entry against the cash flow business rules and if the data fails validation, the system alters the actor and does not accept the changes.
Postconditions:	None
Business Rules:	A cash flow is a dollar amount paired with a date and optionally a memo field. The dollar amount must be numeric. The data cannot predate the lease, nor can it be dated after the lease is scheduled to end.
Technical Requirements:	From an interface design perspective, we need to find a way to decrease the amount of time taken to enter and review cash flow sequences. For example, provide an interface mechanism to repeat a cash flow for a set period (monthly) until a given date. We do not want to lose this data; provide the ability to cancel changes and to undo changes.
Notes:	There are no requirements for foreign currency.

Use Case A.10 Record Transactions

Use Case Name:	Record Transactions
Description:	Enter actual lease/rent payments on a regular basis.
Actors:	Operations manager
Triggers:	Regularly scheduled, at month end
Preconditions:	At least one property unit has been leased.
Basic Course of Events:	The operations manager locates the property/unit. The operations manager navigates to the transaction area. The operations manager enters in actual reconciled transactions, each with the following data: Transaction date Transaction type Transaction amount Optional memo field
Exceptions:
Postconditions:
Business Rules:
Technical Requirements:	There are no current requirements for importing this data from either the book of record (account system) or from bank account data. This is a possibility for future projects, and the flexibility to add an automated interface would be appreciated.

Use Case A.11 Dispose of Property

Use Case Name:	Dispose of Property
Description:	When a property is sold, or if the company has leased the property and subleased the units and the lease terminated, or if for other reasons the property will not be managed by the company at some date, it is necessary to record this.
Actors:	Operations manager
Triggers:	A property will cease to be managed by the company.
Preconditions:	The property was managed by the company.
Basic Course of Events:	The operations manager locates the property in the system. The operations manager enters a date for the disposal of the property. Optionally, the operations manager enters a transaction to cover any monetary change that results from the disposal. The system deallocates all units that were leased and records the lease termination date. The system removes all cash flows for the property from the termination date forward.
Exceptions:
Postconditions:
Business Rules:
Technical Requirements:

Use Case A.12 Establish Capital Schedule

Use Case Name:	Establish Capital Schedule
Description:	When the company acquires a property a capital schedule should be created to predict the payments the company will make to acquire, keep, and maintain the property. The company uses this data to predict the return on a property.
Actors:	Operations manager
Triggers:	A property is acquired for management by the company through either outright purchase or via a lease. Enter Property Details use case.
Preconditions:	None
Basic Course of Events:	The operations manager navigated to the capital schedule functional area. The system displays the existing capital schedule for the tenant if one exists. This is made up of a sequence of dates, each with a dollar value and optionally a memo field. The operations manager adds, modifies, and deletes capital values until satisfied that the series is realistic. These include any payments on notes, property taxes, and so on. The system adds additional capital values from a set of rules. These include anticipated depreciation.
Exceptions:	4. The system checks each entry against the cash flow business rules, and if the data fails validation, the system alters the actor and does not accept the changes.
Postconditions:	None
Business Rules:	A schedule item is a dollar amount, a date, a type, and optionally a memo field. The dollar amount must be numeric. Depreciation is assumed to be 1/12 of the annual expected revenue.
Technical Requirements:	From an interface design perspective, we need to find a way to decrease the amount of time taken to enter these sequences. For example, provide an interface mechanism to repeat an item for a set period (monthly) until a given date. We do not want to lose this data; provide the ability to cancel changes and to undo changes.
Notes:	There are no requirements for foreign currency.

Use Case A.13 Report Top Ten Properties

Use Case Name:	Report Top Ten Properties
Description:	This report calculates the actual internal rate of return (IRR) on each property managed by the company and reports on the ten properties with the highest IRR.
Actors:	Property manager
Triggers:	Create Reports use case
Preconditions:	None
Basic Course of Events:	The system prompts user to enter the report "as of" date. The system calculates the IRR of each property from inception to the "as of" date. The system creates a printed report that contains the following data: Rank: 1 “10, where 1 indicates the highest IRR IRR: The internal rate of return for the property Property inception date Property MSA: The location of the property Property manager Total property revenue The system invokes the appropriate use case for the report.
Exceptions:	2. If more than one property has the same IRR, both properties are given the same rank.
Postconditions:	Report for a given "as of" date is created.
Business Rules:
Technical Requirements:

Use Case A.14 Report Properties per MSA

Use Case Name:	Report Properties per MSA
Description:	This report displays the name and other attributes of each property grouped by MSA. The actor uses this to determine geographical exposure.
Actors:	Property manager
Triggers:	Create Reports use case
Preconditions:	None
Basic Course of Events:	The system prompts user to enter the report "as of" date. The system gathers the following data and prepares a report grouped by MSA: Property MSA: The location of the property Property Name Property inception date At the grouping level (MSA) the number of properties in the MSA are displayed. At the total level the total number of properties are displayed.
Exceptions:	2. MSAs that contain no properties are not included on the report.
Postconditions:	Report for a given "as of" date is created.
Business Rules:
Technical Requirements:

Use Case A.15 Report Expected Rate of Return

Use Case Name:	Report Expected Rate of Return
Description:	This report displays the IRR anticipated for a property. Actual cash flows are used where transaction data is available; otherwise the cash flow schedule is used. The IRR is calculated for the completed lifespan of the property.
Actors:	Property manager
Triggers:	Create Reports use case
Preconditions:	None
Basic Course of Events:	The system prompts user to enter the report "as of" date. The system prompts property manager to select the property from a list. The system calculates the IRR and the following data and prepares a report: Property Name Property inception date IRR Sum of capital expenditures Sum of lease payments Transaction data available from date to date.
Exceptions:	None
Postconditions:	Report for a given "as of" date is created.
Business Rules:
Technical Requirements:

Use Case A.16 Report Exposure

Use Case Name:	Report Exposure
Description:	This report displays all properties in a specific MSA. This report is used to locate properties, perhaps based on a customer request.
Actors:	Operations manager
Triggers:	Create Reports use case
Preconditions:	None
Basic Course of Events:	The system prompts the user to enter the report "as of" date. The system prompts operations manager to select an MSA from a list. The system collates the following data and prepares a report: MSA Name Property Name Property inception date Number of vacant units Number of total units
Exceptions:	None
Postconditions:	Report for a given "as of" date is created.
Business Rules:
Technical Requirements:

Use Case A.17 Report Property Utilization

Use Case Name:	Report Property Utilization
Description:	This report displays all properties that have an occupancy rate of less than 100 percent.
Actors:	Operations manager
Triggers:	Create Reports use case
Preconditions:	None
Basic Course of Events:	The system prompts the user to enter the report "as of" date. The system collates the following data and prepares a report: MSA Name Property Name Property inception date Number of vacant units Number of total units
Exceptions:	None
Postconditions:	Report for a given "as of" date is created.
Business Rules:
Technical Requirements:

Use Case A.18 Report Open Units per MSA

Use Case Name:	Report Open Units per MSA
Description:	This report displays all properties that have an occupancy rate of less than 100 percent grouped by MSA.
Actors:	Operations manager
Triggers:	Create Reports use case
Preconditions:	None
Basic Course of Events:	The system prompts user to enter the report "as of" date. The system collates the following data and prepares a report: MSA Name Property Name Property inception date Number of vacant units Number of total units The system groups the report by MSA and orders in the decreasing ratio of vacant to total units.
Exceptions:	None
Postconditions:	Report for a given "as of" date is created
Business Rules:
Technical Requirements:

Use Case A.19 Report Leases Expiring

Use Case Name:	Report Leases Expiring
Description:	This report displays all properties that have leases due to expire within three months of the "as of" date.
Actors:	Operations manager
Triggers:	Create Reports use case
Preconditions:	None
Basic Course of Events:	The system prompts user to enter the report "as of" date. The system collates the following data and prepares a report: Property Name Lease Name Lease expiration date Current number of vacant units Number of total units Property MSA The system groups the report by lease expiration month and orders in the decreasing ratio of vacant to total units.
Exceptions:	None
Postconditions:	Report for a given "as of" date is created.
Business Rules:
Technical Requirements:

Use Case A.20 Import Index Information

Use Case Name:	Import Index Information
Description:	Rates of return on an investment are compared with returns on similar investments during the same period. Companies track the rates of return for leasing and sell this data. Property managers include indexes in performance reports to provide a comparison baseline.
Actors:	Operations manager
Triggers:	New index data becomes available.
Preconditions:	None
Basic Course of Events:	Navigate to the index data import area. Select the data source from the system-displayed list. Enter the "as of" date of the index data. The system prompts actor to identify the location and name of the index data file. The actor enters the location and name of the file. The system attempts to open the file. The system reads the data and verifies that the format and data types meet expectations. The system stores the index data.
Exceptions:	6. If the system cannot find or open the file, alert the actor and return to step 4. 7. If the data or the file format do not meet expectations, alert the actor that the file may be corrupted and exit this use case.
Postconditions:	If the system was able to read and import the data file, index data for the "as of" date is available for reporting.
Business Rules:
Technical Requirements:	The technical requirements will vary by index data provider. Currently, only one type of index is being used ”this is expected to change. Note that competing vendors have different file formats, although all of them use a flat file. A nice-to-have requirement is to simplify the ability to add additional types of indexes to the system after the initial implementation. The current file format used is a comma-separated file with the following fields
	#	Field	Descr	Notes
	1	Start Date	Begin period date	MMDDCCYY
	2	End Date	End period date	MMDDCCYY
	3	MSA	Metropolitan statistical area	MSA code
	4	Return	IRR	Percentage with three decimal places

Use Case A.21 Set Up MSA

Use Case Name:	Set Up MSA
Description:	MSA describes a geographical area at a higher level than zip code (it is similar to identifying the major city catchment area). This data is used to classify where properties are located.
Actors:	Operations manager
Triggers:	MSA data becomes available or is altered .
Preconditions:	None
Basic Course of Events:	Navigate to the MSA setup area. The system responds by displaying the list of MSAs currently stored by the system. In any order, operations manager Adds an MSA The operations manager enters the MSA name. The system verifies that the MSA name is longer than three characters and that it does not contain illegal characters (not alphanumeric or containing a space or "-"). The system stores the new MSA. The system makes the new MSA available to other users of the system. Edits an existing MSA The operations manager selects an existing MSA. The operations manager enters the name. The system checks that the name is unique. If an MSA already exists with that name, the system alerts the operations manager. The system verifies that the MSA name is longer than three characters and that it does not contain illegal characters (not alphanumeric or containing a space or "-"). The system stores the new MSA. The system makes the new MSA available to other users of the system. Deletes an MSA The operations manager selects an existing MSA. The system checks that there are no properties or tenants currently "using" the MSA, and if there are none, the system removes the MSA from the store.
Exceptions:	cii. The system displays the set of properties and tenants that use the MSA. The operations manager is alerted that the MSA cannot be removed until no property or tenant is attached.
Postconditions:	Legal MSAs are added or altered in the system, and used MSAs may be removed.
Business Rules:	MSAs cannot be removed if they are referred to by a property or tenant.
Technical Requirements:	None

Use Case A.22 Set Up Users

Use Case Name:	Set Up Users
Description:	Users are identities actors interact with and use while interacting with the system. Each is associated with a real person and with the role the person has with the company.
Actors:	Operations manager
Triggers:	A new employee is hired by the company. A employee's role within the company changes. An employee leaves the company. An employee can no longer access the system due to expired or lost identity.
Preconditions:	None
Basic Course of Events:	Navigate to the administration, user area. The operations manager performs any of the following: Add a user The system prompts the operations manager for username, first and last names, user name and password, and role (selected from a list). The operations manager enters the required information. The system checks that first and last name fields are not empty and prompts the operations manager for more information if necessary. The system checks that the user name and password conform to the standard and, if necessary, prompts for a stronger user name and password combination. The system stores the user data and grants the user rights within the system. Reset a user The system displays the set of users. The operations manager selects a user to reset. The system resets the password to the original and displays the original to the operations manager (who is expected to communicate the password to the user). The system flags the user account as reset. Remove a user The system displays the set of users. The operations manager selects a user to delete. The system marks the user as deleted and permits no further access. Edit a user The system displays the set of users. The operations manager selects a user to edit. The system displays the first and last name and the username. The operations manager edits the information and submits it. The system checks that the first and last name fields are not empty and prompts the operations manager for more information, if necessary. The system stores the user information.
Exceptions:
Postconditions:
Business Rules:	Reset accounts must have their passwords changed to a new password the next time it is accessed, or the account will be locked. Accounts that are not accessed within 24 hours of being reset are locked again.
Technical Requirements:	The security discussion revealed that the system should have reasonably strong security ”the property managers want to protect sensitive information. A technical requirement that came from this is that all system access needs to be logged