Message:
|
|
|
 |
Author:
Shorten, Michael (neurowiz) |
Date
Posted: Aug 17, 2001 - 01:09 PM |
|
Attachment:
None |
|
|
Message
1 of 26 |
|
Hello! RM is one of my interests these days with
the job I have.
I have a couple of questions regarding use cases,
RequisitePro, and iterations that have come up during several projects I have
been process coach and architect on. I'm hoping for
some guidance, as I haven't found concrete answers
in several of the Methodology and Use Case books I have.
1. Is it best to use Use Cases to track across
iterations or features?
In most cases, a Use Case seems to complete in
what can be thought as a continguous amount of time
- in that when the initiating actor initiates the
Use Case, the time to completion can be measured in
small amounts of time (dependent on system
processing).
But what about cases where there is
asynchronicity in the process, or some gap of time
that could reflect a human actor's actions? Can the
execution of a Use Case reflect a large gap of time?
Example: The Use Case is Create An Account. In
the Basic Flow, a user enters their account
information and submits it for approval. The
Administrator must approve the account for it to be
active (the creation/activation of an account is
considered the result of significant value for the
initiating actor). But in this case, approval might
take a couple of hours or days and is dependent on
the Administrator performing their bit in the Use
Case.
2. Should I use a new document for each iteration
or try to keep all the use cases in one document?
When a user has to enter data elements as part of
a Use Case, there are usually business rules
regarding validation of that data. It doesn't make
sense or improve the readability of the Use Case to
put those rules in the main flow, but it's clearly
business rules that could be use case specific. Do
you end up creating a separate section or putting
those rules in the Special Requirements section (of
the RUP Use Case Template)?
Thanks in advance!
Regards,
Michael Shorten, Technical Manager
Dunn Solutions Group
Reply to this message
|
 |
 |
Message:
re: PART 1 |
|
|
 |
Author:
Dijkgraaf, W.N. (wn.dijkgraaf) |
Date
Posted: Aug 20, 2001 - 01:27 PM |
In
Reply To: Shorten, Michael (neurowiz) |
Attachment:
None |
|
|
Message
2 of 26 |
|
Dear Michael,
Thanks for you’re participation in this forum
and for starting the first thread.
The first subject you come up with is:
1) Is a Use Case contiguous in terms of execution
time?
You explain the origin of this question, which is
based on synchronicity versus asynchronicity
(especially with a batch-wise character). A sub
question you come up with is ‘Can the execution of
a Use Case reflect a large gap of time?’.
In order to give you my opinion I would like to
go back to the definition of a use case as
formulated by Alistair Cockburn in his book
‘Writing effective use cases’:
”A use case captures a contract between the
stakeholder of a system about its behaviour. The use
case describes the system’s behaviour under
various conditions as the system responds to a
request from one of the stakeholders, called the
primary actor. The primary actor initiates an
interaction with the system to accomplish some goal.
The system responds, protecting the interests of all
the stakeholders. Different sequences of behaviour,
or scenarios, can unfold, depending on the
particular requests made and the conditions
surrounding the requests. The use case gathers those
different scenarios together.
Use cases are fundamentally a text form, although
they can be written using flow charts, sequence
charts, Petri nets or programming languages. Under
normal circumstances, they serve as a means of
communication from one person to another, often
among people with no special training. Simple text
is, therefore, usually the best choice. …
… A well-written use case is easy to read. It
consists of sentences written in only one
grammatical form – a simple action step – in
which an actor achieves a result or passes
information to another actor. Learning to read a use
case should not take more than a few minutes. …”
Within this context, in my opinion the aspect of
‘a use case being contiguous in terms of execution
time’ is not a use case ‘problem’ but a
problem of ‘how to describe the process in an easy
to communicate fashion’. What about this?:
Functional Requirement:
- a User enters account information and submits it.
- the system sends the account information to the
administrator for approval.
- The Administrator reads the account information
and approves the account for it to be active.
- ….
Non-functional Requirement:
Time behaviour (Extended ISO):
Definition: Attributes of software that bear on
response and processing times and on throughput
rates in performing its function.
Description: Time between submission and approval
might be a couple of hours or days (is dependent on
the Administrator performing the approval)
With kind regards,
W.N. Dijkgraaf (Wim)
Business & Software Engineering Consultant
InDepth-ICT
The Netherlands
http://www.indepth-ict.com
Reply to this message
|
 |
 |
Message:
re:
PART 2 |
|
|
 |
Author:
Dijkgraaf, W.N. (wn.dijkgraaf) |
Date
Posted: Aug 20, 2001 - 01:27 PM |
In
Reply To: Shorten, Michael (neurowiz) |
Attachment:
None |
|
|
Message
3 of 26 |
|
2. How do you reflect system validation rules in
a Use Case?
In my opinion, the business rule is a separate
requirement type. I would trace from within the use
case description to the particular business rule
requirement. The business rule requirement defines
the details of the business rule. In other words,
use traceability from use case to the business rule.
Do you end up creating a separate section or
putting those rules in the Special Requirements
section (of the RUP Use Case Template)?
I would report the business rules in a separate
document. You could use the business rules template
as defined within RUP. You could also refer to a
centralized repository containing business rules.
With kind regards,
W.N. Dijkgraaf (Wim)
Business & Software Engineering Consultant
InDepth-ICT
The Netherlands
http://www.indepth-ict.com
Reply to this message
|
 |
 |
Message:
re: |
|
|
 |
Author:
August, Susan (saugust) |
Date
Posted: Aug 20, 2001 - 02:20 PM |
In
Reply To: Shorten, Michael (neurowiz) |
Attachment:
None |
|
|
Message
4 of 26 |
|
Michael,
To answer you first question, yes, execution of a
use case can span a large gap of time as long as the
use case continues to provide "significant
value for the initiating actor" (as you pointed
out).
However, looking more closely at the Create
Account use case that requires a human actor's
intervention, I would actually suggest taking a
different approach. Personally, I would split the
behavior into two use cases, Create Account and
Approve Account. Create Account would call the
Approve Account use case in the Basic Flow of Events
via an includes relationship. When authoring the
Approve Account use case I would indicate that human
intervention is required, and I would include a
post-condition to the effect of "The account
has been reviewed by the Administrator and been
approved or rejected within 24 hours" as a way
of specifying known business processes.
I would suggest doing this for several reasons.
On one hand, it becomes immediately clear to the
reader that Create Account is dependant on Approve
Account for its execution, and consequently that the
time horizon for the use case may be quite long.
Additionally, separating out Approve Account
highlights the fact that this is a human-intensive
business process that may be a target for future
automation or development work. If that work comes
to pass, the use case structure doesn't need to
change -- all that needs to change is the Approve
Account use case details.
As for your second question, system validation
rules can be reflected in one of several places:
· in the "Business Rules" field of your
use case template
· or, in a "supporting specifications" or
"special requirements" section (I tend to
include these in the appendix of whatever document
holds the corresponding use cases so that everything
is in one place)
· or, in an "information architecture
specification" (assuming you are fortunate
enough to work with a dedicated team of information
architects and user experience designers, this would
be one of their key deliverables)
In the end, I don't believe there's one right
way. It really depends on your use case audience –
Engineering teams tend to want it all in one
document so that they don't have to hunt for more
information, whereas a Marketing or Customer
representative would want one stream-lined document
that references the supplemental specifications.
Choose whatever is best for your environment.
Hope that helps!
Susan August
Requirements Analyst
Rational Software Corporation
Reply to this message
|
 |
 |
Message:
re: |
|
|
 |
Author:
Shorten, Michael (neurowiz) |
Date
Posted: Aug 29, 2001 - 11:03 AM |
In
Reply To: August, Susan (saugust) |
Attachment:
None |
|
|
Message
5 of 26 |
|
You wrote:
However, looking more closely at the Create Account
use case that requires a human actor's intervention,
I would actually suggest taking a different
approach. Personally, I would split the behavior
into two use cases, Create Account and Approve
Account. Create Account would call the Approve
Account use case in the Basic Flow of Events via an
includes relationship. When authoring the Approve
Account use case I would indicate that human
intervention is required, and I would include a
post-condition to the effect of "The account
has been reviewed by the Administrator and been
approved or rejected within 24 hours" as a way
of specifying known business processes.
-----------
That's been my approach up to a certain point - I
get hung up on thinking about how I'm trying to
consistently model a system and show significant
results of values (Side note: I can see how
religious wars start over this stuff... Login
anyone? *G*) - it seems that in this example,
creating an account may result in an account in
limbo, but the true result of value isn't acheived
until the second use case is run - and I don't see
modeling the second as Extends use case to be
accurate either.
I have opted to do what seems to make sense for
each situation - thanks for validating that there's
no 'secret' that I'm not seeing. :)
Regards,
Michael
Reply to this message
|
 |
 |
Message:
re: |
|
|
 |
Author:
mccarl, m (mccarl) |
Date
Posted: Sep 04, 2001 - 03:53 PM |
In
Reply To: Shorten, Michael (neurowiz) |
Attachment:
None |
|
|
Message
6 of 26 |
|
So far, you've gotten some excellent responses,
but I wonder why no one suggested using the glossary
for data validation? Why go through the hassle of
building and maintaining tracability from a use-case
requirement to a business rule if you don't need to?
Reply to this message
|
 |
Message:
re: |
|
|
 |
Author:
Dijkgraaf, W.N. (wn.dijkgraaf) |
Date
Posted: Sep 06, 2001 - 10:24 AM |
In
Reply To: mccarl, m (mccarl) |
Attachment:
None |
|
|
Message
7 of 26 |
|
I would like to reply to your posting but I'am
not sure wether my interpretation is in line with
your point. Could you be more precise?
With kind regards,
W.N. Dijkgraaf (Wim)
Reply to this message
|
 |
Message:
re: |
|
|
 |
Author:
mccarl, m (mccarl) |
Date
Posted: Sep 07, 2001 - 10:13 AM |
In
Reply To: Dijkgraaf, W.N. (wn.dijkgraaf) |
Attachment:
None |
|
|
Message
8 of 26 |
|
In my previous reply, I am just suggesting that
the glossary is often a simpler way of documenting
validation rules instead of creating more complex
trace links between your use cases and business
rules. I am not suggesting that this method will
always meet your needs, however.
For example, suppose you were developing a
web-site for a car dealer. For any car a user may
want to purchase, they can select the color they
prefer. "Color", then is a data element
you will want to validate. Because different models
of cars are available in different colors, you may
want to create some rules that describe which color
can be selected for which models. You could then
create trace links from use-cases to these rules.
Alternatively, you could create a set of
definitions for the glossary that also describe
which colors could be selected for various models.
This set of definitions might contain terms like
"Mustang Color", "Camaro Color",
and "Porche Color". The definitions would
list the allowable colors for each.
Two advantages of this method are that the
validation rules can be defined early in the
requirements gathering process (the glossary should
be one of the first documents created during problem
analysis) and trace links don't have to be
maintained. Disadvantages may be the number of
definitions that have to be created to describe all
the different validations and the impact of changing
a list of colors on the software may be more
difficult to determine without tracability links.
I hope this description makes my previous point a
bit clearer. The final solution always depends on
the specific needs of the architect.
mccarl
Reply to this message
|
|