Advanced Search
Username
Password
Forgot password?
 

Top Forum Posts
Welcome to the Catalyze Forums

The Forums on Catalyze give members an opportunity to network with other members and ask/answer questions on current topics.
Want to post?

You must be a registered member of the Catalyze community to post;

Click here to JOIN TODAY  If you are already a member, SIGN IN HERE
 
Forums > All Catalyze > Requirements
Subject: Technology Options In requirements?
 Add Tag
You are not authorized to post a reply.  
Author Messages
Rating:
wande00
Posts:1
01/22/2008 3:08 PM Alert 

I am sure I am not experiencing a unique situation here. Consistently the business analyst developing the requirements puts in requirements such as "Technology to provide options to achieve "X" and provide cost estimates for each option". I do not feel the requirements document is the appropriate place for such a request, but where should it go?

Ultimately when you are dealing with brand new functionality, the business often wants to understand their options and costs associate to those options. We cannot provide that detailed information until after the requirements submitted to the technology teams, so where is the best place for this sort of request?

 
robeveretts
Posts:4
01/25/2008 5:47 PM Alert 
I think there are multiple approaches to what I think you're saying here. If I hear you correctly, BAs are being asked to list out potential solutions to an issue and provide costs associated with each possible option, right? You are absolutely right that these should not be in the requirements doc.

First of all, anything to do with cost around here goes through Sales and/or Project Management, but if you don't have those options, you should consider having the BAs create a Project Charter document with this information in it. If you already understand the entire business need or issue and have a handle on potential solutions, you can outline them at a high level in a document like this. The Project Charter is usually used to state the purpose of the project and what the definition of success will be on the project. You can adapt this to state several possibilities for success based on the solution chosen.

My caveat to all of this is that solutions shouldn't usually enter the discussion until all requirements are gathered. New features and functionality need thorough analysis, and jumping too early into the solution ring can tie you down to an undesireable solution or a cost that is lower than you anticipated. I would suggest having at least one or two intense JAD sessions with the business and then discuss the requirements with your technology team (or involve them in the JAD sessions as silent observers)before outlining these options in the separate doc. We have found that involving the tech team early in the process means fewer misunderstandings when it comes to translating the business rules into technical specs, plus it helps for everyone's heads to be put together to ponder the various options you have for a solution.

One thing to note in conclusion: DO NOT discuss solution options with your business users until you have discussed what can be done with the tech team. Putting your users into the solution-seeking mode often leads them to overlook their true requirements and can mean you have an unsuccessful product in the end. "Seek 1st" is a great method to look at, because it tells you that you need to first seek to understand the need or the issue, then move into how that can be achieved. Hope that helps!