CIS353 Assignment 2

Running Head: BUSINESS PROCESS AND FUNCTIONAL MODELING

2

BUSINESS PROCESS AND FUNCTIONAL MODELING

Business Process and Functional Modeling Student Name Course Title Instructor’s Name Institution Affiliation Date

Introduction

ABS or Advanced Business Modeling is a company that operates in hiring and staffing contracts for its clients across the world. The company has a project of automating its business activities right from the creation of a contracts, sending a staffing request to arranging for the contract and closing the staffing request. This king of system is possible only if the project manager captures all the requirements. To gather the user, business, functional and nonfunctional requirements, there is need to implement a use case technique and an activity diagram technique (Gutiérrez, Nebut, Escalona, Mejías, & Ramos, 2008). These techniques depict the functional modeling of the system for easy development of the system. This document will discuss the use case and activity diagram. It will also provide a detailed discussion of the verification and validation for the models alongside functional requirements document.

Use Case Diagram

The diagram below shows the actors, and use cases of the system required by the ABS Company:

Activity Diagram

An activity diagram is helpful in understanding the requirement system because it provides the flow of activities between one system class or object and the other (Xu, Miao, & Philbert, 2009). The following activity diagram uses structured English to illustrate this flow of activities:

The activity diagram above shows the flow of activities through the system. At the start, the client makes a contract before the contract manager saves it to the contracts file. The client will then proceed to make a staffing request where the contract manager will verify it and save it in the staffing request database. The placement specialist will the find the staffing requirements and qualification in the staffing request and use it to find a candidate through the placement department.

Use Case Description

The use case diagram above shows the system actors, use cases and interactions. The system involves three major actors that are contract manager, client and placement specialist. The contract manager interact with the system through the use cases such as validating the staffing request and closing the staffing request. The placement specialist is responsible for processing the placement, arranging for the contract, and notifying the candidate. The client interacts with the system through use cases like creating a contract and sending a staffing request. The use cases for the system are discussed below:

Creating a contract: this use case involves a client making an initial contract to the ABS Company. The client makes a contract by filling a contract form with their relevant details before sending it to the system database. The contract contains use information including the payment and terms of staffing contract (Munyon, Summers, & Ferris, 2011).

Sending a staffing request: a client is responsible for sending a staffing request to the company. A client sends a staffing request through the system and it contain information on outsourcing a temporary professional or contractor to help meet the client needs. The contract manager receives the staffing request for validation process.

Validating a staffing request: A contract manager is the actor responsible for this use case as shown in the use case diagram. This use case involves reviewing the staffing request received from the client and validating it against the earlier contract that the client created with the company. Therefore, the use case of validating staffing request includes the use case of creating contract and extends the use case for sending staffing request.

Processing the placement: the placement specialist and the contract manager handle this use case. The contract manager puts a successfully validated staffing request into the system database where the placement manager picks it for processing. The processing use case involves checking the availability of candidates, their qualifications and staffing requirements.

Notifying a candidate: this use case is handled by the system but the placement manager initiates it. When the placement specialist finds a candidate that meets the staffing requirement and has the required qualification, he or she will send a notification to the candidate through the system.

Arrange the contract: this use case involves confirmation of the starting date, location, travel and other contract details. The contract department also sends notification to the candidate with the arrangement for confirmation before closing the staffing request.

Close the staffing request: The contract manager will receive the notification of successful placement and forwards it to the client before closing the staffing request and sealing the contract.

Verification and Validation

The two major diagrams, use case diagram and activity diagram are dependent on each other hence verification of the functional modeling. The use case diagram involves three major actors that are client, contract manager and placement specialist. Similarly, the activity diagram involves two major classes to handle the staffing request. These classes in the activity diagram are the client and contract manager. Therefore, the actors in the use case diagram are the classes in the activity diagram thus the diagram are valid for the described use case (Gutiérrez et al., 2008).

The use case diagram is reflective of the activity diagram because the activities in the activity diagram are the use cases in the use case diagram. For instance, the use case diagram involves use cases like send a staffing request, create a contract, validate a staffing request and process a placement. Similarly, these use cases are reflected in activity diagram in form of activities such as make a contract, send a staffing request, find contract and validate staffing request. Since the use cases of the use case diagram are readily mapped on the activities of the activity diagram, then the diagram are valid.

The use cases and activities in both diagram capture the business requirements hence making them verifiable. The models can be verified because the business requirements include allowing the users to send staffing request, creating contracts, processing staffing requests and arranging for the contract and these business functions are the use cases and activities in both diagrams (Gutiérrez et al., 2008).

High Level Requirements Document

The major system’s functional requirements are as listed below:

· The system shall provide the clients with an interface to create a contract by entering appropriate details for the contract.

· The system shall allow the client to make a staffing request by providing an interface with a form that will take relevant input for processing the staffing request.

· The system will generate a variety of notifications for various tasks to alert the clients and company employees of successful or failed staffing request validation and staffing request processing.

· The system shall allow the users to save, delete or update various records to the database. The records include staffing request records, contract records and placement records.

· The system will provide allow users to access various functionalities after registration or login by providing valid usernames and password.

References

Gutiérrez, J. J., Nebut, C., Escalona, M. J., Mejías, M., & Ramos, I. M. (2008). Visualization of use cases through automatically generated activity diagrams. In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) (Vol. 5301 LNCS, pp. 83–96). https://doi.org/10.1007/978-3-540-87875-9_6

Munyon, T. P., Summers, J. K., & Ferris, G. R. (2011). Team staffing modes in organizations: Strategic considerations on individual and cluster hiring approaches. Human Resource Management Review, 21(3), 228–242. https://doi.org/10.1016/j.hrmr.2010.07.002

Xu, D., Miao, H., & Philbert, N. (2009). Model Checking UML Activity Diagrams in FDR. In 2009 Eighth IEEE/ACIS International Conference on Computer and Information Science (pp. 1035–1040). https://doi.org/10.1109/ICIS.2009.107