Without project requirements gathering, a project is nothing. One failure point is letting the wrong people gather the requirements.
There are basically two types of requirements for an application project: the functional/feature-set and the technical.
Pitfall: There must be at least one cycle of comparing Functional to Technical requirements to ensure they sync up, followed by adjustments to both (as necessary).
Functional
This answers the two questions:
- What will this application do?
- How will the user interact with the application to get #1?
If you want your application to feed the user by ordering from Fries-2-Go™, the 24-hour french-fry delivery service (fries in 27.5 minutes or you supersize for free!), that is #1. If you say that the user will push the Big Red Button on the app, then say what flavor fries they want (Creamy Chicken Velouté, Herb Hollandaise, or Buttery Béchamel), that is #2.
Note that we didn’t say HOW this magic happens. That is not the purview of the Functional Requirements.
Pitfall 1: the stakeholders (especially people who are representative of those who will use the app) MUST participate when crafting the requirements, especially any workflow.
Pitfall 2: failing to involve an experienced technical architect during this phase may result in defining requirements that are not technically feasible, craft a clumsy/unwieldy workflow, or miss borrowing from solutions in similar applications.
Technical
These requirements are concerned with the plumbing, the hidden part of the iceberg and the underground kingdom of the Troll People. Functional requirements—from a high level—are absolutely required (see what I did?) to be defined before the technical requirements are attempted.
Pitfall: any attempt by non-technical folks to attempt to work on these will result in flawed implementation, busted schedule, cost overruns and lowered team morale (lowered productivity).
Failure Examples
A high-level manager defined functional requirements with no input from field staff or technical architects. She then defined technical requirements based upon an internal standards white-paper, but without the understanding necessary to apply the standards to this project.
The technical staff was brought in at the last minute and told to review the requirements quickly so that work could begin. Immediately, the staff noticed several major flaws. For example, one of the functional requirements violated app store constraints, which would prevent the app from ever being accepted by the app store. In addition, the requirement was completely unnecessary, as there were external apps that provided the same features.
The manager (perhaps to save face) ordered the project proceed with the original functional requirements intact. This resulted in a product that cost more than necessary, it could not be distributed via well-known app stores, and it contained useless and confusing functionality.
