hiho,
We had a lot of discussion at the genesis
of OpenUP as to whether or not it would explicitly be a use-case-based process.
The opinion of many of the leaders was that it wasn’t critically
important that use cases were used as the requirements technique of choice; but
to create a concrete, enactable, complete process we needed something. And,
based on the fact that this is a version of the Unified Process, use cases
represent a good choice.
Personally, I like to have some sort of
scenario-based requirements structure so that I can incrementally create
instances of end-to-end usage that add value to the stakeholders and that can
be tested with test cases. I also happen to like use cases, but that isn’t
critical.
In the example below, I would find some
set of usage scenarios that represent valuable, testable functionality. The
best case would be to have scenarios that clearly drive business value –
perhaps more clearly than Maintain X. But if we ended up with 300
lightweight use cases that essentially reference the related data requirements,
then so be it. In that case the use cases would be mostly a grouping
mechanism organized along the same lines as the data model; I probably wouldn’t
bother with a use-case spec for each.
I’m fine with whatever you call it
as long as I can understand the value the required functionality brings to the
stakeholders, as long as I can build it as a chunk of functionality, and as
long as I can test it.
------------- b
From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Ronaldo r
Sent: Tuesday, June 19, 2007 4:10
PM
To: Eclipse
Process Framework Project Developers List
Subject: Re: [epf-dev] supporting
requirements
So,
do you create use cases for all possible situations? Even for those that hasn't
much interations between user and the system?
Suppose that my system has 300 entitys that need to be manteined by the user.
In this case you will write 300 use cases like "mantain entity x",
grouping insert, delete and updating operations ?
On 6/19/07, Jim
Ruehlin <jruehlin@xxxxxxxxxx>
wrote:
Hi Ronaldo,
Use cases describe functional requirements that are usually NOT
system-wide. The requirements described in use cases are specific to a
goal the user is trying to achieve. So if you have functional
requirements that apply at all times to the entire system, you would
place them in the Supporting Requirements artifact.
In my experience, system-wide functional requirements are rare. You'll
almost always put functional requirements in use cases.
As I wrote in a previous post, business rules describe what the business
can or can't do, such as the circumstances under which a mortgage
application can be accepted.
So you might have a use case called "Request Mortgage Loan", where
the
system allows someone to submit their mortgage application and check the
status of the loan approval. In the step of the use case that describes
the functional requirement of submitting the application data, you might
reference the business rule (in the Supplementary Specification) that
describes what data must be included in the application before it can be
accepted by the system.
Hope this helps,
- Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer www.eclipse.org/epf
email: jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax: 949.369.0720
________________________________
From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx]
On Behalf Of "Ronaldo r" <ronaldorezende@xxxxxxxxx
>
Sent: Tuesday, June 19, 2007 8:14 AM
To: Eclipse Process Framework Project Developers List
Subject: Re: [epf-dev] supporting requirements
I've saw this in supporting requirements template. I haven't
understand this yet. I'm confusing about what kind of requirements
should be in a use case, the requirements that fits better in "System
wide functional requirements" or "Business rule" sections of
supporting requirements template.
On 6/19/07, Nate Oster < noster@xxxxxxxxxxxxx> wrote:
> Ronaldo,
>
> I'm not sure where in OpenUP you're referencing, but I think the
> distinction is SCOPE. "System wide Functional Requirements" are
> *global* - they apply to the entire system. The entire system must
> behave a certain way.
>
> "Business Rules" might be associated with only part of the
system. For
> example, there may be many business rules about a Register Member use
> case, but contradictory business rules for the Manage Member Profiles
> use case. There could be any number of reasons for this, such as
> different actors (perhaps one is an end user, the other a customer
> support engineer).
>
> Is there somewhere that this is too ambiguous in OpenUP? We can always
> submit a bug! :)
>
> Nate
>
> -----Original Message-----
> From: epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx
]
> On Behalf Of Ronaldo r
> Sent: Monday, June 18, 2007 3:30 PM
> To: Eclipse Process Framework Project Developers
List
> Subject: [epf-dev] supporting requirements
>
> What's the difference of "System wide Functional Requirements"
section
> and "Business Rules"? What kind of rule fit in each of these?
>
> _______________________________________________
> epf-dev mailing list
> epf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/epf-dev
>
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
