Analyzing Customer’s Requirements

Analyzing Customer’s Requirements

Every project owner wants to be understood. The need to be understood is even greater when the project owner has a unique, non-typical project which requires custom development. Knowing that understanding is essential, we pay special attention to customer's requirements getting deep into their short-term and long-term goals.

Engineer of a special kind

An ability to perform requirements analysis in software development assumes that the engineer who makes the analysis: a) understands the client on a personal level, b) knows how their business works and c) has advanced communication skills.

Usually, most of senior-level engineers acquire those skills as their experience grows. However, not all senior developers outstep the level of technical tasks. At the same time, there are many less experienced engineers who learn to see big picture and judge from the business perspective early. This often happens when they specialize in communication with customers - as when they are rollout engineers, project managers or so called knowledge engineers who are specialists in building expert systems.

This way, a good collaboration with a client calls for an engineer with skills that go beyond the remit of technical stuff.

Managing over technical

The paragraphs below are my insight of how good rollout engineers work when they deal with a new project.

They identify 1 or 2 core project features that determine the market value of the application. The same way they can detect main features of existing (competitive) products that function in the market.

While doing that, they refer to industry-specific terms and concepts because they know the industry and know how different aspects influence the business. For example, rollout engineers know what MLS means to real-estate agents, or what UB-04 form means to US Healthcare industry, and so on.

Since I mentioned the UB-04 claim form, it is worth mentioning that rollout engineers can "read" forms, questionnaires, regimented documents, etc. and "extract" workflows from them. If they assess a business management system, the first thing they ask the client is if there are some sheets and forms used in everyday procedures.

Rollout engineers prefer manual solutions over automated solutions except for the situation when automation is the main purpose of the project. They "compress" the requirements in their mind if the requirements are too big to fit in one release because they always try to reach simplicity and get maximum business value for small initial investment exactly as the agile approach recommends.

Qualitative over quantitative

When preparing estimation of a new project, they prefer qualitative measures over quantitative measures and refrain from strict numbers knowing that numbers are always misleading. Their estimation looks like a project overview rather than a table. This overview outlines client's main objectives and contains high-level questions such as 'Who is your target audience?', 'Where will your referrals come from?', 'How quickly should new listings appear in search results?' and so on.

When asked to provide a breakdown, rollout engineers aim at splitting the project into releases rather than into user stories. This way they achieve a more goal-oriented picture which can be discussed in the client's language.

Certainly, they are always open to a dialogue with the project owner. Due to their advanced communication skills, they can express their ideas, listen to the client and adjust the plan. Unlike rollout engineers, "technical" developers - even very seasoned ones - prefer to focus on their current tasks and rely on the customer for strategy and goals.

Flexible over sustainable

It is no secret that an ideal plan is not always achievable. Requirements are rarely stable, project owners may insist on their strategy deviating from principles of simplicity. In such a complicated environment, communication issues can be resolved only by skilled communicators who have to be flexible.

So, flexibility is another quality of rollout engineers that helps them understand their clients. Here is how it works.

There is a sophisticated analysis called "knowledge extraction". When the client is a field expert, he has been around his industry for dozens of years. When he starts talking with engineers, he simply does not realize that things he is accustomed to are not that obvious to his conversational partners. So, he usually focuses on the main subject and leaves "minor" details out of the equation.

A knowledge engineer should literally extract the required information from the expert. A seasoned engineer can do it having a minimal number of discussions.

Many clients welcome software developers to ask questions - and so the developers do. However, the difference between an amateur developer and an experienced professional is that the latter asks the right questions based on the situation and business workflow.

Communication over all

There are some other features that are inherent to rollout engineers.

They can deliver the extracted knowledge to other engineers. In other words, they can write user stories in the way the stories will be clear to a new project participant almost without explanations.

They can catch and start using a new terminology, but they never return the client his sentences without rewording them - otherwise the client would not be able to determine if he was understood at all.

They know aspects of rolling out business solutions that require special management on the side of the project owner. For example, they know how the network effect affects the business and how to overcome it.

They often receive a feedback from the client that says something like 'You raised a good question', or 'Your statement about … is right to the point'.


Every specialization has its upsides and downsides, the requirements analysis in programming is no exception. Engineers who have great technical skills are not always as experienced in analyzing customer's requirements and vice versa. An average custom project requires both types of engineers - this is what we call "a balanced team". At the initial stage it definitely requires someone who understands the project owner. In his turn, the project owner usually wants to talk with someone who speaks his language, understands the terminology and can see the big picture.

If you are a project owner, make sure that your development camp has a good communicator - either a rollout engineer or a project manager - with appropriate experience who knows your objectives and shares your vision. Such a person in the development camp will save you a lot of time and help you reach your goals.