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

Hi, Jaro. I think that the issue is both having discrete numbers and
having the requirements be visually more prominent. (Others, correct me
if I misunderstood the intent here.) At the moment, the requirements
don't show in the table of contents (along the side, as per respec) and
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.

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.

kc



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: 
> 
>       https://rawgit.com/jpullmann/dxwg/gh-pages/ucr/index.html
> 
>  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 <kcoyle@kcoyle.net> 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
>> kcoyle@kcoyle.net http://kcoyle.net
>> m: 1-510-435-8234 (Signal)
>> skype: kcoylenet/+1-510-984-3600
>>
>  
>  
>  
> 

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Sunday, 24 September 2017 17:38:43 UTC