[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [epf-dev] supporting requirements

It's not unusual to have a use case in your UC model that focuses on
system or data administration. You wouldn't need to have 300 use cases
that maintain 300 entities. You could have a use case like "Maintain
Data Integrity", where any of the data can be updated, entered,
archived, etc. In this case you'd probably have a data dictionary that
describes the specific data, the range of legal values for each field,
etc. The use case would then reference the data dictionary when
describing the data that needs to be updated. For example:

 

Use Case Step

The user selects the desired data, updates the data, and submits the
changes to the database. See the data dictionary for data constraints.

 

Data Dictionary

Customer address: Required, maximum 50 characters

Customer age: Required, legal values are 1 to 120

Etc.

 

- 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 1: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

 

_______________________________________________ 
epf-dev mailing list 
epf-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/epf-dev