Meeting minutes
Logistics
<McCool> IEEE SWEBOK: https://
<McCool> update to requirements presentation including a template: https://
Agenda Review
<kaz> agenda for today
<kaz> IEEE SWEBOK (definition of "requirements")
Koster: Today we want to focus on the Use Cases
Meeting Minutes
Koster: We already reviewed them yesterday
Use Cases
Koster: First we'll have mm present
McCool: I had a presentation at TPAC, I extended the presentation and will upload it
<kaz> McCool's slides for TPAC (to be updated)
McCool: I added the terminology from the IEEE
… <maps the concepts from IEEE to Who, What, Why>
<presents the Requirements Template proposal>
McCool: Comments
Kaz: This is an initial proposal, do we want to do brainstorming on it?
McCool: Yes, I'd try to collect the outcome in a PR or an Issue
<creates a PR on the wot-usecases repo>
McCool: We do not have enough people to make a decision, so I'm just preparing the PR
Kaz: It is a bit odd editing wot-usecase from a wot-thing-description call
McCool: I'm writing the PR as co-chair of the group
<McCool> wot-usecases PR 305 - Create userstory-requirement.md (as an initial proposal)
McCool: The TD TF can create a db of user stories and link back to the use-cases
<McCool> it is up to the TD TF to decide how to organize work items (e.g. PRs/issues/lists in an MD files/assertions) - end state should be an assertion, however (e.g. a feature in the TD specification) for "capabilities". For Use cases, if one does not exist, it should be created (keep it abstract; don't need a ton of implementation details in use case, it should just state the purpose) and/or a category should be suggested (can be just in the user story, give a definition or link to at least one use case in the "details" section).
<McCool> or a category should be suggested (can be just in the user story, give a definition or link to at least one use case in the "details" section).//or a category should be suggested (can be just in the user story, give a definition or link to at least one use case in the "details" section).
McCool: I can put the above statements in a slide as well
Koster: It starts to look like a workflow now
Koster: It seems to me that the user-stories aren't fully created as use-cases
Koster: We have two templates: Requirements and Use Case
Luca: Use Case and Requirements are input from outside, Categories is just an internal detail to sort them out
Luca: Both Use Case and User Stories, no matter who submits them would be good to have the same way to ingest (e.g. Forms) and they should have the same IPR rules since they end up in our repos one way or another
Kaz: It seems to me that we're handling two levels of issues at once, (1) terminology of "requirements", "feature requests", etc., and (2) how to describe them based on additional templates. Given we have only 10 more mins, I'd suggest we focus on the first issue today, and talk about the templates and IPR issues later.
Kaz: Do we have consensus on the basic direction, e.g., need for clarifying terminology, workflow and templates?
<McCool> https://
<kaz> proposal: TD TF agrees on the need for clarifying the terminology (like "requirements" and "feature requests"), workflow and templates to describe them.
<kaz> proposal: TD TF agrees on the need for clarifying the terminology (like "requirements"), workflow and templates to describe them.
<kaz> [ we're out of time and continue the discussion next week. ]
<kaz> [adjourned]