Defining a project requirements listing makes sense.

Developers

How many times has someone said, "I need you to build a {application description*}, how much will it cost?" And the person saying it fully expects an answer even though they have not given you nearly enough information to help them, and may still have no clear idea of what they actually want yet. The potential customer obviously has not fully thought out a plan, and unfortunately has not even begun to gather the requirements needed for someone to give them an accurate estimate.

After restraining the desire to reply with something condescending the first order of business is to help this potential customer realize why the question cannot be answered without more information. There is no way to know how long it will take to build what they have in their mind, let alone how much it will cost for the man-hours and/or software licenses it will take to support the functionality that requirements gathering will uncover.

Business Owners, Startups and Visionary

You know what it is like to approach a developer while trying to figure out what the next steps are for your project and say, "I need you to build a {application description*}, how much will it cost?" Then feel awkward while faced with blank stares, or worse, the "deer caught in headlights" look of someone who can't response due to a lack of information.

It may be a great idea that could be profitable, but unfortunately many try to build applications without clearly defined requirements, specifications, or know what they really want. This would be similar to going onto a car lot and asking how much a car will cost without giving any more data. If the salesman doesn't know whether the buyer need an SUV versus a compact how could he possibly give any idea how much it will cost? Or perhaps he might give a price for a car without air conditioning because it was not mentioned. Of course that may be OK, unless the buyer lives in Florida or Arizona. Ouch!

ReqHarbor knows how difficult it can be to build a requirements list needed to clearly define an application, enhancement, or tool. So we built this requirements gathering site to enable both developers and business people get closer to the vision of what is needed.

Businesses fail due to poor preparation.
It is no secret that a primary reason businesses and applications fail is because the main building blocks were not clearly defined, thought out, or were missing from the start. Too many startups, who may have had a wonderful idea, tried to go straight to the attack phase without everyone involved fully understanding what the visionary truly "saw".

It is vital when building an application, website, or enhancement, that everyone fully understands what they are building. Otherwise you will end up with missed deadlines, project scope creep**, overly complex tools that do not get used, or features that are completely absent from the finished product.

The right requirements gathering tool helps avert disaster.

The Application

• With ReqHarbor a user will start by creating a project or application, and defining many aspects typically missed or overlooked during the application life-cycle until it is too late.
• ReqHarbor will help clearly outline a description of the vision and application by using the goal, revenue generator, user objectives, and target users. The end result will be a team where the business owner/manager ensures everyone involved "knows" what the goal is.
• All participants in the application should clearly understand what they are building, and what the end result should achieve. Otherwise they may be going in totally different directions.

The Persona

• Many find it helpful if all participants can "visualize" the average customer, visitor, or user of the application being built. This ensures time is not wasted on options or functionality that will never be used, or that confuse users.
• By creating a persona, and naming him/her, it also helps participants "look" at the user as a person rather than an object. This generally helps improve the quality of the project. We don't want to disappoint "Jane" do we? What would "John" expect when that link is clicked?
• A teenage girl is going to use something entirely different than a 40 year old man. By defining a persona of your target audience all participants in the project "know" who they are dealing with, and become intimate with the details quickly.

The Features

• If it is something that should be included in the application, it should be defined as a requirement feature. Otherwise it will not be built.
• Everything, no matter how small or large should be a requirement feature and have a priority set to it. Then the developement team can look at the application requirements and understand what features should be build in version 1 and which can be rolled out in version 2. Imagine if a full e-commerce site was built, yet there was no way to get to shopping cart after items were added to it. Do you think that would make it difficult to generate cash flow?

By using ReqHarbor you can avoid these pitfalls, and get your development team off on the right foot with a clearly defined application and full list of features. No longer will everyone show up for meetings and wonder what is going to be built.

---