Before you build a complex system — it is best to ensure the task is understood well. It is better than having to redo it later. For this we use a number of techniques, from early prototyping to detailed specifications with screen designs and algorithm descriptions.

Key problem here is that the customer doesn’t always know the details of your system or implementation nuances. Yet they have an understanding of the problem that needs solving (and there is a problem, as otherwise there wouldn’t be a budget to solve it, right?), and it is our task to understand it and find a good solution for it. This is where requirement analysis steps in.

The result of requirement analysis is a set of specification documents, which are clear enough for the customer (often not very technical) to approve), but also detailed enough for the developers and QA to understand what is required and how it should work.

Not all technical decisions are described or even made at the requirements stage, to give the engineers enough freedom to implement the best solution. Yet our aim is, whenever it is possible, to decide on screen (UI) designs and main algorithms prior to work has started — this allows us to involve the client in the design process (always a good tactic!), and to be more confident that what the team is about to implement will actually solve the problem.

For UI decisions we use mockup tools (for example, Balsamiq Mockups, or MS Excel). If interaction is a key part of the design, we sometimes prototype a screen or particular UI element using HTML5 (involving JavaScript and CSS). This also helps with early research on whether a particular interaction concept is easy to implement or not.

For algorithm descriptions we use text, diagrams or prototyping with Excel formulas. The latter is helpful since it usually allows the client to test the algorithm’s feedback with various input data, and also helps the developers to implement this algorithm, as it includes the key formulas functioning in the descriptions.

For more complex features it is also vital to include QA in the requirement analysis process — building a set of testing scenarios greatly helps in understanding different aspects of the problem.

Analysing and describing requirements is the first step in ensuring reliable communication with the customer, and thus lays solid foundation for providing appropriate high-quality solution at the end of our work. This is the reason that we put special emphasis on doing this part right. We’ll describe further steps in later entries.