Project Name: Team Members Client Contact

APPENDIX A Glossary of Terms and Acronyms

Download 275.64 Kb.

Page	3/3
Date	05.01.2017
Size	275.64 Kb.
	#7146

1 2 3

Requirements Shell (RS) Cards

APPENDIX A
Glossary of Terms and Acronyms

APPENDIX B
Scope of Work: Business Process Model

APPENDIX C
Actor Cards

APPENDIX D
Use Case Diagram

APPENDIX E
Transitional Matrix: BPM and Use Cases

APPENDIX F
Use Cases: Functional Requirements

APPENDIX G
Data Model
APPENDIX G

Transitional Matrix: CRUD (Create, Read, Update and Delete)

BLANK FORMS

Actor Cards

Actor Specification
Actor Name:
Type: (Primary/Secondary)	Personality: (I, E, R or F)	Abstract: (Yes/No)
Role Description:
Actor Goals:
Use Cases Involved with:

Use Cases
Initial Use Case Form
(Use case is described with a text narrative)

Use Case ID	(prefix your Use Case IDs with UC, to distinguish them from other models)
Use Case
Elaboration	Initial use case description
Actors
Description
Priority	(High, Medium or Low)
Non-Functional Requirements	(only those associated with this use case, if any)
Assumptions
Source

Base Use Case Form
(Use case is described with sequential flows of events
for sunny-day scenarios only – no conditional flows should be included)

Use Case ID	(prefix your Use Case IDs with UC, to distinguish them from other models)
Use Case
Elaboration	Base use case
Actors
Description	(brief)
Pre-conditions
Flow of Events	etc.
Post-conditions
Alternative Flows	(briefly describe alternative flows here for base Use Cases; extend this into complete conditional flows of events in the corresponding Elaborated Use Cases)
Priority	(High, Medium or Low)
Non-Functional Requirements	(only those associated with this use case, if any)
Assumptions
Outstanding Issues
Source

Elaborated Use Case Form

(Use case is described with sequential flows of events

for both sunny-day and rainy-day scenarios – start all-rainy day scenarios with “if” and “else” statements and then list the corresponding flows as either: conditional flows within this form; or as alternative flows in a separate form for alternative flows)

Use Case ID	(prefix your Use Case IDs with UC, to distinguish them from other models)
Use Case
Elaboration	Elaborated use case
Actors
Description	(brief)
Pre-conditions
Flow of Events (include conditional flows here as they occur)	If xxx Else etc.
Post-conditions
Alternative Flows	(briefly describe alternative flows here for base Use Cases; extend this into complete flow of events for Elaborated Use Cases, either here or in the next template)
Priority	(High, Medium or Low)
Non-Functional Requirements	(only those associated with this use case, if any)
Assumptions
Outstanding Issues
Source

Alternative Elaborated Use Case Form

(Use case is described with sequential flows of events

for sunny-day scenarios – and then listing all conditional flows or rainy day scenarios in a different section below. start all-rainy day scenarios with “if” and “else” statements

Use Case: UC-03 Eligibility Evaluation
Elaboration	Elaborated use case
Actors
Pre-conditions
Optimistic Flow of Events
Conditional Flows
Post-conditions

Elaborated Use Case Form w/Business Steps

(This is the same form as the prior Elaborated Use Case form, but it has two columns where you can differentiate system steps from business steps. Use cases normally only have system steps, but describing business steps may provide important context information for your application. It is important that developers can differentiate system actions from business actions in your use cases.)

Use Case ID	(prefix your Use Case IDs with UC, to distinguish them from other models)
Use Case
Elaboration	Elaborated use case
Actors
Description	(brief)
	System Steps	Business Steps
Pre-conditions
Flow of Events (include conditional flows here as they occur)	If xxx Else etc.	If xxx Else etc.
Post-conditions
Alternative Flows	(briefly describe alternative flows here for base Use Cases; extend this into complete flow of events for Elaborated Use Cases, either here or in the next template)
Priority	(High, Medium or Low)
Non-Functional Requirements	(only those associated with this use case, if any)
Assumptions
Outstanding Issues
Source

Use Case Form for Alternative Flows
(An Alternative Use Case MUST be associated with an existing Elaborated Use Case)

Use Case ID	(same ID as the base Use Case ID, but with suffix A1, A2, etc., for each alternative flow Use Case)
Use Case
Elaboration	(indicate whether it’s initial, base or elaborated use case)
Actors
Description	(brief)
Insertion Point	(step in Base Use Case where this alternative flow should be inserted)
Pre-conditions	(clearly indicate under which conditions the alternative flow is triggered)
Alternative Flow of Events
Post-conditions
Priority	(High, Medium or Low)
Non-Functional Requirements	(only those associated with this use case, if any)
Assumptions
Outstanding Issues
Source

Form for Extending Use Cases
(An Extending Use Case MUST be associated with an existing Elaborated Use Case)

Use Case ID	(same ID as the base Use Case ID, but with suffix E1, E2, etc., for each extending Use Case)
Use Case
Elaboration	(indicate whether it’s initial, base or elaborated use case)
Additional Actors	(only list actors not listed in the extended use case)
Description	(brief)
Extended Use Case	(ID and name)
Extension Point	(step in Base Use Case where it is extended)
Guard Condition	(pre-condition in the extended Use Case that causes it to execute)
Flow of Events
Conditional Flows
Post-conditions
Alternative Flows	(briefly describe alternative flows here for the Extending Use Case; extend this into complete flow of events in an Alternative Use Case form if needed)
Priority	(High, Medium or Low)
Non-Functional Requirements	(only those associated with this use case, if any)
Assumptions
Outstanding Issues
Source

Form for Included Use Cases
(An Included Use Case is generic and can be re-used and included in any other Use Case,
so it does not need to be associated with a specific Use Case)

Use Case ID	(prefix your Use Case IDs with IUC, to distinguish them from other Use Cases)
Use Case
Elaboration	(indicate whether it’s initial, base or elaborated use case)
Description	(brief)
Including Use Cases	(list all Use Cases that use this Included Use Case)
Pre-conditions
Flow of Events
Conditional Flows
Post-conditions
Alternative Flows	(briefly describe alternative flows here for the Included Use Case; extend this into complete flow of events in an Alternative Use Case form if needed)
Priority	(High, Medium or Low)
Non-Functional Requirements	(only those associated with this use case, if any)
Assumptions
Outstanding Issues
Source

Form for CRUD-Type Use Cases

(Some Use Cases do very little processing and a lot of data management; these use cases don’t have a lot of detailed flows to describe, but instead they contain a lot of data management steps – e.g., create, read, update and/or delete data; since database application developers know exactly what to do in such cases, it is often simpler to specify your flows broken down by CRUD activities and using simpler flows; since you will later need to use these use cases to identify data objects, the following use case format is appropriate for these use cases)

Use Case ID	(prefix your Use Case IDs with UC)
Use Case
Elaboration	(indicate whether it’s initial, base or elaborated use case)
Actors	(prefix actors with [P] for primary and [S] for secondary)
Description	(brief – but you may also want to say something like “this use case handles standard data management events for etc.)
Pre-conditions
Flow of Events	Create Data C1. C2. etc. Read Data R1. R2. etc. Update Data U1. U2. etc. Delete Data D1. D2. etc.
Conditional Flows
Post-conditions
Alternative Flows	(briefly describe alternative flows here for base Use Cases; extend this into complete flow of events for Elaborated Use Cases, either here or in the next template)
Priority	(High, Medium or Low)
Non-Functional Requirements	(only those associated with this use case, if any)
Assumptions
Outstanding Issues
Source

BPM/Use Case Transitional Matrix Form

BPM			Use Case
Step	Name	Type	UC 1	UC 2	UC 3	Etc.
P1
P2
P3
Etc.

CRUD Matrix Form

(Create, Read, Update, Delete)

Entity	Use Case
Entity	UC 1	UC 2	UC 3	Etc.
Entity 1
Entity 2
Etc.

Requirements Shell (RS) Cards

Not required for this project, but many requirements analysts find them useful to take field notes while you are gathering requirements. Fill one RS card for anything that a stakeholder describes that sounds like a requirement (functional or non-functional). One RS card may generate zero, one or many use cases or many RS cards may be consolidated into one use case. Think of an RS card as an organized way to take field notes when you are gathering requirements (i.e., “trawling for knowledge”).

Requirement Shell
Requirement No.:	Requirement Type:		Use Cases:
Description:
Rationale:
Source:
Fit Criterion:
Customer Satisfaction Rating:		Customer Dissatisfaction Rating:
Dependencies:		Conflicts:
History:		Supporting Materials:

Directory: 2013
2013 -> Annual InStructional unit plan
2013 -> The Ministry of Education and Science of Ukraine
2013 -> #1 a lifesafer of virginia inc
2013 -> Name(s): your name here team or Group #(if applicable): Professor’s name
2013 -> Alcott Local School Council (lcs) Meeting Minutes
2013 -> Table Of Contents introduction 2
2013 -> Supplemental demographic information
2013 -> 【Education&Working Experience】

Download 275.64 Kb.

Share with your friends:

1 2 3

Project Name: Team Members Client Contact

APPENDIX A Glossary of Terms and Acronyms

APPENDIX A Glossary of Terms and Acronyms

APPENDIX C Actor Cards

APPENDIX E Transitional Matrix: BPM and Use Cases

Requirements Shell (RS) Cards

APPENDIX A
Glossary of Terms and Acronyms

APPENDIX C
Actor Cards

APPENDIX E
Transitional Matrix: BPM and Use Cases