Subject: [sfc] Use Case drafts and requirements

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Apr 2014 13:54:34 -0400

Myo Zarny pointed something out to me that I had overlooked.
The mobility use case draft has requirements buried in it.
Distributing requirements across multiple drafts is a bad practice.
And tying requirements to the use case drafts is confusing.  As I 
understand it, we are adopting use cases as guidance, not as 
requirements.  They are cases we want to support.  Requirements should 
be derived from them, not included in them.

Thus, I would ask that as part of adopting this draft, or in a respin 
shortly thereafter, the material in section 3.1.2 be removed for later 
discussion in a requirements draft.

Yours,
Joel

PS: Don't ask how I missed the clear section in my earlier reading.  Sorry.

---

From: "Haeffner, Walter, Vodafone DE" <[email-masked]>
Date: Tue, 22 Apr 2014 21:05:28 +0000

Hi Joel,

Thanks for your remark. Sounds reasonable. Will discuss issue with co-authors. Original intension was to mention weak points in typical current SFC implementations. Hope you are fine with this. From there it was only a small further step  to end with requirements. 

For me it is OK  to collect all requirements derived from all use case drafts finally in a separate draft.

Regards, Walter

-----Ursprüngliche Nachricht-----
Von: sfc [mailto:[email-masked]] Im Auftrag von Joel M. Halpern
Gesendet: Dienstag, 22. April 2014 19:55
An: [email-masked]
Betreff: [sfc] Use Case drafts and requirements

Myo Zarny pointed something out to me that I had overlooked.
The mobility use case draft has requirements buried in it.
Distributing requirements across multiple drafts is a bad practice.
And tying requirements to the use case drafts is confusing.  As I understand it, we are adopting use cases as guidance, not as requirements.  They are cases we want to support.  Requirements should be derived from them, not included in them.

Thus, I would ask that as part of adopting this draft, or in a respin shortly thereafter, the material in section 3.1.2 be removed for later discussion in a requirements draft.

Yours,
Joel

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 22 Apr 2014 17:19:58 -0400

Noting ways that existing solutions have trouble with the use cass is 
probably useful in the use case document, even if atypical.

Part of my concern is that I don't want to get caught in trying to 
wordsmith requirements text (which need careful wording) when our goal 
is to get the point that the overall behavior is needed.

Yours,
Joel

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 23 Apr 2014 20:25:41 +0000

Hi Joel,

I agree, getting caught up in a complex requirement doc (and associated long drawn out process) is not something we need, want, nor are chartered for.  Rather, let’s focus on clear use cases and use them to drive requirements.

Thanks
Paul

On Apr 22, 2014, at 2:19 PM, Joel M. Halpern <[email-masked]> wrote:

> Noting ways that existing solutions have trouble with the use cass is probably useful in the use case document, even if atypical.
> 
> Part of my concern is that I don't want to get caught in trying to wordsmith requirements text (which need careful wording) when our goal is to get the point that the overall behavior is needed.
> 
> Yours,
> Joel
>

---

From: Lucy yong <[email-masked]>
Date: Wed, 23 Apr 2014 22:11:37 +0000

I support this approach!
Cheers,
Lucy 

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Paul Quinn (paulq)
Sent: Wednesday, April 23, 2014 3:26 PM
To: Joel M. Halpern
Cc: Haeffner, Walter, Vodafone DE; [email-masked]; Jeffrey Napper (jenapper)
Subject: Re: [sfc] Use Case drafts and requirements

Hi Joel,

I agree, getting caught up in a complex requirement doc (and associated long drawn out process) is not something we need, want, nor are chartered for.  Rather, let's focus on clear use cases and use them to drive requirements.

Thanks
Paul