Requirement gathering cut off when the time for requirement collection is too long

Question

I am doing a small project. Users can only provide a part of requirements. The period of user requirement gathering has lasted for two months. But it seems we will receive no information for the rest of the requirements.

Should the project be separated into two phases? One phase to launch the system for the existing requirement. The second phase could be the "reset requirement" and start the second requirement when user thinks the "reset requirement" is ready.

Is this a common practice if requirements cannot be collected for a certain period?

Answer 1

Whether you're doing a big or a small project your approach should be something like this:

• Discover what the users want (go talk to them, for example)

• Build a smallest version of that (for example no user management, only with dummy data etc.) and ask for their opinion

• If they liked it, start working on improving the functionality (add whatever you need to make it production ready)

• If they didn't ask them why and what could make it better

Repeat until "project" is done.

P.S You will never have complete requirements before you have shown something for your users several times. That's why it's generally a bad idea to have "requirements phase" anything longer than a week or two before you start building. And at least 50% of the requirements you get from users at the start will change. The percentage might be over 100 as well (meaning that even the changed requirements will change)

Answer 2

You will never have all the info for requirements so...

For this small project you can propose to build the best solution you can with the resources (info, budget & time) available. When the situation evolves so will your options.

If that is not an option you may be being set up for failure.

Answer 3

Is this a common practice if requirements cannot be collected for a certain period?

It could happen, however, if you don't know something, you will guess or ignore it. If this thing is important to the user, chances are they are not going to be happy unless your guess was correct! People who know a particular business well can sometimes guess minor details based on previous experience. Even this may not always work. For example, each bank has its own policy when it evaluates a new customer for a loan. If you skip on the rules or use another bank's criteria, this does not help.

If you can't get all the requirements, it's either because the users don't know how to answer your questions or because your team is not able to ask the correct questions. In either case, the project would be at risk. Certain requirements may be phased into a future version as you suggested. However, this may be risky in some cases. For example, in a project using a Relational Database, missing a many-to-many relation between two tables, requires work on the database and may require a change in the GUI. A practical approach is to:

1. Identify what is missing.
2. Identify why it has not been finalized.
3. If the problem is in your team, fix it.
4. If the problem is the user team, clearly identify the risk and possible associated cost. Maybe ask for a change in the user team. Use escalation procedures to make the big fish aware.
5. If you make assumptions, document these assumptions carefully.
6. Get a sign-off on the entire analysis effort - The good parts and the bad parts of the analysis.
7. Always remember that incomplete or bad analysis could easily kill any project.

This may be relevant: Dealing with incomplete requirements