Nokia Process Guidelines


This post is mainly for the many startup companies who come to me with vague ideas for mobile applications. They usually want to know two things – is the application possible and how much will it cost. While I can provide ‘ball park’ answers, the ‘devil is in the detail’ and it’s often necessary to dig a lot deeper which costs time and money.

So how should be these people be approaching me? Nokia has just published some guidelines…

Use Case Creation Guideline

Requirement Creation Guideline

Development and Quality Assurance Process Guideline v1.1

These documents are a goldmine for the wannabee entrepreneur. In particular, I would look at the use case document. If you can describe your application in terms of use cases then you will have a much more successful time talking to potential mobile developers (and investors!).


It’s also important not to go over the top documenting everything. Ideas change so err on the side of minimalism to avoid wasted effort.

If you want to go further, you should look at Agile Software Development which has User Stories which are similar to use cases. I personally slightly prefer use cases as they are less ambiguous and tend to map easier onto code. Incidentally, Agile development is particularly suited to mobile development because the limitations of particular platforms, devices, connections, UIs and APIs all conspire to change your project over time. However, be careful and don’t over-do it. The degree of Agile development should depend on the size of the project, the size and experience of the team and the company culture.

As an example, when I have worked with (usually large) companies that sadly still use waterfall development processes I have tried my best to turn the project into uses cases/stories and a series of phased deliveries with self testing rather than relying on a large big bang approach at the end of the project.

A final tip is to implement your riskiest use cases/stories first. Unfortunately, only experience can tell you which these might be. Also aim to get a thin slice through the whole system. In this way you will get an early appreciation of the problems and the timescales after which you can re-plan and prioritise accordingly.