|
|
 | | From: | mikron | | Subject: | Use of internal functionaliy in use case | | Date: | 11 Jan 2005 23:39:51 -0800 |
|
|
 | Can I include internal functionalily in the use case?
I am writing software requirements using use case for software model of
a router. The trivial use case is Packet Processor (actor) send packet
to the system. Should I include what (and not how) the system does
(e.g. save the MAC in the MAC table; look up ip in the ip table; update
counters; etc. )?
|
|
| | From: | mikron | | Subject: | Re: Use of internal functionaliy in use case | | Date: | 18 Jan 2005 01:41:10 -0800 |
|
|
| Thank you very much.
H. S. Lahman wrote:
> Responding to Mikron...
>
> > Can I include internal functionalily in the use case?
>
> Yes and No. Any functionality that is unique to the application and
is
> also stipulated as requirements should be in the use cases. However,
> any functionality that is the result of design decisions -- usually
as
> part of resolving nonfunctional requirements -- should not be in use
cases.
>
> [However, for complex applications that have lots of subsystems, it
may
> be desirable to write individual, specialized use case for individual
> subsystems. In that case everything outside the subsystem is an
actor,
> which may include "requirements" that are really the result of a
design
> decision elsewhere in the application. We rationalize that by saying
> that the use cases for individual subsystems are based describe a
unique
> suite of local requirements where the Black Box is at a lower level
of
> abstraction than that for customer requirements.]
>
> >
> > I am writing software requirements using use case for software
model of
> > a router. The trivial use case is Packet Processor (actor) send
packet
> > to the system. Should I include what (and not how) the system does
> > (e.g. save the MAC in the MAC table; look up ip in the ip table;
update
> > counters; etc. )?
>
> Here I would be inclined to say No because the IP stuff is all pretty
> much defined by the TCP/IP protocols and the MAC details likely to be
> defined in some external standard, neither of which are specific to
this
> application. So all the use case needs to do is reference the
relevant
> standards (e.g., "send packet to ABC via TCP/IP protocol" and
> "authenticate via MAC standard XYZ".)
>
> Bottom line: like all requirements use cases just define What must be
> done. If that is already describe in annoying detail in some
standard
> you don't need to belabor it redundantly in the use case.
>
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindermda.com
> blog (under constr): http://pathfinderpeople.blogs.com/hslahman
> (888)-OOA-PATH
|
|
| | From: | H. S. Lahman | | Subject: | Re: Use of internal functionaliy in use case | | Date: | Thu, 13 Jan 2005 21:51:17 GMT |
|
|
| Responding to Mikron...
> Can I include internal functionalily in the use case?
Yes and No. Any functionality that is unique to the application and is
also stipulated as requirements should be in the use cases. However,
any functionality that is the result of design decisions -- usually as
part of resolving nonfunctional requirements -- should not be in use cases.
[However, for complex applications that have lots of subsystems, it may
be desirable to write individual, specialized use case for individual
subsystems. In that case everything outside the subsystem is an actor,
which may include "requirements" that are really the result of a design
decision elsewhere in the application. We rationalize that by saying
that the use cases for individual subsystems are based describe a unique
suite of local requirements where the Black Box is at a lower level of
abstraction than that for customer requirements.]
>
> I am writing software requirements using use case for software model of
> a router. The trivial use case is Packet Processor (actor) send packet
> to the system. Should I include what (and not how) the system does
> (e.g. save the MAC in the MAC table; look up ip in the ip table; update
> counters; etc. )?
Here I would be inclined to say No because the IP stuff is all pretty
much defined by the TCP/IP protocols and the MAC details likely to be
defined in some external standard, neither of which are specific to this
application. So all the use case needs to do is reference the relevant
standards (e.g., "send packet to ABC via TCP/IP protocol" and
"authenticate via MAC standard XYZ".)
Bottom line: like all requirements use cases just define What must be
done. If that is already describe in annoying detail in some standard
you don't need to belabor it redundantly in the use case.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
|
|
|
