Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use Cases and Design Constraints
Previous Previous
 
Next Next
New Post 8/13/2008 5:23 AM
User is offline Jim
15 posts
9th Level Poster


Use Cases and Design Constraints 

Hello,

I am a BA and am currently writing use cases for a couple projects that I am working on.  I have used use cases before and find they are extremely helpful in some cases and not as useful in others.  It depends on the system and the type of requirements.  When I am using them, one thing that I get caught up on is how to prevent imposing design constraints when describing the use case.  We always say to define requirements so as not to constrain the design.  How can we do that if use cases are supposed to be descriptions of the interactions between a user and the system?  It seems to me that in order to write them, you have to make design decisions about the interface (i.e. what is displayed on the screen, whether a drop-down list is used, whether something is visible or not) because you pretty much have to describe what is on the screen and what the user can do. 

Does anyone else face this similar issue?  Is there a better way to describe the use case or is that just the nature of the technique?  Any tips?

I want to be able to capture the requirements in the use cases, but I also want to let the designers and developers build the appplication how they see fit without unnecessarily constraining how they design it.

Any thoughts would be helpful.

Thanks,

Jim

 
New Post 8/14/2008 8:47 PM
User is offline Chris Adams
323 posts
5th Level Poster






Re: Use Cases and Design Constraints 
Modified By Chris Adams  on 8/14/2008 10:53:50 PM)

 jimbo1580 wrote

Hello,

I am a BA and am currently writing use cases for a couple projects that I am working on.  I have used use cases before and find they are extremely helpful in some cases and not as useful in others.  It depends on the system and the type of requirements.  When I am using them, one thing that I get caught up on is how to prevent imposing design constraints when describing the use case.  We always say to define requirements so as not to constrain the design.  How can we do that if use cases are supposed to be descriptions of the interactions between a user and the system?  It seems to me that in order to write them, you have to make design decisions about the interface (i.e. what is displayed on the screen, whether a drop-down list is used, whether something is visible or not) because you pretty much have to describe what is on the screen and what the user can do. 

Does anyone else face this similar issue?  Is there a better way to describe the use case or is that just the nature of the technique?  Any tips?

I want to be able to capture the requirements in the use cases, but I also want to let the designers and developers build the appplication how they see fit without unnecessarily constraining how they design it.

Any thoughts would be helpful.

Thanks,

Jim

I am in complete agreement with your desire to avoid making design decisions within use case specifications.  This is certainly one of the hardest things to do and at times it may even seem unavoidable. Looking back at my work, however, I find that usually I am successful at avoiding most design related information.

The following information presumes that you are developing the use cases very early on in the process to capture requirements.  Screen design should come later, though when working with business representatives they seem to want to see screens right away. 

To avoid design decisions remember a few things. First, use cases and screens are not a one to one relationship.  A system use case describes a series of actor/system interactions to achieve something of standalone value for the user.  So a single use case will often, if not usually, span multiple screens within a system.  There should be no reference to or knowledge of these screen to the reader.  It's just "the system". Second, while the system will display information to the user/actor you don't need to specify what controls are used.  The actor will provide certain information and the system will do something or make a decision based on that information.  Then, it may present some information back.  Exactly how the user sees that information you don't need to get into.  Third, don't allow the logic of the system use cases to get too overly detailed.  Remember, they are not the only artifacts you will be creating.  They are to capture functional requirements in a way thats easily understood by the business.  If you get too detailed you defeat the purpose of creating use cases.

I know a lot of this sounds easy, but is actually very difficult in practice.  Another tip that I have found helpful to keeping design out of my system use cases is to first start by creating business use cases.  Describe the processes in term of the business and busines workers as if none of the process was automated by a system.  Moving from a business use case to a system use case, i.e. replacing parts of the business use cases with user/system interactions, help get you going on the right track.

Finally, a comment about developing use cases simultaneously with screen mockups.  This is often done so that the business can visualize how things will work.  If you must go down this path then understand that keeping design out of your use cases will be much more difficult.  You as the analyst will inevitably start thinking about controls and screens.  Just make sure you don't include them in your use cases.  This makes use case maintanance unbearable and eventually your use case model reflects far more than functional requirement.  They begin to restrict your developers.

Hope this helped.  I know some of this may seem generic.


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
New Post 8/15/2008 6:17 AM
User is offline vinny
66 posts
8th Level Poster


Re: Use Cases and Design Constraints 

 cadams5 wrote

 

 

There should be no reference to or knowledge of these screen to the reader.  It's just "the system". Second, while the system will display information to the user/actor you don't need to specify what controls are used.  The actor will provide certain information and the system will do something or make a decision based on that information.  Then, it may present some information back.  Exactly how the user sees that information you don't need to get into.

Describe the processes in term of the business and busines workers as if none of the process was automated by a system.  Moving from a business use case to a system use case, i.e. replacing parts of the business use cases with user/system interactions, help get you going on the right track.

Finally, a comment about developing use cases simultaneously with screen mockups.  This is often done so that the business can visualize how things will work.  If you must go down this path then understand that keeping design out of your use cases will be much more difficult.  You as the analyst will inevitably start thinking about controls and screens.  Just make sure you don't include them in your use cases.

Original poster:

Chris offers excellent advice here!

It's taken me a little while, but currently I do almost exactly what Chris has advised above and it really does work.  In the business process modeling stage, I have trained myself to leave out, like you mentioned, drop-down lists.  Instead I let formally documented stakeholder-defined constraints (e.g. "We only want the customer to be able to specify two-letter state designations according to the region that they are in.") influence in the design stage what mechanisms will be used to fulfill the requirements (the developer may decide to use something else other than a drop-down list, despite the possibility that I'd opt to use a drop-down list).

 
New Post 8/15/2008 8:01 AM
User is offline Jim
15 posts
9th Level Poster


Re: Use Cases and Design Constraints 

Thanks for the advice!  I came from the development side of the house, so I think I automatically think about how the screens would look.  I am trying to change my mindset when doing the business analysis and that is why I am looking for tips. 

Would any of you be able to post an example of a use case you have done in the past?  It would help me to see the kind of language that you use to describe the interaction between the user and system in a full example...what the user does and how the system responds.

Also, lets say that the users require that all changes to account status get tracked and they need to be able to see the status history.  Would you specify in the use case that allows a user to change the status of an account the following :  "...the system records the status change, including: old status, new status, date, and user."?

Thanks!

 
New Post 8/15/2008 11:07 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases and Design Constraints 

Hi:

I suggest try researching on "essential use cases".  Essentail means implementation independent - which is what you are after.   Of course, an essential use case can not compare with the power of an essential data flow diagram:-)

Tony

 

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Use Cases and Design Constraints

Community Blog - Latest Posts

Fabricio Laguna talks Business Analysis and AI
I recently connected with Fabricio Laguna, aka The Brazilian BA. Fabricio is a passionate and pioneering business analyst from Brazil. During our conversation, we had a thought-provoking discussion on how artificial intelligence stands to shape the field of business analysis in the years ahead. While AI promises to transform many aspects of busines...
Business Architecture, Ontology and More with Terry Roach
It's been a privilege meeting Terry Roach, a visionary in the field of enterprise architecture and business architecture. Terry's insights into the evolution of business models, the importance of ontology in architecture, and the potential of AI to shape our future were not only thought-provoking but also a reflection of his extensive exper...
Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...

 



Upcoming Live Webinars




 

Copyright 2006-2024 by Modern Analyst Media LLC