Use Case goals

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Use Case goals

joël Winteregg-3
Dear all,

At the beginning of Friday meeting (telcon), it was quite hard (at least
for me) to understand the exact objectives of the Use Case Definition.
Then, from the answer of the question I asked during the telcon (about
Use Case goals) and from available Use Case (on the Wiki, at:
http://12.193.84.139:8080/web/guest/home ) I better understand Use Case
objectives. As understood, Use Case will be mainly used:
* To have concrete example of log usage scenario (to be able to
benchmark existing log format, "test" current work against concrete
scenario, etc.)
* To define CEE objectives from use case prioritization (related to the
following post http://www.nabble.com/Re%3A-CEE-charter---Definitions-p18819264.html )

Am I right ?

Is there a document/wiki where each operational objectives (like Use
Case goals) are given ? If not, don't you think it will be useful to
have such information somewhere ? Appendix B of CEE White Paper provide
this kind of information for higher level tasks (tactical objectives)
but I was not able to find any information about lower level tasks
(operational objectives).

Thanks in advance.


Regards,


Joël
Reply | Threaded
Open this post in threaded view
|

Re: Use Case goals

Tina Bird
Hi Joel --

> At the beginning of Friday meeting (telcon), it was quite
> hard (at least
> for me) to understand the exact objectives of the Use Case Definition.
> Then, from the answer of the question I asked during the telcon (about
> Use Case goals) and from available Use Case (on the Wiki, at:
> http://12.193.84.139:8080/web/guest/home ) I better
> understand Use Case
> objectives. As understood, Use Case will be mainly used:
> * To have concrete example of log usage scenario (to be able to
> benchmark existing log format, "test" current work against concrete
> scenario, etc.)
> * To define CEE objectives from use case prioritization
> (related to the
> following post
> http://www.nabble.com/Re%3A-CEE-charter---Definitions-p18819264.html )
>
> Am I right ?

I have managed to miss *all* the discussions directly related to use cases,
so I don't know what anyone else things, but your idea sounds reasonable to
me.

> Is there a document/wiki where each operational objectives (like Use
> Case goals) are given ? If not, don't you think it will be useful to
> have such information somewhere ? Appendix B of CEE White
> Paper provide
> this kind of information for higher level tasks (tactical objectives)
> but I was not able to find any information about lower level tasks
> (operational objectives).

I agree. One of the things I've been meaning to do is to take the use cases,
whatever they are, in the existing documentation, and try to sort them into
three broad categories: those relevant for "business" purposes (ie. things
like compliance to regulations, audits against local HR policies, workflow
monitoring for business applications, reporting on employee access to
sensitive data for managers, etc); those relevant for operations (all those
things we system administrators worry about); and those relevant for
programmers/developers. I am taking it on faith that we already have enough
written down that such a task will be possible ;-)

Then I was planning on taking the latest revision of our definitions, and
seeing how those fit in with the use cases (or the "generalized" use cases)
as a way of checking to be sure we've got everything covered that we think
we need covered, and to expose anything we've missed.

For the moment, I'm going to do this work off-line, with progress reports
(or copies of whatever I've managed to do) posted to this list. I've also
got an outstanding deliverable to several people (some CEE, some not) for a
summary of laws and standards that incorporate requirements for event
logging and data retention. I had intended to do that over the long U.S.
holiday weekend, but I somehow managed to find myself having a weekend
instead ;-)

Please, everyone, let me know if this seems like a helpful way to proceed,
or if there are other sources of information I should try to incorporate. I
have a couple of appointments this morning, but I'll be working on this
later on today.

thanks -- tbird
Reply | Threaded
Open this post in threaded view
|

Re: Use Case goals

David Corlette
Hi guys,
So the process I would recommend here would be to use the Use Cases as a way to generate requirements.  Having a preliminary breakdown as Tina describes would be a great start.

To make this concrete let's just take a sample use case:

"The internal auditor at a large enterprise needs to generate some simple reports so that she can prove compliance with several regulations...."
(there's more to this Use Case on the wiki, such as specific requirements that can be pulled wholesale from PCI).

From this we can easily start to generate requirements:

R1) The data must be centralized s.t. the auditor does not need to visit each system to generate the reports
R2) To "prove" anything, the data must be authenticated and non-repudiable and secure to some degree TBD (perhaps each enterprise can decide if they need to sign each event, SSLize the transport, etc as necessary to achieve their desired level of protection).
R3) The events must be simply categorized and easily comprehensible for even non-technical users so that, for example, if the regulation states (from PCI) "report on the use of identification and authentication mechanisms" selecting the correct events for the report is straightforward.

and so on...

Next you'd go through all the other critical Use Cases, avoiding requirement duplication where necessary and compromising on requirements where there might be conflicts. So for example, several folks have pointed out that having simple "categories" for events sometimes makes it hard to express a "new" or "different" type of event that some system expresses. A compromise might involve extensible taxonomies, somewhat like SNMP, but obviously there are risks there as well.

Once the requirements are fully realized, then and only then can we proceed to implementation. Or that is to say, once some minimal core set of requirements is fully realized, since there's no reason we can't be agile and work our feature details later, as long as folks agree on the fundamentals.

So this is the approach I would take, which you can take or leave as you see fit.  Obviously having a collaborative space where each Use Case could be discussed w.r.t. generated requirements would be of great benefit.

>>> On Tue, Sep 2, 2008 at 11:48 AM, in message
<4C2FB005CDE44796AF9F6AEB0CE662D9@lindesfarne>, Tina Bird
<[hidden email]> wrote:

> Hi Joel --
>
>> At the beginning of Friday meeting (telcon), it was quite
>> hard (at least
>> for me) to understand the exact objectives of the Use Case Definition.
>> Then, from the answer of the question I asked during the telcon (about
>> Use Case goals) and from available Use Case (on the Wiki, at:
>> http://12.193.84.139:8080/web/guest/home ) I better
>> understand Use Case
>> objectives. As understood, Use Case will be mainly used:
>> * To have concrete example of log usage scenario (to be able to
>> benchmark existing log format, "test" current work against concrete
>> scenario, etc.)
>> * To define CEE objectives from use case prioritization
>> (related to the
>> following post
>> http://www.nabble.com/Re%3A-CEE-charter---Definitions-p18819264.html )
>>
>> Am I right ?
>
> I have managed to miss *all* the discussions directly related to use cases,
> so I don't know what anyone else things, but your idea sounds reasonable to
> me.
>
>> Is there a document/wiki where each operational objectives (like Use
>> Case goals) are given ? If not, don't you think it will be useful to
>> have such information somewhere ? Appendix B of CEE White
>> Paper provide
>> this kind of information for higher level tasks (tactical objectives)
>> but I was not able to find any information about lower level tasks
>> (operational objectives).
>
> I agree. One of the things I've been meaning to do is to take the use cases,
> whatever they are, in the existing documentation, and try to sort them into
> three broad categories: those relevant for "business" purposes (ie. things
> like compliance to regulations, audits against local HR policies, workflow
> monitoring for business applications, reporting on employee access to
> sensitive data for managers, etc); those relevant for operations (all those
> things we system administrators worry about); and those relevant for
> programmers/developers. I am taking it on faith that we already have enough
> written down that such a task will be possible ;-)
>
> Then I was planning on taking the latest revision of our definitions, and
> seeing how those fit in with the use cases (or the "generalized" use cases)
> as a way of checking to be sure we've got everything covered that we think
> we need covered, and to expose anything we've missed.
>
> For the moment, I'm going to do this work off-line, with progress reports
> (or copies of whatever I've managed to do) posted to this list. I've also
> got an outstanding deliverable to several people (some CEE, some not) for a
> summary of laws and standards that incorporate requirements for event
> logging and data retention. I had intended to do that over the long U.S.
> holiday weekend, but I somehow managed to find myself having a weekend
> instead ;-)
>
> Please, everyone, let me know if this seems like a helpful way to proceed,
> or if there are other sources of information I should try to incorporate. I
> have a couple of appointments this morning, but I'll be working on this
> later on today.
>
> thanks -- tbird
Reply | Threaded
Open this post in threaded view
|

Re: Use Case goals

joël Winteregg-3
Hi all,

Thank you Tina and David for your emails.

Your inputs confirm the way Use Cases will be used:
* A way to generate requirements
* A way to check current work (as Tina is going to use it to check
Definitions coverage)

I also believe that Use Case should be (after requirements generation)
prioritized in order to be able to define a standard which better fit
high priority Use Cases. Indeed, some Use Case will output different
needs and without a proper prioritization it will be hard to define
which requirement is more important. For example: A Use Case could
outline log expressiveness, while another one could outline log
generation speed. If no prioritization is available, it will be hard to
define which log format (Common Log Syntax) is the best:
- XML (expressiveness = good, speed = bad)
- Binary (expressiveness = bad, speed = good)


Regards,


Joël


On Tue, 2008-09-02 at 10:44 -0600, David Corlette wrote:

> Hi guys,
> So the process I would recommend here would be to use the Use Cases as a way to generate requirements.  Having a preliminary breakdown as Tina describes would be a great start.
>
> To make this concrete let's just take a sample use case:
>
> "The internal auditor at a large enterprise needs to generate some simple reports so that she can prove compliance with several regulations...."
> (there's more to this Use Case on the wiki, such as specific requirements that can be pulled wholesale from PCI).
>
> >From this we can easily start to generate requirements:
>
> R1) The data must be centralized s.t. the auditor does not need to visit each system to generate the reports
> R2) To "prove" anything, the data must be authenticated and non-repudiable and secure to some degree TBD (perhaps each enterprise can decide if they need to sign each event, SSLize the transport, etc as necessary to achieve their desired level of protection).
> R3) The events must be simply categorized and easily comprehensible for even non-technical users so that, for example, if the regulation states (from PCI) "report on the use of identification and authentication mechanisms" selecting the correct events for the report is straightforward.
>
> and so on...
>
> Next you'd go through all the other critical Use Cases, avoiding requirement duplication where necessary and compromising on requirements where there might be conflicts. So for example, several folks have pointed out that having simple "categories" for events sometimes makes it hard to express a "new" or "different" type of event that some system expresses. A compromise might involve extensible taxonomies, somewhat like SNMP, but obviously there are risks there as well.
>
> Once the requirements are fully realized, then and only then can we proceed to implementation. Or that is to say, once some minimal core set of requirements is fully realized, since there's no reason we can't be agile and work our feature details later, as long as folks agree on the fundamentals.
>
> So this is the approach I would take, which you can take or leave as you see fit.  Obviously having a collaborative space where each Use Case could be discussed w.r.t. generated requirements would be of great benefit.
>
> >>> On Tue, Sep 2, 2008 at 11:48 AM, in message
> <4C2FB005CDE44796AF9F6AEB0CE662D9@lindesfarne>, Tina Bird
> <[hidden email]> wrote:
> > Hi Joel --
> >
> >> At the beginning of Friday meeting (telcon), it was quite
> >> hard (at least
> >> for me) to understand the exact objectives of the Use Case Definition.
> >> Then, from the answer of the question I asked during the telcon (about
> >> Use Case goals) and from available Use Case (on the Wiki, at:
> >> http://12.193.84.139:8080/web/guest/home ) I better
> >> understand Use Case
> >> objectives. As understood, Use Case will be mainly used:
> >> * To have concrete example of log usage scenario (to be able to
> >> benchmark existing log format, "test" current work against concrete
> >> scenario, etc.)
> >> * To define CEE objectives from use case prioritization
> >> (related to the
> >> following post
> >> http://www.nabble.com/Re%3A-CEE-charter---Definitions-p18819264.html )
> >>
> >> Am I right ?
> >
> > I have managed to miss *all* the discussions directly related to use cases,
> > so I don't know what anyone else things, but your idea sounds reasonable to
> > me.
> >
> >> Is there a document/wiki where each operational objectives (like Use
> >> Case goals) are given ? If not, don't you think it will be useful to
> >> have such information somewhere ? Appendix B of CEE White
> >> Paper provide
> >> this kind of information for higher level tasks (tactical objectives)
> >> but I was not able to find any information about lower level tasks
> >> (operational objectives).
> >
> > I agree. One of the things I've been meaning to do is to take the use cases,
> > whatever they are, in the existing documentation, and try to sort them into
> > three broad categories: those relevant for "business" purposes (ie. things
> > like compliance to regulations, audits against local HR policies, workflow
> > monitoring for business applications, reporting on employee access to
> > sensitive data for managers, etc); those relevant for operations (all those
> > things we system administrators worry about); and those relevant for
> > programmers/developers. I am taking it on faith that we already have enough
> > written down that such a task will be possible ;-)
> >
> > Then I was planning on taking the latest revision of our definitions, and
> > seeing how those fit in with the use cases (or the "generalized" use cases)
> > as a way of checking to be sure we've got everything covered that we think
> > we need covered, and to expose anything we've missed.
> >
> > For the moment, I'm going to do this work off-line, with progress reports
> > (or copies of whatever I've managed to do) posted to this list. I've also
> > got an outstanding deliverable to several people (some CEE, some not) for a
> > summary of laws and standards that incorporate requirements for event
> > logging and data retention. I had intended to do that over the long U.S.
> > holiday weekend, but I somehow managed to find myself having a weekend
> > instead ;-)
> >
> > Please, everyone, let me know if this seems like a helpful way to proceed,
> > or if there are other sources of information I should try to incorporate. I
> > have a couple of appointments this morning, but I'll be working on this
> > later on today.
> >
> > thanks -- tbird