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 5: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 4: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 9: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 4: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 7: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

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