Your first step in the requirements gathering process should be to solicit requirements for your software development project from the stakeholders. The method and techniques you choose to employ for the purpose of requirements solicitation will require you to contact these stakeholders for the purpose of either gathering them together, meeting with them one on one, or communicating with them long distance. That first contact will require a contact list of key stakeholders.

[Read the rest of this article...]

The intent of this section is to offer you some insight into the various requirements gathering tools available and the factors you need to consider when choosing which to use for your project. You'll need to take training in the use of these tools before becoming proficient in their use.

The nature of the software application or web site your project will deliver will influence your decision on which requirements gathering tools to use. Other factors that will influence your decision are the number and type of business users, customer service reps, and maintenance people and their locations. We'll attempt to describe some of the tools available to you in this section and describe situations where they would be appropriate to use.

[Read the rest of this article...]

We mentioned previously in this section that a Statement of Work (SOW) embedded in the contract for a project will serve as the master blueprint for your requirements. Although we haven't consistently stated this disclaimer everywhere in this section it should be understood that no requirement, no matter how you gathered it, no matter who contributed it, no matter who approves it, can be a part of the required product unless it's stated or implied in the SOW! Keep this fact in mind when you identify the approvers of your requirements.

[Read the rest of this article...]

The requirements you capture must be stated in business terms, must be clearly stated, must be concise, and must be feasible. To ensure that requirements are clearly stated, you should have them proof read by someone external to the project (or at least someone not familiar with the requirements you've captured). Any questions raised by your proof reader should trigger a re-write of that requirement. Clean the language up until your proof reader understands the requirement.

[Read the rest of this article...]

I've seen alot of buzz and movement in the industry around requirements visualization. There have been talks, white papers, discussions, new tools, a...

[Read the rest of this article...]