Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use Cases and Design Constraints
Previous Previous
 
Next Next
New Post 8/19/2008 12:48 PM
User is offline Dave F
4 posts
No Ranking


Re: Use Cases and Design Constraints 
Modified By Dave F  on 8/19/2008 1:51:38 PM)

It's clear to me that as a BA you don't want to get into UI design.  What is unclear is who is responsible for user interaction design?  If you leave it to the engineers they will tend to design user interaction that is system-centric, not user-centric - a recipe for user discontent.  You've seen this before:  systems where frequently executed tasks take the user many steps to complete because the functions weren't well-placed in the right screens with the right linkages to other screens.  So unless your organization has a user interaction designer who knows what they're doing, I'd rather see the responsibility fall on the BA than a developer - the BA is much closer to the user and understands what they're trying to accomplish in their work.

I like testing mockups on users to validate requirements which means, as Chris pointed out, that you have to think about separating UI elements from requirements.  I've successfully documented a highly user-interactive system the following way:

1.  Create a crude Visio drawing of the user-tested mockup screens and clearly point out that it's for illustration only to graphically show how functions are grouped.  I make it ugly enough to get the point across that I'm not trying to do UI design.

2.  Under each screen drawing I document a user-centric "focus area" which is a textual description of the functions in each mockup screen.  I can even add related business rules and UI advice from the user tests such as how fields should be named.  Simple example (o = system invoked function, . = user invoked function, > = link to other focus area):

 Focus Area:  Enter account information

 Functions
 . Enter or change customer name and address
       [here you can also specify the fields, how fields should be named, # of characters, etc.]
 o See available account managers
       Business Rule:  only show account managers assigned to the customer zip code
 . Assign account manager to customer

 Links
 > Enter new order
 > See past orders

 Business objects
   Customer
   Account Manager


3.  Provide use cases that show the dynamics of how users use the functions in the focus areas and in what order.  The focus areas provide a system "floor plan" of grouped functions and the use cases show how users move about in the system to get something done.


The focus areas are what communicate the functional requirements, but it also includes elements of interaction design:  how functions should be grouped to coherently support a task and how users want to navigate the system.

 
New Post 8/19/2008 1:19 PM
User is offline Adrian M.
741 posts
3rd Level Poster




Re: Use Cases and Design Constraints 

It is not a fast rule that the Business Analyst does not do UI design. There are many business analysts who do and should do UI Design.

Ideally, the project would have a User Experience/Design professional on but most projects don't. In that chase the Business Analyst is probably the best person on the project to specify the UI Design.

Having said that, they key (and challenge) is to keep the requirements separated from the UI design. If the only artifact that the BA creates contains both requirements and UI design it becomes unclear which parts of the UI design are requirements (which should be implemented as is) or just design decisions (which can be negotiated/changed).

From my experience, what works well is to separate the requirements from UI design and I generally achieve that by creating on set of artifacts/repository for the requirements and then include the UI design in a separate set of artifacts called Functional Specifications.

How much UI detail you provide in the functional specs depends on your organization, process, best practices. For example, if your system is a browser based system and the style sheets and UI guidelines have already been developed then the only thing that the dev team should need are wireframes. However, if that is not the case you might need to provide them with more details including colors, font types, font sizes, etc.

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 8/19/2008 5:06 PM
User is offline BrianL
2 posts
No Ranking


Re: Use Cases and Design Constraints 

 flotree wrote

It's clear to me that as a BA you don't want to get into UI design.  What is unclear is who is responsible for user interaction design?  If you leave it to the engineers they will tend to design user interaction that is system-centric, not user-centric - a recipe for user discontent.  You've seen this before:  systems where frequently executed tasks take the user many steps to complete because the functions weren't well-placed in the right screens with the right linkages to other screens. t it also includes elements of interaction design:  how functions should be grouped to coherently support a task and how users want to navigate the system.

If your engineers design like that then try to specify some non-functional usability requirements. Ideally in an organisation there should be some suitable for re-sue, but application specific ones need to be defined, especially when the functions required for a task haven't been explained before. Task specific use cases should help here.


Geek, Business Analyst, Infovore
Shadow Footprints
 
New Post 8/19/2008 5:58 PM
User is offline Adrian M.
741 posts
3rd Level Poster




Re: Use Cases and Design Constraints 

And to add to Brian's note: if you are trying to design a system with the correct grouping of screens and linkages to other screens you should begin with the business workflow in mind.  If you have a requirement which states that the system shall support the following business workflow: .... then the system can be designed in such a way.

Again - separation of the requirements and system design.

- Adrian


Adrian Marchis
Business Analyst Community Blog - Post your thoughts!
 
New Post 8/19/2008 8:31 PM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Use Cases and Design Constraints 

Jim,

Let me suggest that if you are only thinking about cases where people use a screen interface when doing the  requirements, this will affect the requirements as you describe.

However, consider that not every interface/interaction with a system is through a screen/window, and not every actor interacting with a system has to be a human being. As simple as it sounds, I find that keeping this in mind helps avoid the problem you are having. If your Use Case is about Creating a Customer, the business requirements will be the same if it is done by a person, another system, or even a batch process creating a lot of customers in one execution.

Anyway, it works for me...


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

Community Blog - Latest Posts

Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...

 



Upcoming Live Webinars




 

Copyright 2006-2021 by Modern Analyst Media LLC