Stephen,
1) There was no "guesswork" involved. The exception was documented in that manner, as a result of working with the customers in eliciting the requirements of the system. If some of the rules that I had related to the generic exception were not handled by the described behavior, then that would have been a requirements error. That would have been caught during reviews (knock on wood) with the customers, and addressed through correcting the traceability, or actually describing it as its own exception in the use case. (Remember, I am not saying you can't, only don't hinder the readability of the use case) 2)As far as communicating business rules, I generated views of the rules and reviewed them with the customer along with the use cases. 3) The use case is not the only artifact for communicating with the customer. There are prototypes, non functional requirements, scope documents, test plans, etc. Of course, the requirements contained in the documents relate to 1 or more use cases. 4) If you are not using a tool, then either I would document the rules as a section within a use case, or could have a standalone document of rules, and have references made by them in the use case text. Whatever works. Please consider purchasing a tool like req pro. I am currently involved on a project that uses a document only approach, and the management of the requirements has been a challenge, as well as other problems, that could be eliminated through the use of a tool. 5) You also had a question about the capturing of rules outside the use case mechanism in Req Pro. I don't know if this will answer it, but all I did was to simply use a separate requirement type of BR, and assign specific attributes that would apply to rules. For example, one of the characteristics of the project was a gas transportation system that was deployed on different pipelines. The pipelines had rule differences, so I used an attribute of "Pipeline" or "Applies To" (can't remember specifically) and assigned the appropriate value. Hope this helps, Jim >===== Original Message From "Baynes, Steve" <[EMAIL PROTECTED]> ===== >Jim, in my opinion I think you have just described a very good case of an >include use case. > >I see a number of issues here in not making it a use case. >1. you have "guessed" that the actions are the same every time (this does >not mean you are wrong but it does imply an understanding of the business >and the solution). Nothing wrong with this approach but it is surprising >how many exceptions to the business rule occur. >2. the use case is the only artefact for communicating with the customer so >how so you communicate this business rule? > >I am very interesting in how you capturing business rules outside the use >case mechanism in requisite pro. > >Regards >Stephen Baynes > >-----Original Message----- >From: eleadsolutions [mailto:[EMAIL PROTECTED]] >Sent: 14 August 2002 15:49 >To: Baynes, Steve; rose_forum; Les Munday >Subject: RE: (ROSE) UML and Business Rules > > >Stephen, > >I disagree with your statement about business rules "must be captured in the > >use cases". What really needs to happen is that business rules must be >captured, but can be traced to use case flow of events, or exceptions, >instead >of documenting them directly in a use case document. > >I have worked on a project where I described generic exceptions, and related > >the business rules to it using Requisite Pro. For example, I had something >like "Invalid Contract" exception. There were many ways that you could have >an >invalid contract, but the system responded in the same manner to these >errors. > >(i.e., The system displays an error message, blah blah blah) The business >rules that triggered this exception were either entered as database only >rules, or were described in legacy documentation. Rather than >duplicate/reenter this information, I imported the legacy document into RP, >tagged the appropriate text as a business rule, and related it to the >appropriate exception or flow of events. > >I am not saying that you can't document rules in the use case. But remember, > >one of the key benefits of applying use cases on a project, is that they are > >great way to communicate the behavioral requirements of a system. We should >not hinder this by exceptions which are so bloated because we have >documented >every rule in it. > >Hope this helps, >Jim McAllister >eLead Solutions, Inc. >cell#: 713-582-5725 >email [EMAIL PROTECTED] > > > >>===== Original Message From "Baynes, Steve" <[EMAIL PROTECTED]> ===== >>All, The need for business rules must be captured in the use cases. Use >>cases are the requirements documents. The implementation of the business >>rules will flow throughout the rest of the analysis, design, implementation >>and testing. >> >>Business rules may be driven by object state transition, the >>inter-relationship between objects etc. This means no single artefact, >>other than use cases, can capture the need for these rules. >> >>This is all "in my opinion". I look forward to some different views... >> >>Regards >>Stephen Baynes >> >>-----Original Message----- >>From: Les Munday [mailto:[EMAIL PROTECTED]] >>Sent: 13 August 2002 22:24 >>To: '[EMAIL PROTECTED]' >>Subject: Re: (ROSE) UML and Business Rules >> >> >> >>Since I think of business rules as generally applying to >>attributes and relationships between attributs, and since we >>don't reference attributes within use cases, I would not >>recommend stating business rules in use cases. >> >>I also think of business rules as being flexible, much more so >>than I want my use cases to be. >> >>So my expectation would be to see business rules described by a >>business object model. I think that they attach quite nicely to >>the attributes and relationships in the class diagram. >> >>Much better place than use cases, IMO. >> >>Les. >> >>> >>> UML and Business Rules - are these two things complementary? >>> Some people believe that when you use UML/Use Cases you don't >>need >>> business rules techniques to capture business policies, >>regulations, >>> restrictions, etc. >>> - since it got captured in use cases anyway. >>> Other people think that UML is not sufficient for these >>purposes. >>> >>> What is your approach to this? >>> >>> Thank you. >>> >>> David Lyalin >>> >>**************************************************************** >>******** >>> * Rose Forum is a public venue for ideas and discussions. >>> * For technical support, visit http://www.rational.com/support >>> * >>> * Post or Reply to: [EMAIL PROTECTED] >>> * Subscription Requests: [EMAIL PROTECTED] >>> * Archive of messages: >>> * >>http://www.rational.com/support/usergroups/rose/rose_forum.jsp >>> * Other Requests: [EMAIL PROTECTED] >>> * >>> * To unsubscribe from the list, please send email >>> * To: [EMAIL PROTECTED] >>> * Subject: <BLANK> >>> * Body: unsubscribe rose_forum >>> >>**************************************************************** >>********* >>> >>> >>> >> >> >>________________________________________________ >>Get your own "800" number >>Voicemail, fax, email, and a lot more >>http://www.ureach.com/reg/tag >>************************************************************************ >>* Rose Forum is a public venue for ideas and discussions. >>* For technical support, visit http://www.rational.com/support >>* >>* Post or Reply to: [EMAIL PROTECTED] >>* Subscription Requests: [EMAIL PROTECTED] >>* Archive of messages: >>* http://www.rational.com/support/usergroups/rose/rose_forum.jsp >>* Other Requests: [EMAIL PROTECTED] >>* >>* To unsubscribe from the list, please send email >>* To: [EMAIL PROTECTED] >>* Subject: <BLANK> >>* Body: unsubscribe rose_forum >>************************************************************************* >>************************************************************************ >>* Rose Forum is a public venue for ideas and discussions. >>* For technical support, visit http://www.rational.com/support >>* >>* Post or Reply to: [EMAIL PROTECTED] >>* Subscription Requests: [EMAIL PROTECTED] >>* Archive of messages: >>* http://www.rational.com/support/usergroups/rose/rose_forum.jsp >>* Other Requests: [EMAIL PROTECTED] >>* >>* To unsubscribe from the list, please send email >>* To: [EMAIL PROTECTED] >>* Subject: <BLANK> >>* Body: unsubscribe rose_forum >>************************************************************************* >************************************************************************ >* Rose Forum is a public venue for ideas and discussions. >* For technical support, visit http://www.rational.com/support >* >* Post or Reply to: [EMAIL PROTECTED] >* Subscription Requests: [EMAIL PROTECTED] >* Archive of messages: >* http://www.rational.com/support/usergroups/rose/rose_forum.jsp >* Other Requests: [EMAIL PROTECTED] >* >* To unsubscribe from the list, please send email >* To: [EMAIL PROTECTED] >* Subject: <BLANK> >* Body: unsubscribe rose_forum >************************************************************************* ************************************************************************ * Rose Forum is a public venue for ideas and discussions. * For technical support, visit http://www.rational.com/support * * Post or Reply to: [EMAIL PROTECTED] * Subscription Requests: [EMAIL PROTECTED] * Archive of messages: * http://www.rational.com/support/usergroups/rose/rose_forum.jsp * Other Requests: [EMAIL PROTECTED] * * To unsubscribe from the list, please send email * To: [EMAIL PROTECTED] * Subject: <BLANK> * Body: unsubscribe rose_forum *************************************************************************
