Comments embedded: Hello all! Anyone, experience or ideas about the following case.
We are modeling a new release of a product family. Previously the functionality described in the use cases was designed and implemented as such. With this new release a high degree of configurability has come into the picture so that business designers can use a specific tool to create and configure the business processes using what we call process components. These can be added, removed or changed. Some of them are mandatory, some optional. In some cases the order of steps in the flow can be changed. The software should be able to function and these processes should go the way the system has been configured. So the question is, with systems that almost everything can be configurable, what would be the ideal approach to describe the use cases? <Les> This is a tough one. </Les> Here are some ideas: <Les> Here's some answers: </Les> - Describe with use cases how the configuration is done (well, this is obvious) <Les> Not so much how, as what is being done. The system is allowing users to set up their own Business Process Components (BPCs). So the use cases show how to create modify and manage these BPCs. </Les> - Describe with use cases how the functionality will be after configuration has been done (end user functionality)? The difficulty is that the possiblities are numerous because the processes are designed and configured, not implemented as a part of the product. <Les> I would use business use cases to do this. There are a certain minimum number of processes that your system must support. You're making these configurable for some reason (possibly for future needs), but the system must satisfy the business needs of today. Use business use cases to describe the current business needs, demonstrate that your system satisfies these needs. </Les> - We thought of identifying examples of most likely end user functionality and model these as use cases? But these would be only configuration examples. <Les> This statement scares me. 'Most likely' - does this mean that you don't know your end user needs? Are you building a configurable system in the hope that the flexibility will satisfy your customer needs? As I said above, I would find out the minimum business needs and make sure that the system satisifed this. Making a system highly configurable is generally a design decision, i.e. not described in use cases. Hope this helps, Les. ________________________________________________ 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 * Only plain-text messages are supported. * HTML or Rich-Text messages may be rejected. * * 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 *************************************************************************
