So how do I make sure I get the right requirements for a product?

Dear reader,

Of course it is not the R&D/development department that actually should go about and collect the requirements for the product. It should be the product manager (or product planner) that collects the requirement on a high level. Often the product manager listens and talks to the customers and follows the latest technical trends and so forth. There are seldom any issues in these areas if you have a good product manager you will normally have the right requirements in these areas (however a bad product manager can kill any product). The difficult parts are often the non functional requirements, usability or requirements on perceived quality or performance. To get these requirements right you might need to push the CEO or head of product management in the management team to improve the requirements gathering process to include the right stakeholders. Stake holders that are typically not included are operations (including the installation team), usability experts, executive management (to make sure you get early feedback, otherwise you might have to make changes later) and customer support.
Now! When the product manager have collect the “right” requirements your system design department and chef architect should add all technical requirements that are needed in the pluming to fulfil all top level requirements and start a pre-study (more on the process when to start new pre-studies in later posts) to quickly assess the work effort for each work item on a top level. In the meantime the product manager need to start ranking the requirements 1-n. If you have a very big number of requirements you need some kind of tool to help you prioritizing the requirements. I recommend the product manager to use IBM Focal Point (IBM® Rational® Focal Point™). If you have a very big number of requirements you should make three piles:

1. These are all must have (i.e. without these there is no product)
   
2. These are the requirement that will give your product an edge, but you could live without them if you must
   
3. These are good to have stuff

(Please note: if you have less requirements you can just use a Scrum type product backlog to have control over all your requirements.)
However if you using the 1, 2, 3 approach above you do this because you have a limited budget or resources and a fixed wanted delivery date for you product. In most cases you can forget about the 3 in the first release of the product so it is all about doing a focal point on number 2 and get all the most important requirements from this group into the product within you budget. Ready more about Focal point here: http://www-01.ibm.com/software/awdtools/focalpoint/

In the end, independently what type of tool you use, in my opinion you need to have a long list of the requirements that are individually ranked from 1-n, no. 1 being the most important requirement and 2 the second most important requirement etc (i.e. the same way you do a product backlog when using Scrum). Why? Because when you use for example groups of priority 1, 2 and 3 that many companies do, you often end-up not thinking the requirement through 100% and you do not get the right grouping in your incremental development when it starts. When the above is done you should now have a product backlog and the requirement part of the pre-study for the product should be ready for the next step: The detailed design and analysis phase.

Kind regards
Anders