Rational Developer Network
Rational Developer Network Rational.com
  My Profile  |  Site Map  |  Help  |  Support  |  Log Out   
Current Location - Development Resources  >  Rational Tools  >  RequisitePro Welcome - Lou LeBlanc
 
SEARCH SITE:
 
 Advanced
 
Forum : Requirements Management Concepts *public forum
Topic: Controlling iterations with RequisitePro
 Previous Topic   Next Topic   Delete this Topic   Printable Version   Back to Forum 
page 1 of 9
previous 10
button_prepage
1  2  3  4  5  6  7  8  9
button_nxtpage
next 10
 Message: Controlling iterations with RequisitePro    
 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: Controlling iterations with RequisitePro 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: Controlling iterations with RequisitePro 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: Controlling iterations with RequisitePro    
 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: Controlling iterations with RequisitePro    
 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: Controlling iterations with RequisitePro    
 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: Controlling iterations with RequisitePro    
 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: Controlling iterations with RequisitePro    
 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

 
 Previous Topic   Next Topic   Delete this Topic   Printable Version   Back to Forum 
page 1 of 9
previous 10
button_prepage
1  2  3  4  5  6  7  8  9
button_nxtpage
next 10
Copyright © 2001 Rational Software Corporation. All Rights Reserved. About Rational.