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

Anthony Horner
Anthony Horner
BPMN 2.0 is a modelling standard that has been around for 10 years now and although it has its foibles it has been recognised as the best for capturing the business logic behind real-life scenarios.  What most people don’t realise is that the standard itself is supported by an XML definition of its objects. What does this mean? Essent...
0 Responses
akshitavarma143
akshitavarma143
Different procedures are utilized for legitimate administration of IT administrations, yet ITIL is viewed as the best arrangement of practices for even administration of IT administrations. ITIL is the contraction for Information Technology Infrastructure Library.  In easier words, ITIL is many rules and arrangements for the effective admin...
0 Responses
Rajesh-N
Rajesh-N
What Everyone Must Know about AI in Testing Artificial Intelligence is the buzzword that we frequently keep hearing. Its widespread popularity and influence can be understood from the way industries adopting AI in their organization. Whether it’s Healthcare, Automobile, Banking & Financial Services, or Airlines, many industries have st...
0 Responses






Latest Articles

Product Owner vs. Business Analyst - Demystifying the Ambiguities
Feb 21, 2021
0 Comments
Agile projects, due to the short cycles of delivery, require a collaborative team, substantial leadership support, and a robust, agile culture to be i...
Copyright 2006-2021 by Modern Analyst Media LLC