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
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.
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.
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,
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.
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.
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:-)
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
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: