Career Forums

Hello,

What is the Business Analyst's role in determining the feasibility of requirements elicited from business users?  I'm mostly interested in technical and operational feasibility. 

With respect to technical feasibility...When should we as BA's make the determination that a requirement is not technically feasible?  How should we go about backing up our determination? 

I was a deveIoper in my previous life and I am currently gathering requirements for a project where some of the business requirements seem like they will be extremely difficult to implement.  And even if they are technically feasible, they will make the system very complicated for the business user to operate and will introduce inefficiency into the process.  How can I go about determining the technical feasibility and how should I communicate the results to the business?

Thanks - Jim

[QUOTE]dwwright99 wrote

As a BA and no longer a developer, you will have to start letting technical feasibility be determined by the people on the project who are the designers/developers. Its hard to let go of some things but, unless you keep yourself current as a developer as well as a BA (which doesn't sound easy), your technical knowledeg will get old fairly quickly and could actually be a detriment to your project if you don't get technical people to do this.

So, in general, a BA should not be expeccted to determine technical feasibility. My own pre-BA technical skills were in PL/1 and IMS, so I can't say that would be much help these days!

[/quote]

David I disagree.

If you know something is not feasible you have a duty to the client to cut off that area of inquiry as soon as possible.  Otherwise you are consiously wasting time and money.

The caution is that your developer skills will fall out of date and you'll need to consult with current experts to validate your hunches.

Feasibility checks are well withing thye scope of the BA role - see the BABOK's process areas.  The chapter on enterprise analysis specifically covers this ground.

Additionally the enterprise architecture role (which has significant overlap with the BA profession) also looks at identifying contraints and guides to shortcut the efforts required for the feasibility question.

This goes to a value set Kevin Brenan of the IIBA asks - do BAs take a neutral stance to solution design or do they get involved as early as possible?

The answer is about the context - the individuals and the circumstances.  And it also involves layers.  Solutions come in iterations and requirements respond  well to incremental design of solutions.  It's a conversation.

Craig
www.betterprojects.net

Hmmm... if you absolutely know something is not feasible, sure, don't keep it to yourself. The question is, on what basis do you 'know'? As you say, "The caution is that your developer skills will fall out of date and you'll need to consult with current experts to validate your hunches.". That is pretty much all I was saying...but I will look at the BABOK again soon.

As for the BA and solution design, it is about the project. As the usual stats say, most projects are maintenance/enhancement of existing systems, so the design is in place. Of the rest of the projects to deliver new systems,  a lot of those end up buying packages, so no design there. Its been a few years since I did complete requirements for a new system to be developed, and it was not a big system. So, perhaps that colors my opinion on this topic, but I will stick with "what, not how" as my guide as a BA until the opportunity for new development appears.

Whenever I do get to do that, I do hope there is Business Architecture (everything in Zachman Row 2, I think) in place, so that you know you can deliver in iterations and the resulting pieces will fit together. I wax and wane on overall Enterprise Architecture. I think I like the concept, but don't have an opportunity to apply it. That's probably a bad thing in the long run, but I don't know if the answer is to try to apply EA more, or try to make EA more 'appliable"...probably somewhere in between.