Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Use Cases and Design Constraints
Previous Previous
 
Next Next
New Post 8/21/2008 6:39 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases and Design Constraints 

Hi:

I totally agree with Adrian on seperation of requirements and design.   Up-front, the focus has to be on essential (unchanging) business functionality.    This can not be overstated!   I have lead larger-scale intergration efforts where I tied together the requirements of more than a dozen BA's across projects.     What I really had to do was coach BA's to postpone implementation considerations and to focus on the essential.  Such work really makes clear the overwhelming need that most BA's (and others) have to "get technical" ASAP.

Especailly for larger scale efforts, a focus on the essential often requires a single-minded bullheadedness.   I have always found that, in most orgainzations, you have to be counter cultural.    But, frankly, without such a mindset, much of essential requirements are not going to captured until they have to be  (in later phases of the project, resulting in messed up patchwork design and primative user interfaces).

Tony

 

 

 
New Post 8/22/2008 5:53 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Use Cases and Design Constraints 

 ajmarkos wrote

What I really had to do was coach BA's to postpone implementation considerations and to focus on the essential.  Such work really makes clear the overwhelming need that most BA's (and others) have to "get technical" ASAP.

 I guess the industry is heading towards essential features only in the first release (aka iteration) as a default position.

 ajmarkos wrote

Especailly for larger scale efforts, a focus on the essential often requires a single-minded bullheadedness.   I have always found that, in most orgainzations, you have to be counter cultural.    But, frankly, without such a mindset, much of essential requirements are not going to captured until they have to be  (in later phases of the project, resulting in messed up patchwork design and primative user interfaces).

I don't think you have to be bull headed with clients - senior people usually very literate about what can be done and how it should be tackled.  I agree that you do have this issue with more junior managers and analysts.

I don't see the problem with a just in time requirements approach - but you hvae  to have a big picture view to get your overll design & prioritisation right.

 
New Post 8/28/2008 10:23 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Use Cases and Design Constraints 

Craig:

Does senior level management know what needs to be done?  For some really important issues,  I have always found that, with few exceptions, the answer is no.  Example:  The need to employ a logical, natural partitioning in functional analysis - and avoid forced, artifical partitioning.    Even the "big boys" seldom, if ever, know what that means.  

Tony

 

 
New Post 8/29/2008 5:55 AM
User is offline Craig Brown
560 posts
www.betterprojects.net
4th Level Poster




Re: Use Cases and Design Constraints 

 ajmarkos wrote

Craig:

Does senior level management know what needs to be done?  For some really important issues,  I have always found that, with few exceptions, the answer is no.  Example:  The need to employ a logical, natural partitioning in functional analysis - and avoid forced, artifical partitioning.    Even the "big boys" seldom, if ever, know what that means.  

Tony

Tony,

In my experience the senior managers do know what they want. And so do most of the other layers of management. What breaks down is their ability to articulate it in a way that a BA and Project team can effectively translate into a solution.

The problem so many projects face is that the requirements simply get lifted and carried across to the development team as stated.

The BA's job is to work with the business clients to properly frame up their requirements in terms of problems and opportunities to be addressed.  Only once this is effectively done should requirements be addressed.  And then, as you say at the logical level first.

Tony, I believe my clients are smart intelligent people who are excellent at running their business.  There are contraints there that make their jobs hard.  It's our job to play our part by assisting them in firstly identifying the problems and opportuniies as they present themseleves and then finding the right solution for them.

I've read your posts and you believe this too.  Its why you are so passionate and committed to doing an excellent job.

 

 
New Post 9/8/2008 8:13 AM
User is offline Irene
31 posts
9th Level Poster


Re: Use Cases and Design Constraints 
Modified By Irene  on 9/8/2008 9:16:54 AM)

I also agree to separate UI design from Business Requirement, use cases; and put UI design as part of Functional Specifications. If there are both BA and BSA on project, I think BA, with better business domain knowledge, should do most of the initial work and get the business requirement, then BSA creates functional specs and screen mockups. After fully understanding the business requirement and confirming with development team, A BSA should suggest and decide ex. whether using dropdown or radio button on screen. Functional specs, including screen mockups, should also be presented to end users. Engineers/developers should not be the key person to do the UI design.

  

 ajmarkos wrote

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

 

Here I have some confusion about “essential use cases”. I thought all use cases should be implementation independent. Is not that “essential use cases” are just the first step or preliminaries of “normal use cases”? After getting “essential use cases”, should BA still need to continue getting and putting more info for regular (non-essential) use cases?

 

Thanks,

Irene

 
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