Re: New action on UCR group / Proposal for requirement numbering

  Hello Karen,

> issue is both having discrete numbers 

  this is covered by both approaches

> and having the requirements be visually more prominent

  there is the option to reverse the document order putting the requirements in front of use cases.
  I already ask for proposals / requirements of formating enhancements with no resonance.
  We may discuss the available options today, among others the resolution and removal of
  "note" and "issue" sections.

> At the moment, the requirements don't show in the table of contents

  hmm, they are located at the bottom of the page and not initially visible,
  but they are (as any other named section) part of the navigable TOC

> it's not easy to "eyeball" them in scanning the document. So the task
> appears to be creating both numbers that we can refer to for clarity as
> well as increased visibility of the requirements themselves. I'll let
> others weigh in on whether the numbering below achieves that.

  yes, and if rejected a concrete proposal is need

> Other options include pulling the requirements into a separate document
> where they are easily scannable, but that may be best done after they've
> been approved. I can imagine that the editors of the three deliverables
> will want to be working with a defined list of requirements.

  this is unusual, the use cases provide a mandatory interpretation context.
  All the W3C UCR specifications consulted maintain them as part of same document.

  Talk to you soon, best regards

> On 9/23/17 4:53 PM, Jaroslav Pullmann wrote:
>>   Dear Karen, dear all,
>>   there were some discussions on the numbering approach for requirements, among others:
>>    1) continuous index: R1 ... RN:
>>    PROS:
>>   - straightforward
>>    CONS:
>>    - possibly high index numbers, potential for mistakes
>>    - absolute index prevents distributed work (editors rely on mutual changes of single shared index)
>>    - purely numerical index, no relation among items
>>   2) discrete index groups based on requirement's topic: RVers1 ... RVersN, RProv1 ... RProvN
>>   This approach involve the following steps:
>>   a) for each requirement identify a topic / main tag, e.g. "version". The assumption here is, that there should be at least
>>   one such tag (otherwise to be create) and there a requirement should be focused enough to map naturally to a single one
>>   b) create ID using tag's mnemonic abbreviation and current index: "RVers2". The index increments by group, not globally
>>   PROS:
>>   - easy to maintain small, "local" index
>>   - distributed work possible
>>   - items are naturally related
>>   - makes use of and evaluates tagging
>>   CONS:
>>   - requires to decide on requirements main topic (which is indeed o.k.)
>>   Personally I am in favor of option 2) and provided a sample numbering of the whole requirement set here:
>>   The example surely needs polishing but is stable enough to ask for discussion of this approach in our next telcon.
>>       Best regards
>>     Jaro
>> On Tuesday, September 19, 2017 00:33 CEST, Karen Coyle <> wrote:
>>> After the call ended today I realized that I missed an opportunity to
>>> create an action around Alejandra's suggestion that the UCR document
>>> might need numbering for the requirements as well as their brief
>>> headings. I will now create an action item with the description:
>>> Explore numbering of requirements within the heading areas in UCR document
>>> Because the tracker only takes one name, I'll assign this to a member of
>>> the UCR group but the implication is that it is a group task. Note that
>>> it says "explore" because the UCR group should come back to us if this
>>> turns out to be overly burdensome.
>>> Thanks, kc & Caroline
>>> -- 
>>> Karen Coyle
>>> m: 1-510-435-8234 (Signal)
>>> skype: kcoylenet/+1-510-984-3600

Jaroslav Pullmann
Fraunhofer Institute for Applied Information Technology FIT
User-Centered Ubiquitous Computing
Schloss Birlinghoven | D-53757 Sankt Augustin | Germany
Phone: +49-2241-143620 | Fax: +49-2241-142146

Received on Monday, 25 September 2017 13:11:29 UTC