A scope change process. Together, the DSC and UCD define what will and what will not be part of the project scope. In short, the project team is responsible for delivering everything that is listed application system should include. If you are build- ing a custom database management system, this is where you will define all of the features and functionality of the system. On the other hand, if you proposed an existing software package, your UCD will detail all of the features and functional- ity of that system. Although Figure 5.5 in the text provides an example of a use case, you can build one by:

a. Drawing a box to represent the system bound- ary. b. Drawing stick figures to represent the actors of the system. Actors can be users, managers, customers, or even other systems that will interact with or use the application system. Actors should be drawn on the outside of the system boundary. Be sure to label each actor with a descriptive name to describe the actor's role. c. Drawing an oval inside the system bound- ary for each system feature or function and label the oval with a descriptive name. A use case is a particular function that the appli- cation system will perform. Examples of use cases are: update customer information, print employee overtime report, create new vendor record, and so forth. This important step during your project necessitates a great deal of interac- tion with your client. Unfortunately, you will not have access to a real client, so you can in the DSC and UCD. Unfortunately, items may be overlooked and often needs will change. Adding deliverables or functionality to the system is an important decision. Therefore, develop a logical process that your client and team will follow for identifying, cataloging, managing, and responding to a scope change request. Be sure to include tem- plates or examples of any forms or logs that will be used to support the scope change process.