22
Requirements Use Case- IEEE BMS About Use Case Diagrams Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals. Customer Obligation 1. Review document for missing, incomplete, or incorrect content. 2. Return feedback promptly as the development team is currently developing the software based on this version of the use case. 3. the same 3-day period with the time required to respond. Establish And Main Cas Identifier and/or Name 1. Create or modify a customer profile within the system that is uniqu goal). Immediate notif tain Customer Profile Use e Goals in Context: ely identifiable (stakeholder 2. ication (to the system) of new or updated profiles 3. Capture data necessary to “better” manage customer relationships (accuracy, currency & pleteness,) com Channel: Business Justification (Scope) Capture Customer Profile for the support of IE EE business. Customers can establish or modify their own profile information w/BMS. Changes to profile information are recorded for historical purposes, and support of research and marketing activities. List of Actors (Primary, Secondary and Supporting) P rimary – Customer Secondary – Customer Information Provider (feed from another computer system) Supporting – IEEE Staff www.prestwood.com/psdp 1 Revision 3.02

Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

  • Upload
    others

  • View
    9

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

Requirements

Use Case- IEEE BMS

About Use Case Diagrams Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals.

Customer Obligation 1. Review document for missing, incomplete, or incorrect

content. 2. Return feedback promptly as the development team is

currently developing the software based on this version of the use case.

Provide feedback within 3 business days or notify us within3. the same 3-day period with the time required to respond.

Establish And MainCas Identifier and/or Name

1. Create or modify a customer profile within the system that is uniqugoal). Immediate notif

tain Customer Profile Use e

Goals in Context:

ely identifiable (stakeholder

2. ication (to the system) of new or updated profiles 3. Capture data necessary to “better” manage customer relationships (accuracy, currency &

pleteness,) com

Channel:

Business Justification (Scope)

Capture Customer Profile for the support of IE

EE business. Customers can establish or modify their own profile information w/BMS. Changes to profile information are recorded for historical purposes, and support of research and marketing activities.

List of Actors (Primary, Secondary and Supporting)

P

rimary – Customer Secondary – Customer Information Provider (feed from another computer system) Supporting – IEEE Staff

www.prestwood.com/psdp 1 Revision 3.02

PSDP Help
Use this template to document a single Use Case. For documenting multiple use cases, use the 2-Requirements Specification (UML).doc template.
PSDP Help
Rationale or goal(s) of use case.
PSDP Help
List of actors. Optional, add a brief description and notes.
Page 2: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

Assumptions and Pre-Condition(s) 1. Profile information is supplied in electronic form by customer information providers. Format of

data feed must be compatible with BMS (Note – the system must provide the ability to process data that is not received in electronic form)

2. Actors will be authenticated/authorized before allowing updates to customer profiles. 3. Customer is the owner of their core customer profile data. Other than IEEE Staff initiating a

request on behalf of the customer, only the customer can create or modify his/her own core profile information.

4. Customer profile may be created as a result of another use case (example, establish SPO) 5. Customers requesting an interaction with the IEEE will have a customer profile created and saved

in the system. 6. Opt-in/Opt-out preferences will be maintained at the customer level, however, the actor, or staff

acting on behalf of the customer will have the ability to change those preferences at each offering level. (Over-riding the customer level choice for that particular offering).

7. Customer records and their associated data (related to organizations), established through BES, must be available to the individual customer profiles – (refer to issue #91 requiring the ability to link individual customers to the company they work for).

8. Data owners are responsible for maintaining and/or updating their data. 9. Various events (such as conference/meeting attendance) will be associated with the customer

record via the order process.

Trigger:

www.prestwood.com/psdp 2 Revision 3.02

PSDP Help
Conditions that must be true for use case to terminate successfully.
Page 3: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

Normal Course (Description) Establish New Core Profile: 1) Actor indicates to create a new core customer profile 2) System prompts for core profile information (based on customer type, refer to list of data elements) 3) Actor provides core information and indicates to save 4) System checks to see if this is a duplicate record based on defined key data elements 5) If potential duplicate record exists, system asks actor “is this you” (and presents potential duplicate

record) a) If actor chooses existing record, system allows for update – proceed to “Maintain Customer

Profile – Change Core Profile or Add/Update Supplemental Information “ alternative course. b) If actor indicates new record, use case continues.

6) System validates core information (see “Incomplete Core Profile” exception), saves it, and presents a customer number (a unique identifier) back to the actor (See “Unique Identifier Confirmation” exception

7) System assigns initial customer type (see Customer Type Assignment business rule) 8) System assigns the customer to their respective geographic location

(region/council/section/subsection) depending on customer type (refer to Geographic Assignment Rule)

9) System provides opportunity to create IEEE Web Account a) If actor chooses to create a web account, system directs actor to Create IEEE Web Account

Process b) Upon completion of the create web account process

i) electronic services are available to customer based on business rules. ii) Actor is returned to Create Profile

10) System provides opportunity to add supplemental profile information to customer record (See data requirements for list of supplemental profile information) a) If actor chooses to add supplemental profile information, proceed to alternative course

“Maintain Customer Profile - add supplemental information” b) If actor does not wish to add supplemental information, Use Case ends

Alternative Course(s) (Variations) (if different types of customers require different behavior, list as an alternative course)

www.prestwood.com/psdp 3 Revision 3.02

PSDP Help
Basic or normal steps documenting the interaction between actors and use cases.
PSDP Help
Document alternative paths (variations in the steps listed above).
Page 4: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

Maintain Customer Profile Changes to Core Customer Profile 1) Actor indicates to change core customer profile 2) Actor is authenticated/authorized (Refer to Authentication/Authorization business rule) 3) Actor updates allowable core customer profile information and indicates to save

a) If actor changes a “ship-to” address, the system checks to see if there are any open orders with that address. If yes, the address on that order will be changed as well.

4) System displays a summary of changes requested by Actor & prompts actor to confirm or edit changes a) If actor chooses to edit, system allows changes to be made and revalidates

5) Actor confirms and indicates to save 6) System validates based on business rules (Refer to “Core Profile Information Validation” business rules

) a) If data is validated, system saves, applicable business rules/routines are executed (ex. Member

Geographic Assignment) and customer change history is updated. b) If data does not pass validation, actor is prompted to fix or cancel action.

7) System sends confirmation of change to Actor via preferred method of communication 8) Use Case ends Add supplemental profile information 1) Actor indicates to add supplemental profile information 2) Actor is authenticated/authorized (Refer to Authentication/Authorization business rule) 3) Actor provides supplemental information (refer to data elements and associated business rules) 4) Actor indicates to save 5) System validates based on business rules specific to the supplemental information

a) If data is validated, system saves. b) If data does not pass validation, actor is prompted to fix or cancel action.

6) System sends confirmation of change to Actor via preferred method of communication 7) Use Case Ends Change supplemental profile information 1) Actor indicates to change supplemental profile information 2) Actor is authenticated/authorized (Refer to Authentication/Authorization business rule) 3) Actor changes supplemental profile information (refer to data elements and associated business rules) 4) Actor indicates to save 5) System displays a summary of changes requested by Actor & prompts actor to confirm or edit changes

a) If actor chooses to edit, system allows changes to be made and revalidates 6) Actor confirms and indicates to save 7) System validates based on business rules specific to the supplemental information

a) If data is validated, system saves and customer change history is updated. b) If data does not pass validation, actor is prompted to fix or cancel action

8) System sends confirmation of change to Actor via preferred method of communication 9) Use Case Ends Delete supplemental profile information 1) Actor indicates to delete supplemental customer information 2) Actor is authenticated/authorized (Refer to Authentication/Authorization business rule) 3) Actor deletes one or more supplemental data elements and indicates to save . 4) System displays a summary of the information requested to be deleted by Actor & prompts actor to

confirm changes 5) Actor indicates to save

www.prestwood.com/psdp 4 Revision 3.02

PSDP Help
Document alternative paths (variations in the steps listed above).
Page 5: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

6) System validates based on business rules specific to the supplemental information a) If data is validated, system permanently removes the sections from the profile b) If data does not pass validation, actor is prompted to fix or cancel action.

7) Use Case Ends

Exceptions Data Feed Validation errors If the system determines the actor is the customer information provider, (example feed file), all discrepancies and errors are logged and available for reporting for manual processing by staff. No profile information would be created under an error condition. Duplicate Profiles

1. During the creation of a profile, the system finds potential duplicates profiles based on matches to one or more core data elements.

2. The system will present the matches and ask the actor if one of them is the customer’s profile a. If the actor identifies an existing profile, the system discards the new one, and allows

the Actor to continue with Alternative path, “Maintain Customer Profile” b. If the actor confirms that the new profile is unique, then the use case continues

Incomplete Core Profile

1. If required core profile data elements are not provided, the system prompts the actor for the missing information.

2. If all required information is provided, use case continues, else use case fails. Unique Identifier Confirmation

1. If staff is acting on behalf of the customer, confirmation including unique identifier is sent to customer via preferred method of communication

2. If the actor is a customer information provider (data feed) the update to profile process should trigger correspondence code to customer record in order for a subsequent process to send confirmation to customer which includes a unique identifier ( sent to customer via preferred method of communication).

Extensions Customer Reports Use Case Place order View History of profile changes (separate use case)

Includes

www.prestwood.com/psdp 5 Revision 3.02

PSDP Help
Description of error conditions.
PSDP Help
Variations on this use case that specializes it. Present those use cases that have an extends relation with the current use case.
PSDP Help
List use cases that are “called” from this use case.
PSDP Help
List use cases that are “called” from this use case.
PSDP Help
Variations on this use case that specializes it. Present those use cases that have an extends relation with the current use case.
Page 6: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

Post-Condition: - Success:

1. Normal Course - Core with or without Supplemental customer profile information is stored in the system.

2. Alternative Course – Updated information is recorded in the customer history 3. History of profile changes is saved in BMS 4. The initial type/class of the customer will be established once the profile is created. (Refer to

customer type business rule). The customer type will be updated (if applicable) based on customer profile changes.

- Failure

1. New profile or updated profile rejected; not stored in the system.

Business Rules: (Actual rules should be listed in the Business Rule spreadsheet, and referenced here) Name validation rules When entering Names, no numbers should be accepted in this field, however, spaces and character ‘ are allowed Physical Address Validation Rule If country of the address is U.S., the street, city, state and zip must be provided. If the country of the address is Canada, the street, city, province and country & postal code must be provided If the country of the address is not US or Canada, the street, city and country must be provided. For each address type, one address must be designated as primary (preferred) Address is CACE or CASS certified – preferable addresses are certified real time Telephone number format rules

·In North America +1 area code XXX XXXX Example: United States +1 732 123 4567

·Outside North America +country code city code XXX XXXXX Example: Belgium +32 3 770 2242

The phone number is preceded by a '+'. The '+' represents the code needed to access the international trunk line which is different for each country, for example in the United States it is '011' and in Belgium it is '00'. No other punctuation should be used Email Address validation rules

Do not allow spaces Do not allow commas @ must exist only one @ can exist

www.prestwood.com/psdp 6 Revision 3.02

Page 7: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

allow upper and lower case

Member Geographic Assignment Business Rule: (BR24) Copy of Geographic Assignment Rule:(BR24) from SPO - Added traceability to UC1 Members are assigned or re-assigned to a geographic structural SPO based on the address designated as preferred. No reassignment is done for those who selected contiguous membership. If the member’s contiguous SPO is being inactivated or dissolved, members must be reassigned to SPO based on their preferred address

Listed below are business rules (and their owner) that are still outstanding:

1) Core Customer Validation Rule (Customer Team to supply) – Note, team will put the list of required core data elements once we received the valid customer types.

2) Audit Descriptor business rules (ABC/BPA) – Are there rules for when this info is required? Are Audit descriptors are mandatory if print subscriptions are purchased? (Marketing and Spectrum dept)

3) Consent For Use business rule - Need business rules for customer consent. For example, in purchasing a prospect list that will be used to create customer profiles, should we require pre-consent of individuals on the list as condition of purchase? What about prospect records from IEEE conference registration? (Sales & Marketing, Member Services)

4) Authentication/Authorization business rules – (Vera S. and Mary L) 5) Customer Type Assignment business rule (need from Marketing - Terry)

www.prestwood.com/psdp 7 Revision 3.02

Page 8: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

Data Requirements: (move to data element table below) Supplemental record (Partial list) (Next to each item of supplemental information is the team of SME’s considered as the data owners. Those identified should review the data element list for accuracy and completeness) 1) Customer Identifying (personal and primary/secondary contact information, special circumstance,

various payment methods used (credit card numbers, bank account information) – Member & Customer Service to provide

2) Employment Histories (include special circumstance, i.e. unemployed) - Marketing 3) Education Histories – Education, Student Services, Vera Sharoff 4) SPO Participation Histories – Vera, Rosanne & Colleen

a) Officers (this includes actual position held and candidacy) b) Other Participants

5) Demographics (ability to capture information and tie to a customer record – example: age range or salary range obtained from questionnaire) – Team & SME (Institute Research)

6) Certifications – Education, Student Services & Marketing 7) Additional Associations/ Sister Societies – Corporate Activities 8) Other Roles (Speakers, Authors, Editors, elected and non-elected) – Team 9) Award Histories – award name, award sponsor, citation (Corporate, Technical Activities &

Membership) 10) Financial Advantage Participation (This may possibly be obtained through purchase history) – Mirelle

White & Michelle (FAP) 11) Audit Descriptors (BPA -refer to business rules) – Marketing & Spectrum 12) Interest Profile – Technical Activities, Marketing, Computer Society

a) Areas of interest (based on event/purchase/activity/behavior history of the individual) b) Areas of interest (based on information provided – Education, Certifications) – Marketing? c) TIP Codes/ Areas of Interest – Technical Activities d) Overlay information (member segmentation category) - ?

13) Evaluator Information 14) Record of Correspondence – Member Services (tied to customer interaction use case) 15) Purchase & transaction history including preferred method(s) and conditions of communication &

method of payment at the offering level (i.e. subscriptions, memberships, contribution history, conference or meeting (event) attendance) – Team propose & order team to verify

16) AR Credit Profile

www.prestwood.com/psdp 8 Revision 3.02

Page 9: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

Notes / Issues / Special Requirements 1) View History (An online history of the entire customer profile is described in the Report Use Case) 2) Customer needs to be associated with a type classification (example: prospect, member etc.) 3) TIPs are associated to customers in three ways: customer selection, purchase history or conversion

of TIP code 4) Conference-Related Data – What information related to conferences needs to be available in BMS. 5) Record duplication - Need to determine if customer exists in the system at the time of establishing

new customer profile. Ask individual “Is this you”, Ask CSR “is this him/her”? 6) Need to address tracking and purging of duplicate records that occur in the system. Action Items When do we turn services on & what are the minimum data requirements to start each service Test Cases: Member (Higher Grade) Student Member Affiliate Non IEEE Member Ideal test case for Integration of products/offerings, customer, transaction (all BMS) plus organizations (BES); Complimentary allotted individual memberships (IEEE SA)

www.prestwood.com/psdp 9 Revision 3.02

Page 10: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

ISSUES: Closed Issue: How are certain positions tied to customers? (For positions that are not elected, such as nonmember associated editors) Does the customer self-identify, or is there an associated business process. (issue 74) – Resolved: Customers are able to self-identify roles but must be submitted to appropriate staff for confirmation (refer to customer interaction use case) Proposal is that positions held will be attached to the customer via the order process. If this is not possible, a web based form should be made available which allows the actor to tie position codes with customers. Open Issue: How is customer type determined? Is it expected that the system makes determination? Need to discuss further categorization of customers (member segmentation, behavior pattern, prospect. Team believes that this will be handled outside of establishing Customer Profile -See Product and offerings, event history and sales analysis use cases (issue #73) Open Issue: Employment - Need to discuss hierarchical relationships with BES team (Issue #71, #91) – need ability to tie individuals to their specific company location (as it relates to employment history) i.e. tie customer profile to specific location at AT&T Closed Issue: Need to readdress where/when the “providing access id” occurs (at establish customer or based on purchase or other) (Issue 89) Closed Issue:Should addresses have effective dates associated with them to automatically accommodate temporary location (addresses should either have effective dates tied to them, or provide the ability to specify an address type of “temporary” with effective dates. Closed Issue: When do we request information on Employment, such as Company Name. Do we make it required only for certain customer type (company information can be requested, however, it is not mandatory) SPECIAL (SUPPLEMENTAL REQUIREMENTS)

1. What is the criterion for defining a uniquely identifiable customer? (The data elements that should be used to uniquely identify a customer need to be defined. These would be the data elements that the system would use to check for duplicate records when a new profile is being established - OUTSTANDING)

www.prestwood.com/psdp 10 Revision 3.02

Page 11: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 11 Revision 3.02

Data Requirements -+: Term Field(s) Possible Values Required/

Optional Defaults Notes

Core Customer Profile

SPO or Individual

indicator S, I Required This is used by the

system to determine which data elements are required to establish a Core customer profile

Customer Number Alpha/Numeric Required Generated by the system

Customer Type ?? Last Name Optional Required, if Individu Middle Name Optional Initial is acceptable First Name Optional Required if Individua Prefix Optional Suffix Optional Preferred Name Optional Customer provided

Name SPO Name Optional Required if SPO Gender Optional Date of Birth DD/MMM/YYYY Optional Some Business

Process requires it and will be asked during these processes. Example Life Member

Physical Address

Optional Can be multiple Required if email is not provided. Also refer to business rules

Company Name/ Street line 1

Required Rules for length If work Address, Street line 1 can be Company Name

Street line 2 Optional Street line 3 Optional City Required Automatically

populated based on Zip code if Domestic

This should be a term that has exists in the use case, which is a nickname for several fields.
Each field that explains it associated term.
A complete list of values for the field.
If the field is required when the data is initially entered into system specify required.
Page 12: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 12 Revision 3.02

State Optional Two digit if US –Automatically populated based on Zip Code if Domestic

Province Optional For Canada, automatically populated based on Postal Code

County Optional Populate based on Zip Code for US

Postal Code Optional Required for US Canada and specified countries

Country Required Address Type

(Usage) Work, home, School, Work, Bill-to, Ship-to

Required

Location Optional Oracle Legacy. Is this still needed

Preferred Flag Optional

Email Optional Required if physical address not provided

URL Optional Auditing/Identifier Mother’s

maiden name Required Customer supplied

Phone Optional Country Code Optional Required if user

provides telephone number

Area / City Code Optional Required if user provides telephone number

Telephone Number Optional Required if user provides telephone number

Extension Optional Type Fax, Cell,

pager, work-phone, home-phone, school

Geographic SPO Assignment

SPO Number Derived from Preferred

Page 13: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 13 Revision 3.02

Address. Manually entered if customer requests contiguous assignment

SPO Name Derived from Preferred Address. Manually entered if customer requests contiguous assignment

Contiguous Flag Yes No Default to No. If yes allow update o

Communication Preference

Communication Method

Customer has the ability to indicate the preferred method of communication at customer level. Customer also has the option of defining the preferred communication method at each offering level.

Consent for use flag for Method of communication

Yes/No

Supplemental Profile Information

Recruiter Info Recruiter Member

# Member number of

the recruiter Payment Information

Payment Method Credit Card Debit Card Wire Transfer

Optional

Credit Card Type MasterCard Visa American Express Diners Club

Optional Required if providing credit card information

Credit Card Number

Numeric Optional Required if providing credit

Page 14: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 14 Revision 3.02

card information Expiration Date Date Optional Required if

providing credit card information

Cardholder’s Name Optional Required if providing credit card information

5-digit Zip code numeric Optional Required if providing credit card information & US Customer

CVVC numeric Optional Required if providing credit card information

Bank Name Optional Bank Number Optional Branch Optional Branch Number Optional Description Optional Account Name Optional Account Number Optional Check Digits Optional Check Digits

Description Optional

Currency Optional Is this needed? Primary flag Yes

No Optional

Start Date End Date Discount Eligibility

Code Optional View from profile,

but the information resides with the order

AP Vendor flag Optional Auto CC flag What is this Hold Mail Start

Date Optional For undeliverable

mail or request from customer

Hold Mail End Date

Optional For undeliverable mail or request from customer

IEEE Mailings Default is Yes Required Overall Opt in Opt Out

Third Party Mail Default is Yes Required Last Mail Flag

Update Date DD-MMM-YYYY

Required System generated when the mailing flag fields are updated

Page 15: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 15 Revision 3.02

Send Ack. Letters Flag

Is this needed since it will be included as part of the offering

Employment / Professional Histories

Company Name

Division/ Department

Title / Position Years in Position Years in

Profession

Education Histories

School Name Captured at ordering

Program Degree Status Attending,

Inactive, Graduated

Start Date DD/MMM/YYYY End Date DD/MMM/YYYY Customer SPO Position History

Position Code List Populated if entered on SPO officer record

Position Description

Populated Populated if entered on SPO officer record

Additional Position Information

Populated if entered on SPO officer record

SPO Customer Number

Populated if entered on SPO officer record

SPO Name Populated if entered on SPO officer record

Term Start Date Populated if entered on SPO officer record

Term End Date Populated if entered on SPO officer record

Out of Office Date

Populated if entered on SPO officer record

Bio attachment Position Statement attachment Year

Page 16: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 16 Revision 3.02

Candidacy List Petition Candidate, N&A

Other participation

Demographics Demographic Code Demographic value Effective start dt Effective end dt Market segmentation

Currently handled as a type of demographic

Maillists Currently handled as a type of demographic

Electronic Opt-in Opt-out

Handle as a demographic

Certification Certification Name PE, EIT Computer

Society, Continuing Education

Date DD/MMM/YYYY Status State Country Additional Associations /Sister Societies

Association Id ACM Is this still needed?

Association Name List Displays by system based on Assoc ID

Start Date Date End Date Date Other Roles Speaker,

Author, Editor

Could be demographics

Speaker Info

Expertise Code

Description Display description of expertise code

As Of Date

Page 17: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 17 Revision 3.02

Speech Date

Topic

Rating

Total Members Wouldn’t this info be held at the event level (on the spo) vs. on the person’s record?

Total Nonmembers Wouldn’t this info be held at the event level (on the spo) vs. on the person’s record?

Corresponding Meeting Info (which meeting the speaker spoke at)

Meeting Is this info kept on the meeting record (or offering) and then tied to the speaker?

Meeting sponsor Is this info kept on the meeting record (or offering) and then tied to the speaker?

Meeting type Is this info kept on the meeting record (or offering) and then tied to the speaker?

Meeting scheduled date

Is this info kept on the meeting record (or offering) and then tied to the speaker?

Meeting topic Is this info kept on the meeting record (or offering) and then tied to the speaker?

Award Histories

Award Code list Optional Required if start to enter award information

Award Name list Optional If award code is

Page 18: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 18 Revision 3.02

entered, Award Name is populated.Required if start to enter award information

Award Description list Will populate based on the Award Code

Sponsor List Optional Will populate based on the Award Code

Award Year Year Optional Press Date Date Optional Is this needed?

Computer Society Citation Optional Presentation Site text Optional Is this needed by

Computer Society & Awards Staff?

Category List Optional Is this needed by Computer Society & Awards Staff?

Conferences Attended

Data Source: Conference Management Database, External Data Feed or manually entered by Actor

Conference Name Conference

Acronym

Date of Conference

Location Financial Advantage

Broker Code list Optional Broker Code

Description Optional Populate based on

code FAP Code list Optional FAP Code

Description Optional Populate based on

code Effective Date Date Optional Cancellation Date Date Optional Audit Descriptors

Line of business Coded values from audit bureau

Job function Job responsibility Job title

Page 19: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 19 Revision 3.02

Audit info date Date info provided from customer

Job title (text) Free form text- allows the customer to write in specific title.

Interest Profile

Areas of Interest Based on event/purchase/ activity/behavior history

Areas of Interest Based on information provided – Education, Certifications

TIP Codes TIP Code No. TIP Description Rank Source Is this needed –

Computer Society to address

As of Date Date End Date Date TIP Job Function

Code Place holder for

Communication Society to address for future implementation

TIP Job Function Description

Place holder for Communication Society to address for future implementation

Overlay information

Market Segmentation category

Duplicate of data element above.

Correspondence Tracking

Alternate contact Information

Business Descriptors

SIC For company records only?

Tax ID For company records only?

D&B Number For company records only?

Page 20: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 20 Revision 3.02

Special Circumstances

Unemployed

Minimum Income Retired Totally Disabled Partially Disabled Preferred method(s) and conditions of communications

Opt-in, Opt-out

Evaluator Data (Certifications) Certification Code Optional Need to obtain

values from Education Dept

Description Description of code should be displayed based on code value

Nominate Date Training Date Training Location

Appointed Date Expire Date Evaluator Assignments

Certification Code

Nomination Date School Id/# School Name Program Code Accreditation Code Scheduled Date Rating Status Actual Date Membership Data

Info you would want to see about all memberships – in general

Join date # of years of

service

Grade

Page 21: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 21 Revision 3.02

Term start date Term end date Subscription Data

Pub/service identifier

Term start date Term end date Total # of years Contribution History

Fund contributed to

$ amt of contribution

Date of contribution

Revision History Date Version Description Author

08-JAN-2004 1.0 Initial Version Lori Potter & Mary Laties

12-FEB-2004 1.1 Team Reviewed and added to the happy path and other

Team

13-FEB-2004 1.2 Team Review and modifications Team

18-FEB-2004 1.3 Added some notes re issues Mahrukh Cama

08-APR-2004 1.4 Changes based on team review Lori Potter

09-APR-2004 1.5 Added data elements for “evaluators” Lori Potter

13-APR-2004 1.6 Modified Normal and alternative path as per team review

Mahrukh Cama

15-ARP-2004 1.7 Modified Normal and alternative paths and Exceptions based on J. McAllister’s review comments. Also updated Data Elements

Mahrukh Cama

16-APR-2004 1.8 Team Workshop – Reviewed and modified Data Elements

Mahrukh Cama

20-Apr-2004 1.9 Team Workshop Review – modified Data Elements

Mahrukh Cama

29-Apr-2004 2.0 Team Workshop Review – modified and added data elements

Mahrukh Cama

Page 22: Requirements Use Case- IEEE BMSewh.ieee.org/cmte/itsc/committee/bms_use_case_sample.pdf · Use this template to document a single Use Case. For documenting multipl e use cases, use

www.prestwood.com/psdp 22 Revision 3.02

04-May-2004 2.1 Team Workshop Review – added data elements and reviewed against Oracle

Mahrukh Cama

11-May-2004 2.2 Removed duplicate from Normal course

Mahrukh Cama

02-June-2004 2.3 Moved business rules from the BR document and made some changes

Mahrukh Cama

16-JUN-2004 2.4 Updated document based on customer team review meeting held 6/15.

Lori Potter

26-JUN-2004 2.5 Updated document –resolved one of the outstanding issues listed (Geographic Assignment)

Mahrukh Cama

7-Jul-2004 2.6 Updated document – Added traceability to BR29 from UC32 Web Account

Mahrukh Cama