Subject: [sacm] use cases versus requirements

From: "ietfdbh" <[email-masked]>
Date: Mon, 15 Jul 2013 18:33:48 -0400

Hi,

I looked up the BOF summaries from November and March.
The summary from November says " The consensus was to start from
requirements and then develop an architecture to explain how the use cases
can be met.  The group has a fairly good understanding of the problem space,
but needs to document this and present it more clearly with the
requirements, then the architecture.  These steps need to happen to progress
the work."  Are we paying enough attention to the requirements stage? We
don't have a requirements doc, and that might be helpful.

The summary is unclear about which comes first - use cases or requirements.

The -04- version of use cases had very high-level uses cases, and then
defined concepts and requirements from the three abstract use cases, in a
top-down approach that led to organizing the document by (theoretical)
requirements and then finding use cases as supporting examples of the
requirements. As I mentioned in my previous email, I think we should be
working in the IETF bottom-up approach, looking at multiple real-world
implementation/deployment use cases and deriving requirements from the
aggregation of use cases. 

The -05- version of use cases shows the lack of clarity about how this
should be approached (and the lack of time as the deadline approached).

Comments welcome.

David Harrington
[email-masked]
+1-603-828-1401

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jul 2013 14:04:40 +0000

Hi,

Thanks for the effort invested until now into trying to sort out use cases and requirements. 

The document has already some good parts which I believe are very useful - for example the terminology section. 

Is my understanding correct that from 04 to 05 we started to transition from the initial top-down ('theoretical') approach used in the initial versions of the document to a bottom-up approach, collecting real-life use cases, describing, sorting, consolidating them, and deriving the requirements from here? If so should we expect to see the couple of use cases proposed during the last week by Adam on the list by Adam be added to the use cases (together with other that will come)? If I am correct the efforts should be now channeled towards adding use cases to section 3 making sure that all important use cases are covered while keeping the list at a low and manageable size, and in parallel fill in with content section 4 that covers requirements. 

What is the opinion of the WG participants - is the structure of section 4 right or aproximatively right? 

I would like to see the requirements in the requirement sections numbered!

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ietfdbh
> Sent: Tuesday, July 16, 2013 1:34 AM
> To: [email-masked]
> Subject: [sacm] use cases versus requirements
> 
> Hi,
> 
> requirements and then develop an architecture to explain how the use
> cases can be met.  The group has a fairly good understanding of the
> problem space, but needs to document this and present it more clearly
> with the requirements, then the architecture.  These steps need to
> happen to progress the work."  Are we paying enough attention to the
> requirements stage? We don't have a requirements doc, and that might be
> helpful.
> 
> defined concepts and requirements from the three abstract use cases, in
> a top-down approach that led to organizing the document by (theoretical)
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm

---

From: Adam Montville <[email-masked]>
Date: Thu, 25 Jul 2013 14:30:56 +0000

> Romascanu, Dan (Dan)
> Sent: Thursday, July 25, 2013 7:05 AM
> To: ietfdbh; [email-masked]
> Subject: Re: [sacm] use cases versus requirements
> 
> Hi,
> 

+1

> Is my understanding correct that from 04 to 05 we started to transition from
> the initial top-down ('theoretical') approach used in the initial versions of the
> document to a bottom-up approach, collecting real-life use cases, describing,
> sorting, consolidating them, and deriving the requirements from here? If so
> should we expect to see the couple of use cases proposed during the last
> week by Adam on the list by Adam be added to the use cases (together with
> other that will come)? If I am correct the efforts should be now channeled
> towards adding use cases to section 3 making sure that all important use
> cases are covered while keeping the list at a low and manageable size, and in
> parallel fill in with content section 4 that covers requirements.

+1 

The use cases I presented need not be included if we believe we have a suitable use case sampling already.  If they are included, then they can be "trimmed" to be less specific, if warranted.  

I also believe we should understand that many of the use cases can be satisfied, in part, with existing specifications - not all of them, but many.  IMO, the value of the use cases at this point is to ensure that what we're building meets the requirements from the driving needs of the enterprise.

> What is the opinion of the WG participants - is the structure of section 4 right

I was reviewing the document yesterday evening and I like the structure myself - just an opinion of one, though.

> I would like to see the requirements in the requirement sections numbered!

+1

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of ietfdbh
> > requirements stage? We don't have a requirements doc, and that might
> > be helpful.
> >
> > defined concepts and requirements from the three abstract use cases,
> > in a top-down approach that led to organizing the document by
> > (theoretical) requirements and then finding use cases as supporting
> > examples of the requirements. As I mentioned in my previous email, I
> > think we should be working in the IETF bottom-up approach, looking at
> > multiple real-world implementation/deployment use cases and deriving
> > requirements from the aggregation of use cases.
> >
> ...

This message and attachments may contain confidential information.  If it appears that this message was sent to you by mistake, any retention, dissemination, distribution or copying of this message and attachments is strictly prohibited.  Please notify the sender immediately and permanently delete the message and any attachments.

---

From: David Harrington <[email-masked]>
Date: Thu, 25 Jul 2013 18:23:12 -0400

Hi Dan,

I published -05- as a partial update.
I gathered all the use cases I think I knew about at the time.
IIRC I put Adam's in, rewritten to the informal format, but might have not
done so (I'm not looking at the doc right now).
I did find Adam's use case to be quite complex, so I may not have put it
in yet.

There have been a number of use cases discussed since -05-.
I expect to capture them in -06-.
No guarantees of when that will get published.

I started reorg'ing the doc, but haven't finished.
It unclear whether the WG wants each UC to have a
description+functions+requirements (that would lead to a LOT of duplicate
text, which I think would obscure the information badly).
An alternative would be to list all the use cases in 1 section, then
summarize the functions in a section, then derive the requirements in a
third section.
Another alternative would be to organize by general use case (asset,
config, change, vulnerability), and within each of those sections, have
subsections for use cases, functions, and requirements, so there would
liekly be some duplication between the asset mgmt and the config mgmt, but
we'd eliminate a ot of the duplication between asset uc1 and asset uc2,
and so on.

--
David Harrington
[email-masked]
+1-603-828-1401

On 7/25/13 10:04 AM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:

>Is my understanding correct that from 04 to 05 we started to transition
>from the initial top-down ('theoretical') approach used in the initial
>versions of the document to a bottom-up approach, collecting real-life
>use cases, describing, sorting, consolidating them, and deriving the
>requirements from here? If so should we expect to see the couple of use
>cases proposed during the last week by Adam on the list by Adam be added
>to the use cases (together with other that will come)? If I am correct
>the efforts should be now channeled towards adding use cases to section 3
>making sure that all important use cases are covered while keeping the
>list at a low and manageable size, and in parallel fill in with content
>section 4 that covers requirements.
>