How important is knowing functionality before coding?

Question

I work for a software development company where the development work has been off shored to us. The on shore team handle the support and talk directly to the clients. We never talk to the clients directly we just talk people from the on shore team, who talk directly to the clients.

When requirements come, the on shore team talk to the clients and make requirement documents and inform us. We make design documents after studying the requirements (we follow the traditional waterfall model).

But there is one problem in the whole process: nobody in the either off-shore or on-shore team understand the functionality of the application completely. We just know its a big complex web app handling complex order processing, catalog management, campaign management and other activities. We struggle with the design document as the requirements would not be clear. It then goes into a series of questions/answers back and forth between the on shore team, off shore team and clients. We would often be told to understand functionality from the code. But that's usually not feasible as the code base is huge and even understanding a simple menu item take days if not weeks. We tried telling the clients to give us knowledge transfer about the application but to no avail. Our manager would often tell us to start coding even if the design document is not complete or requirements are not clear. We would start by coding the part of the requirements that seems clear and wait for the rest.

This usually would delay the deployment by a month. In extreme cases we would have very low errors in the development and production but the clients would say that's not what they asked. That would start a blame game and a series of change requests and we would end up developing something very different.

My question is how would you do development work if you don't know the functionality of the app fully?

UPDATE

The development methodology it isn't really my choice and I am not my team's lead. It is the way it began. I tried to tell people about the advantages of agile but to no avail. Besides I don't think my team has the necessary mindset to work in an agile environment.

Answer 1

Short version:

Knowing what to do ≠ knowing your customer.

Imagine this: you're a company related to real estate development. You ask your partner to build a large complex. The partner says that despite all the documents you gave him, he also need to talk directly to the people who would purchase the flats in this complex. Seriously?

---

Long version:

It's always nice to know how a specific application will be used, because it's fun to learn things, but it is not always possible on large projects.

Some domains are just too complex. If you're just a developer and you are working on multiple applications from multiple domains, you just can't always understand what the end user is doing, because it would require you to spend five years learning accounting, ten years in medical school, six years in law school, etc.

On the other hand, a software product made with no understanding of the specific domain will be at best, well, a bit unusable.

That's why functional and non functional requirements must be written by people who fully understand the domain. In general, requirements gathering involve at the same time:

1. Technicians (for example developers who would tell that a specific feature is impossible, that this other one can be much better if done this way, and this one will cost thousands of dollars while there is a much cheaper alternative),

2. People specialized in project management,

3. People specialized in the domain of the customer, who have the full understanding of this domain and the precise needs of the customer. Of course, this may be the customer itself.

One functional and non functional requirements are written and are precise enough, you don't need anything else as a person whose work is to translate those requirements into code.

---

As for your specific case, you describe the cause of the problem yourself:

We struggle with the design document as the requirements would not be clear.

It's not the lack of knowledge about the customer which causes all the trouble, it's the low quality of the requirements. In a correctly managed project, the functional and non functional requirements must be perfectly clear and unambiguous. If the requirements document is not clear or if it tells you that "the visual design of the product must be attractive" or other stupidities like that, it's because it was written by people who don't know how to write it.

Knowing that, you have to act differently:

• If you know that the team which gathers the requirements is desperate, and your own team have skilled people for requirements gathering, explain the situation to your superior and tell that the other team must be replaced by somebody competent, for example the people from yours.

• Otherwise (i.e. if they are not desperate), try to determine their internal cause of those low requirements and persuade them that doing their job correctly will only reduce the overall cost of the project. Showing the statistics about how badly written requirements influenced the project by increasing the cost (how much?) and the risk of not being ready for the deadline is a good idea here.

Probably the requirements document is just incomplete. I see this all the time: inexperienced project managers are just convinced that one-page document is enough, and don't understand why they would ever write three to four hundred pages instead of one. If it's the case in your company, show that spending more time on requirements would decrease the costs.

Answer 2

You are using exactly the wrong development methodology for the problems you are facing.

By using Waterfall you are committing to:

1. Getting the right requirements up front - this obviously isn't working
2. Coding the requirements away from the customer - you aren't able effectively check issues with the customer given you have committed to developing to the requirements
3. The first chance the customer gets to see their functionality is during testing - this is far too late given the issues you are having

Consider using, if it is possible, a different way of managing the project. Agile Software Development has several features that are designed to tackle the issues you are facing.

A decent comparison of Waterfall vs Agile was written a while back, lets take a couple of quotes from it that highlight your problems:

Missing the Mark:

Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs. The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method.

Tied Down...

Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction. As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.

...and Unable to Move

To synopsise the difference between the two, one can say the classic waterfall method stands for predictability, while Agile methodology spells adaptability. Agile methods are good at reducing overheads, such as, rationale, justification, documentation and meetings, keeping them as low as is possible. And, that is why Agile methods benefit small teams with constantly changing requirements, rather more than larger projects.

Where you are now is bad; you are not delivering to the customer's requirements, and, if you are in the blame part of software development, productivity is going to go out of the window, distrust is going to rise, and things are likely to get worse, not better.

The relationship with the customer is critical; here, it sounds like you aren't able to effectively collect their issues and adapt to their changing requirements in the way you are currently working; therefore you need to look at ways of changing that.

Answer 3

That's not the way it works is it. One of the subjects of my current education is that of analysis, and the relationship with a customer. The emphasis has alwyas been on clearly defining the project. Imagine this:

• You order a building company to build a house but you don't know how you want it to look. You just customise the first floor, so the team builds a house up to the first floor. Then you want the ground floor to be layed out differently. Oops...

Unless you're very sure you can (partially) make correct foundations for the application, I would just tell the client there is no other way it's going to be done than with clearly defined goals and functionalities. Because if you just take a stab at what it might be, you'll risk throwing a lot of money and time down the drain.

Answer 4

Here's some things that will help overcome the problems:

1. Improve communication between the two teams. Ask the other team to compress the requirement to 3 words, and then programmer will implement those words exactly. The words just need to be correct. Nothing will be implemented without those words. Every word gives you 2000 lines of code. Implementation begins when a new word is known.
2. If a word is not immediately clear to your programmers, they are allowed to ask single question. The question again have to be correct one. It needs immediate answer -- the answer cannot wait a roundtrip from other side of the world, but it needs to be known beforehand. Implementation starts immediately after receiving the answer and the answer will be followed to the letter.
3. If during implementation there are unclear or fuzzy requirements, the way to resolve them are to first look at the (existing) 3 words. If it still is unclear, then programmer makes the best guess possible. Any delay in this process is absolutely forbidden; and asking help from the other team is not the right way to resolve it -- they already had their chance of changing the requirements by deciding correct 3 words.
4. If after all this, the requirement is still unclear or impossible to implement, the correct way to handle is to reject those 3 words that caused the trouble, and move to next words. Any rejected words will be collected and passed to the other team, and they will need to modify the words before re-entering them to the system. Rejecting words always moves the deadline and implementation will need to be planned again.
5. Teams would need to be evaluated based on how many rejected words they have. After requirement has been implemented, it is fixed forever and can no longer be changed. Any attempts to change already implemented features will be rejected.
6. The actual problem with the question is that it assumes that more information makes implementation easier. This is not true. The more freedom your programmers have, the easier the implementation. Compressing the requirements allow communicating large amounts of information without restricting too much what programmers are allowed to do.