Meeting minutes
Clemens shares screen, Ken's framework document
Clemens: Megan added wikinotes to the table and I integrated my comments with hers
… in general we have terminology differences we need to align
… there is a table below that goes into details on the different elements
… what we have in wiki is page name, usage, supplimentary figures but not description
… license information added, drop down or free notes
… subdomain goal as part of the use case we don't have yet. we need to decide if we want predefined lists
… we have actors and other stakeholders
Megan: highlights from Ken's document, hadn't looked at the raw file
Clemens: I added comments in red, Megan green but those don't show, just the yellow in raw view
Ken: markdown differences is what I suspect
Clemens: tabular style a bit off
… we have what data needs to be provided by and to actors
… we just have freeform text for data flows
… I think we have basic flow of events in there
… the wiki doesn't support multiple scenarios for each use case
… there are some other free text fields Megan noted would be needed
… business rules and technology constraints use is unclear to me as is geographic scope - city, block, neighborhood, region...?
… in information viewpoint we have long list of topics we want to answer
… I started going through how we want to address
Megan: I think we have two separate topics, use cases and fields
… I had same sort of questions as you did. the discussed views are not captured presently in the wiki
… logical data model, data dictionary etc need definitions provided below
Clemens: we have this logical data model but with classes, attributes and properties we have something like a logical model, do we derive it or use a separate one?
Megan: in the table you're showing, we have concept of business terms and how they relate whereas the other models look at data elements
… is class more business terms and what is distinction
Ken: the ontology general models major classes and complex items. when you get into details that is more at the logical data model
… ontology is key business terms
Mark: you're right. although ontologies allow you to define down to whatever level of specificity you want, the instances of eg color can be defined elsewhere and extend the ontology as it sees fit
… we're not intending to provide that level of detail. we are more at the information viewpoint level, major classes and properties
… relationships with other classes...
Ken: that is what I'm calling the conceptual data model. all the data that might be of interest to systems would be specified but you don't necessarily present representational form
Mark: we can leave it as range for a property (vehicle speed example) or we could specify units
… we don't want to overcommit for what we're trying to do
Ken: we just need to identify how deep we want to go
… within a city data model. if people want a deeper specification with more detail, we just need to provide link
Clemens: I am still a bit concerned that we are going to get all the information requested
Mark: we had a conversation about a minimum set of points provided and not overburden what people should be provided
… if staying at conceptual level, a number of these issues become irrelevant
Megan: for this effort would we not go into logical data model?
Mark: that is where my mindset has been
Clemens: this says concerns within our scope and makes clear what we don't address
Mark: we will have enough challenge getting conceptual model
… taking things down to lower levels will reside at the different SDOs
Megan: do we define the connection to those levels or leave it to SDOs?
Mark: when people propose new concepts or patterns, to the extent they want to discuss how it connects to lower levels
… I am happy for them to describe that in the description portion but that is not where we are trying to achieve agreement
Clemens: would we provide guidance on what can be put in description fields?
Mark: I am fine with that
Clemens: 20+ fields may be a bit overwhelming to people
Ken: we can identify fields that need to be filled in and would like to see a way to manage what may become a very long list of use cases
Clemens: that is valuable to add so we can organize it
… can we organize wiki with subpages?
Megan: that would be possible
… we discussed coming up with an initial set of domains to provide initial organization
… avoid similar/redundant domains
Mark: agree having a top level would be good
Clemens: and examples for subdomains
Ken: ITS may have a good list for smart transportation
Clemens: we need to try to get use cases into domain buckets and see if that prompts reorganization
Megan: should we look at the fields that are up in the air and define today?
Clemens: for use cases?
Megan: yes
Clemens: summary is a short abstract we would need to add. it is a hassle to have a short and long description
… illustration is perhaps figure
Megan: I kept that generic but we may want to distinguish what they are
Clemens: information flow diagrams, etc can be provided
… we don't want to update wiki model and fine with generic upload figure and we can distinguish what it is visually
Ken: do we allow multiple figures to be uploaded?
… and then we would need to number or organize them
Megan: it currently allows that, you just need to name them
Clemens: we need a way to reference them
Megan: I'll make sure labels are displayed
Clemens: we have business rule assumptions. that would fit into description potentially
Ken: think I created this template from what some other group had developed, traced it to our concerns and items in yellow didn't match
Clemens: staying on conceptual level reduces that
… key words, geographic scope, temporal, if we can drop those likely not a big issue
Mark: I agree
Ken: I'm fine with that. I was pulling in information from different sources and wanted us to be able to argue for or against
Megan: if we have a short summary it should contain the goal
Clemens/Ken: that's fine
Clemens: we have participants and other stakeholders, I see those as actors
Ken: stakeholders may not interact with system and thereby not be actors
Clemens: do we want to distinguish?
Ken: worth capturing who you want to pull into defining
Megan: does identifying those other stakeholders change understanding of use case?
Ken: one of the key elements of developing use case is getting a hold of those stakeholders to develop that information
… we can be clear what we don't address in our documentation
Clemens: then we had extensions/inclusions
Ken: optional flows, events and how you link use cases together
… we could define separate use cases for each variant
Clemens: I would include small variations in description
… use case diagram we covered with figures
… scenarios is one of the questions, currently we only have one but assumption was there could be multiple
Ken: we might want to break out exceptions field
Clemens and Megan discuss auto-population of data flow
Megan: we are building use case and defining the data flow, creating definition for those key concepts
Mark: I would use defined classes instead of required or maybe linked or defined classes/properties
Ken: object classes might not exist yet but may want to list out data needed
Mark: then we have to distinguish
Clemens: part of process of creating a good use case is providing its information requirements, eventually defined and linked but could be initially just text
Mark: we can have required and defined
Megan: defined should be auto-populated
Ken: requirements as free text
Mark: agree to that too
Next meeting 1 April 10am ET