Use Case Conflict
Ronseal
conflict/duplication between atomic requirements and use-case. The
examples I've seen create atomic requirements for Business Rules,
Supplementary Requirements (if using FURPS, global feature set/
capabilities) and even activities/events within the use-cases
themselves. This either negates using traditional use-case i.e. can
be read like a story, or duplicates the vast majority of a use-case's
flow of events. If this is compared to RUP are Atomic Requirements
indeed Features as specified in a RUP Vision or are they indeed at
this very low level i.e. flow of event detail?
For Business Rules how do you avoid duplication with Business
Modelling elements or re-use (and provide traceability for impact
analysis)
Any opinions, it would be good to see some worked examples even if
made-up or doctored.
Suzanne Robertson
To address your question it helps to avoid generalising the concept of a use
case and instead to consider the difference between Business Use Cases
(BUC's) and Product Use Cases (PUC's).
Chapter 7 of the Volere template defines the scope of the work/business
investigation. This provides a way of thinking about the scope of the
business problem rather than limiting oneself to some body's or bodies
intentions for the scope of the product. One of the things that seems to
help people a lot is when they learn to specify work scope and product scope
in parallel. That way, as they start to understand more about the business
problem they are inspired with ideas for the product. As they start to get
more insights for the product they are led back to investigating and
questioning the business problem.
The requirements knowledge covered in Chapter 7 is Work Scope, Business
Events and Business Use Cases and can be expressed using a variety of
techniques - providing the scope of each BUC is consistent and traceable
back to the Work Scope.
Work Scope - a Work Context Diagram
Business Events - a Business Event List
BUCs - BUC Scenarios, Activity Diagrams, Mind Maps.....whatever works for
you. Need lots of different ways of expressing BUCs, the important thing
is to be able to trace BUC knowledge to the Business Event List and from
there to the Work Context.
Chapter 8 of the template covers Product Scope and PUCs
Product Scope - I tend to use the same sort of diagram as for the
work context, just squash the bubble to make it look different and
to accentuate that it is different from the work scope.
PUCs - Scenarios, Sequence Diagrams, Activity Diagrams, Use Case
diagram...whatever works in your own environment. Once again the key is
traceability.
Chapter 9 of the template covers Atomic Functional and Data Requirements and
Chapters 10-17 cover the Atomic Non-Functional Requirements.
In most of the projects that I work on we package the atomic
requirements with the appropriate PUC scenario/s to make a
package of all the requirements for a PUC.
The atomic requirements have a rationale and a fit criterion and are the
basis for making design decisions and designing tests. Now let's deal with
the question of how atomic requirements relate to the PUC? The short answer
is it depends on the granularity of your PUC - you can assess this by
looking at the scenario. If each step in your scenario contains a
description, rationale and fit criterion then you can say that your PUC is
made up of a group of atomic requirements. In this case you have usually
decomposed into PUC's that are small, reusable groups of requirements that
form units of implementation - System Use Cases (SUC's).
Now back to the question of business rules. The business rules relevant to
your project (the ones that will be some of your requirements) are contained
within the Work Scope and are captured by the BUC's. It is true that if you
have done any business process modelling or have an organised enterprise
architecture then some of those business rules might already be defined in
some form. One of the activities when setting the Work Scope for your
project and partitioning it into business events is to look for reusable
knowledge (business rules) that have already been defined. An effective
technique for doing this is to map each BUC to the available business
knowledge. It is here that we address the question of avoiding duplication
with the Business Modelling elements and taking advantage of reuse. Some
organisations have a business analyst who acts as the business rules reuse
co-ordinator. Of course this works both ways, when a project discovers new
business rules as a result of investigating requirements then the
co-ordinator adds that new knowledge to the appropriate business models.
Chapter 1 of the Volere template contains the Goals for the project. These
are the highest level requirements and are used to drive the project. This
is equivalent to the RUP Vision.
I am in the process of doing a small but complete worked example containing
Work Scope, Business Events, BUC's, PUC's, Atomic functional and
non-functional requirements. When this is complete I will make it available
on the Volere website
http://www.volere.co.uk
Thank you for your interesting question.
Kind Regards
Suzanne Robertson
Ronseal
deal of sense, but I still have one more clarification. That is still
around Atomic Requirements, am I right is saying that if you have fit
criteria etc. contained in each Activity within a Flow of Events and
the same for Business Rules then this cover Atomic Requirements. The
example I have seen uses Requisite Pro with Requirement Type of ATOM
and PUC and traceablity between the 2 at the expense of a detailed PUC
i.e. full Flow of Events for each scenario. With the current Tool (pre
version 7) there is no concept of sequencing or traceablity to
anything below a Rose Use-Case so a view of the flow cannot be gained
hence making testing of your Use-Case model virtually impossible. Even
with Version 7 of ReqPro there is little benefit tracing below the
level of a Use-Case, in fact past experiance shows that you get in a
traceability can of worms.
A good example would I'm sure clarify this, but a comment on my
assumption would be most useful. I suppose the bottom line is if you
are using RUPs Vision and SRS/SS correctly with well strcutured and
detailed Use-cases what are the benefits of Volere?
Regards.
Ronseal.
> Thank you for your interesting question.
>
> Kind Regards
> Suzanne Robertson
>
>
>
> > Having seen Volere used (maybe incorrectly) there appears to be a
> > conflict/duplication between atomic requirements and use-case. The
> > examples I've seen create atomic requirements for Business Rules,
> > Supplementary Requirements (if using FURPS, global feature set/
> > capabilities) and even activities/events within the use-cases
> > themselves. This either negates using traditional use-case i.e. can
> > be read like a story, or duplicates the vast majority of a use-case's
> > flow of events. If this is compared to RUP are Atomic Requirements
> > indeed Features as specified in a RUP Vision or are they indeed at
> > this very low level i.e. flow of event detail?
> > For Business Rules how do you avoid duplication with Business
> > Modelling elements or re-use (and provide traceability for impact
> > analysis)
>
> > Any opinions, it would be good to see some worked examples even if
>
> - Show quoted text -
Suzanne Robertson
Volere is a set of techniques that is focused on the content rather than the
form of requirements. This is best summarised by the Volere requirements
knowledge model published in our book "Requirements-Led Project Management".
In essence there are requirements at a number of levels of detail that have
traceability between them. It is true that requirements tools do not satisfy
all of our requirements traceability needs. In these situations we are users
whose needs are not completely met by the software product that we are
using. If the product we are using does not support what we need to do then
we need to add other procedures in order to be able to test solutions
against requirements and in order to do impact analysis of proposed changes.
The word Event is an elastic word and it is dangerous to use it without
qualifying it. The way it is used in Volere is as a Business Event. A
business event is something that happens that causes a stimulus that in turn
triggers a business response. This response is known as a business use case
or a BUC. The business rules/business requirements are contained in the
BUC. For each BUC there can be one or more product use cases (PUCs)
depending on how much of the BUC is allocated to the product.
The fit criterion is one of the attributes of an atomic requirement, it is
what makes the requirement measurable and testable. Each product use case
(PUC) relates to a group of atomic requirements. The PUC is usually
represented as a scenario, sequence diagram, activity diagram or some other
kind of model that suits the way that a particular team prefers to work.
In our experience testers use the PUC scenario plus the associated atomic
requirements as the basis for designing and running tests. Business analysts
also use the PUC scenario plus the associated atomic requirements.
For more insights into Business Events, BUC's, PUC's and Atomic Requirements
go to:
http://www.volere.co.uk/
Click on articles and have a look at the one entitled
Volere Requirements: How to Get Started
I hope that this helps.
Kind Regards
Suzanne
===================================================================
Have a look at our web page devoted to VOLERE Requirements news and
resources
Suzanne Robertson The Atlantic Systems Guild Ltd.
11 St. Mary's Terrace London
W2 1SU UK
mail: suz...@systemsguild.net
phone: +44(0)20 7262 3395
http://www.systemsguild.com
http://www.volere.co.uk
===================================================================