I need help in filling out a Use Case Specifications template for a software engineering requirements project. The project scenario is below:

so with the above information, i need help filling in the Use Case Specifications template below

Use Case Identification and History
Use Case ID:	PROJ.UC.1.1.1
Use Case Name:		Version No:
End Objective:
Created by:		On (date):
Last Update by:		On (date):
Approved by:		On (date):
User/Actor:
Business Owner Name:		Contact Details:
Trigger:
Frequency of Use:

Preconditions

Basic Flow
Step	User Actions	System Actions
1
2

Alternate Flow
Step	User Actions	System Actions
1
2

Post conditions

Includes or Extension Points

Special Requirements

Business Rules

Other Notes (Assumptions, Issues,)

Assumptions:

Issues:

Use Case Specific Checks

Use Case Diagram

The introduction section of the use-case diagram provides a clear, concise overview of the purpose and functionality of the system.

The use case diagram clearly presents the behavior of the system; it is easy to understand what the system does by reviewing the diagram.

No long chains of include and extend relationships, such as when an included use case is extended, or when an extended use case includes other use cases. These can obscure comprehensibility.

Minimal cross-dependencies where an included, extending, or specialized use case must know about the structure and content of other included, extending or specialized use cases.

All use cases have been identified; the use cases collectively account for all required behavior.

All functional requirements are mapped to at least one use case.

All non-functional requirements that must be satisfied by specific use cases have been mapped to those use cases.

The use-case diagram contains no extra system behavior; all use cases can be justified by tracing them back to a functional requirement.

All relationships between use cases are required (i.e. there is justification for all include-, extend-, and generalization-relationships).

Actors

Have you found all the actors? That is, have you accounted for and diagramed all roles in the system's environment? Although you should check this, you cannot be sure until you have found and described all the use cases.

Is each actor involved with at least one use case? Remove any actors not mentioned in the use-case descriptions, or any actors without communicates-associations with a use case. However, an actor mentioned in a use-case description is likely to have a communicates-association with that particular use case.

Can you name at least two people who would be able to perform as a particular actor? If not, check if the role the actor diagrams is part of another one. If so, you should merge the actor with another actor.

Do any actors play similar roles in relation to the system? If so, you should merge them into a single actor. The communicates-associations and use-case descriptions show how the actors and the system interrelate.

Do two actors play the same role in relation to a use case? If so, you should use actor-generalizations to diagram their shared behavior.

Will a particular actor use the system in several (completely different) ways or does he have several (completely different) purposes for using the use case? If so, you should probably have more than one actor.

Do the actors have intuitive and descriptive names? Can both users and customers understand the names? It is important that actor names correspond to their roles. If not, change them.

Use Case Specifications

Is each concrete use case involved with at least one actor? If not, something is wrong; a use case that does not interact with an actor is not required, and you should remove it.

For an included use case: does it make assumptions about the use cases that include it? Such assumptions should be avoided, so that the included use case is not affected by changes to the including use cases.

Do any use cases have very similar behaviors or flows of events? If so - and if you wish their behavior to be similar in the future - you should merge them into a single use case. This makes it easier to introduce future changes. Note: you must involve the users if you decide to merge use cases, because the users, who interact with the new, merged use case will probably be affected.

Has part of the flow of events already been diagramed as another use case? If so, you can have the new use case use the old one.

Is some part of the flow of events already part of another use case? If so, you should extract this subflow and have it be used by the use cases in question. Note: you must involve the users if you decide to "reuse" the subflow, because the users of the existing use case will probably be affected.

Should the flow of events of one use case be inserted into the flow of events of another? If so, you diagram this with an extend-relationship to the other use case.

Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage? If not, you change their names.

Do customers and users alike understand the names and descriptions of the use cases? Each use-case name must describe the behavior the use case supports.

Does the use case meet all the requirements that obviously govern its performance? You must include any (nonfunctional) requirements to be handled in the object diagrams in the use-case Special Requirements.

Does the communication sequence between actor and use case conform to the user's expectations?

Is it clear how and when the use case's flow of events starts and ends?

Behavior might exist that is activated only when a certain condition is not met. Is there a description of what will happen if a given condition is not met?

Are any use cases overly complex? If you want your use-case diagram to be easy to understand, you might have to split up complex use cases.

Does a use case contain disparate flows of events? If so, it is best to divide it into two or more separate use cases. A use case that contains disparate flows of events will be very difficult to understand and to maintain.

Is it clear who wishes to perform a use case? Is the purpose of the use case also clear?

Are the actor interactions and exchanged information clear?

Does the brief description give a true picture of the use case?

References

Rational Unified Process Use Case Checkpoints

Wiegers, K., Software Requirements, Microsoft, 1999

Project - Requirements Engineering Introduction The purpose of this project is to provide a more in-depth view of the topics covered in this course as well as expose tools and software currently used in industry. The project scenario is provided in this document and will act as the basis for the project deliverables that will be produced by each project team Project Scenario The following simplified requirements were modeled from an actual RFP (Request for Proposal) that was used to solicit vendors for the implementation of a customer relationship management (CRM) application.I have not included all the requirements since that would encompass several pages and would be too exhaustive for this semester Customer Intake 1. The system will be able to capture customer contact and demographic information including a. b. C. d. e. Customer Name Customer Address Customer Email Customer Phone Number (home and mobile) Customer Social Security Number 2. 3. The system will be able to identify a customer through an account number The customer service rep will be able to verify the customer's call using their personally identifiable information Case Management 1. The system will display account details for a customer, including a. Plan ID b. Plan Description C. Monthly Cost 2. The system will capture the details of a customer call, including a. Call Reason b. Call Notes The customer service rep will be able to transfer a case to another rep if a certain skill is needed to resolve the call (i.e. Spanish rep for Spanish speaking customer, etc.) The system will be able to keep track of the changes made to a case The system will be able to copy a case The system will capture the reason to close a case The system will allow for customer service reps to update a case 3. 4. 5. 6. 7. Project - Requirements Engineering Introduction The purpose of this project is to provide a more in-depth view of the topics covered in this course as well as expose tools and software currently used in industry. The project scenario is provided in this document and will act as the basis for the project deliverables that will be produced by each project team Project Scenario The following simplified requirements were modeled from an actual RFP (Request for Proposal) that was used to solicit vendors for the implementation of a customer relationship management (CRM) application.I have not included all the requirements since that would encompass several pages and would be too exhaustive for this semester Customer Intake 1. The system will be able to capture customer contact and demographic information including a. b. C. d. e. Customer Name Customer Address Customer Email Customer Phone Number (home and mobile) Customer Social Security Number 2. 3. The system will be able to identify a customer through an account number The customer service rep will be able to verify the customer's call using their personally identifiable information Case Management 1. The system will display account details for a customer, including a. Plan ID b. Plan Description C. Monthly Cost 2. The system will capture the details of a customer call, including a. Call Reason b. Call Notes The customer service rep will be able to transfer a case to another rep if a certain skill is needed to resolve the call (i.e. Spanish rep for Spanish speaking customer, etc.) The system will be able to keep track of the changes made to a case The system will be able to copy a case The system will capture the reason to close a case The system will allow for customer service reps to update a case 3. 4. 5. 6. 7