Profiles Meeting 7/8
How might one capture a use case to inform xAPI-relevant requirements?
July 8, 2020, 3pm Eastern
Email eva@makingbetter.us to be added to the invite
Please join today’s meeting from your computer, tablet or smartphone.
https://global.gotomeeting.com/join/665670021
You can also dial in using your phone.
United States: +1 (312) 757-3121
Access Code: 665-670-021
Team
Host: Aaron Silvers
Community Manager/Secretary: Eva Rendle
Producer: Megan Bowe
Attendees:
Jono Poltrack
Tom Creighton
Jason Haag
Rob Chadwick
Florian Tolk, Ivan Martinez-Oritz, TJ Seabrooks, Michael Thompson, Chris Romero, Marcus Birtwhistle, Tobi Echevarria, Kristi Eager, Lidmila Janda, Lang Holloman, Viktor Haag, Rachel Ruster, Petra Andre, Jeff Clem, Avron Barr
Please join us for a discussion on the topic, “How might one capture a use case to inform xAPI-relevant requirements?”
•Objective:
Through regular, open discussions, participants will help identify enabling and/or disabling policies and practices, as well as technical considerations, in leveraging xAPI Profiles (from one or a network of xAPI Profile Servers).
•Exit Criteria:
TAGxAPI will submit an IEEE LTSC technical report for publication, documenting learnings from this series of discussions in Q3 2020
Use Cases
A use case is a written description of how users will perform tasks on your website. It outlines, from a user’s point of view, a system’s behavior as it responds to a request. Each use case is represented as a sequence of simple steps, beginning with a user's goal and ending when that goal is fulfilled.
How to Write a Use Case
Identify who is going to be using the thing.
Pick one of those users.
Describe what that user wants to do. Each thing the user does becomes a use case.
For each use case, determine on the normal course of events when that user is using the thing.
Describe the basic course in the description for the use case. Describe it in terms of what the user does and what the system does in response that the user should be aware of.
When the basic course is described, consider alternate courses of events and add those to "extend" the use case.
Not enough to cover the normal path, but other paths that could occur
Look for commonalities among the use cases. Extract these and note them as common course use cases.
Repeat these steps for all other users.
Use cases inform requirements which inform data models
Account for the data to be generated and used by a system or systems, both logical and physical.
Provide names, definitions and notes describing the data model elements.
Accompany implementation guidance, such as data types, keys, indexes and views that are critical to the challenges addressed by the data model(s).
Describe business rules in terms of relationships (referential constraints) and values (restrictions
Identify factors to secure data, data sources and any rules to be maintained.
Define governance plans, including enterprise-level collection details (Master Data Management), data quality and retention policies.
The goals of the effort?
•Design Anew?
•Integrated System Support vs Mobile vs eLearning
•Blended curriculum for orienting and onboarding recruited talent
•A Covid-19 OSHA Hazard Prevention Management certificate program
•Append, Augment or Retrofit?
•Understand the learner’s experience with
•The user interface
•The navigation
•The assessment
•The content
•Demonstrate Comprehension
•Supporting industry standards and competencies
•Inform machine learning, business processing or automation efforts e.g. HRIS or EHR systems
Parts of a Use Case
Actor
Anyone or anything that performs a behavior (who is using the system)
Stakeholder
Someone/something with vested interests in the behavior of the system under discussion (SUD)
Primary Actor
Stakeholder who initiates an interaction with the system to achieve a goal
Preconditions
What must be true or happen before/after the use case
Triggers
This is the event that causes the use case to be initiated.
Main success scenarios [Basic Flow]
Use case in which nothing goes wrong.
Alternative paths [Alternative Flow]
These paths are a variation on the main theme. These exceptions are what happen when things go wrong at the system level.
Will not have solutions – while trying to write requirements
Start with a User Story
A User Story is a note that captures what a user does or needs to do as part of her work.
Each User Story consists of a short description written from user's point of view, with natural language.
Unlike the traditional requirement capturing, User Story focuses on what the user needs instead of what the system should deliver.
This leaves room for further discussion of solutions
User Stories won’t tell the entire story
User Stories contain a user’s role, goal and acceptance criteria.
Use Cases contain equivalent elements: an actor, flow of events and post conditions respectively (and usually a lot more).
The details of a User Story may not be documented to the same degree as a Use Case.
User Stories deliberately leave out a lot of important details as they are meant to elicit conversations by asking questions during scrum meetings.
Small increments for getting feedback more frequently, rather than having more detailed up-front requirement specification as in Use Cases.
Example xAPI Profile User Stories
As an Instructional Designer or Authoring Tool Vendor I need clear statement templates and any associated patterns when choosing what statements to send in order to avoid unfortunate misunderstandings
As an Authoring Tool Vendor I need strong normative and descriptive guidelines for presenting profile information when designing my interfaces in order to meet experience author needs
Need to make sure I understand the information that comes back from Profiles so I can help folks author
As a Developer, I need to discern the information in profiles fluently when programming in order to avoid reinventing the wheel.
As a Learning & Development Manager I need to restrict/filter/assort incoming data to this profile when adopting data strategies in order to keep indexing and analysis clean and relevant.
In order to make sure processing and optimizing data, need filter data that we actually need
Actor + basic flow = MVP use case
Stronger use case
Actor
Basic Flows
Alternative Flows
Stronger Use Cases
Strongest Use cases add
Preconditions, post conditions, and business rules
Discussion question:
What are examples of details that could influence your xAPI PROFILE decisions?
Lang Holloman - identifying system errors/issues the end-user may be experiencing...GET requests returning invalid as an example
Jono Poltrack – Patterns.. order of events
Lidmila Janda – type of user
Micahel Thompson – security level access
Megan Bowe – alignment with existing profiles
Kristi Eager question – had discussion with peers this past week: do we create new profiles or should we reuse what’s out there?
When do you create new or use old?
Aaron Silvers answer – a little fuzzy, not tons of profiles in general yet
What concepts have already been designed
We should look at why we put a profile together –
Scorm, cmi5 – people putting these together in one place to find or reference
Not a great reason to put together a profile, creating a lot of duplicates in same collection, not really adding value
Triggers – new modality, basic interaction patterns,
Example – Mobile profile
Performance support
5 years from now, should have more specificity and confidence of how to approach
Thank you for all your participation and feedback – has helped with context and gaps to fill for community
Slides from today’s meeting: