2

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?

3

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)

  • Yes. The system is developed with the existing requirements. Actually, users do not clear the reset requirement so it pends too long. – Ben Cheng Aug 21 '18 at 0:17
  • Besides, it is found that agile methodology is quite difficult to evaluate the cost as the requirement may change. – Ben Cheng Aug 21 '18 at 0:21
  • 1
    @BenCheng that's not caused by the agile methodology; agile just makes it more transparant that it's happening. – Erik Aug 22 '18 at 21:09
1

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.

  • How could I charge for client if the requirement cannot be well collected? – Ben Cheng Aug 23 '18 at 6:05
1

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

  • As the project is a fixed price project, the change of requirement or unclear requirement make my project cost increase. I want to charge the change or the used time, but I may make my client unhappy. – Ben Cheng Aug 23 '18 at 2:18
  • @NoChange. As the requirement fails to collected completely, I am very difficult to get a sign-off on the analysis effort. – Ben Cheng Aug 23 '18 at 2:26
  • Sorry to say that you should go into fixed price projects unless you know the customer well or know that you have the super powers of doing the unknown. Many large companies loose in such projects. It is strange that your customer does not provide the requirements. – NoChance Aug 23 '18 at 8:44
  • It is because the user does not know the requirements. They are just a working unit and do not have a whole picture of the business flow. Sometimes, they may have many strange idea but cannot be requirements. Besides, there may other factors which make them do not want to provide requirements. For example, they do not want to learn new things. – Ben Cheng Aug 23 '18 at 9:52
  • 1
    Fixed price project automatically puts the provider of the software in a bad situation from the first day. Development should be a shared responsibility, a team work, not a legal betel. In your case, I suggest you scope the project to the areas where requirements are complete. If the user does not want to learn or keep changing the requirements, then you can't win in fixed-price contract. – NoChance Aug 23 '18 at 23:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.