Offshore Development Challenges : Requirements

Anyone who has done a reasonable amount of development will tell you that in order for a project to succeed getting the requirements right is the most important ingredient of the success. Communicating a requirement is another challenge due to the fact that along with the idea the intent should also be conveyed and doing this over a non visual communication medium over thousands of miles can be a challenge.

Good requirements development is even more crucial in an off-shore project due to the following reasons

1. When the requirement is not clear valuable time can be lost as the clarifications can take time due to the time difference.
2. Subject matter experts may not be available in the offshore team so the SMEs in the on site team have to explicitly explain each and everything - otherwise the development may not be done keeping the context of usage in mind.
3. The on site team will not be able to see anything till the development is complete or at least a fair bit is done and this may be too costly a time to suggest changes. So if the requirements are explicit and clear then these changes can be minimized.
4. The people developing the project may not be on the same wavelength as the ones that have conceived the project and this may not become apparent till quite late in the project.

In order to minimize the risk of the project failing due to bad requirements development the following details and actions need to be part of requirements development process

Understand the business and application being built
- Ask a lot of questions. Do not be afraid of asking questions.
- Clarify any ambiguity in the answers given. The ambiguity of the answer many a time arises from the on site SME assuming certain level of knowledge. So the clarity of what needs to be done needs to be achieved.
- Assumptions to be documented
- Do not assume things about the business when in doubt ask.
- Do not assume things about what the client may want. The client knows what they want so ask them about it.
- Do not try to think for the client unless explicitly asked to do so. And if you are suggesting something make sure the client is aware that it is only a suggestion.
- Do not try to think for the client unless the client wants it.

Do not assume any technical details
At this point get the development team involved in some questions. The reason you need to ask these questions is because the way the design has to be may put restrictions on how the User Interface can be designed. You do not want to design a User Interface that cannot be implemented.
- Clarify about windows based or web based
- Preferred programming language to be used
- Is there any design that the client already has in mind or is defined
- Existing systems in use and how the application being built interacts with these systems
- Preferred Database
- Requirements pertaining to the response time of the application, number of potential users of the application, acceptable downtime and so on
- Clarify the number of languages that the tool will need to work in
- Clarify on the date and time format that is to be used
- Understand the customizable portions of the data and the values that can be hard coded into the code

Define a scope for the application and stick to it
Defining a boundary for what one is building is the best way to ensure success and this is called the scope of the project. The scope of the project should be logical and building something tangible out of it should be possible.
- Do not put anything more than what is needed for the application to work
- Make the client aware of when the scope is changing
- Do not try to impress the client by adding something that is out of the scope of the project

Do not try to build what is not asked
- Stick to the specification and any clarifications got from the specifications

Ensure a clean flow of the application
- Create scenarios where you put yourself in the shoes of the client and use the prototype

A process that works very well is

• Detailed discussions of what needs to be built. Also ask for any documentation or reference material.
• Build a prototype using a tool such as Axure and ensure that you put all the information that you have into the specification in the tool either at the page level or at the field level.
• Use online collaboration tools such as Webex to demo the prototype to the client/on site team to ensure the understanding is correct.
• Refine and repeat demonstrations of the prototype till the clarity is achieved.