What SHOULD Software Engineer ask their client?

In many companies dedicated System Analysts or even Business Analysts are relics of the past. Responsibility for analysing system and business requirements lies on Product Manager and Software Engineers themselves. Not every PM or SE deeply understands the business. Software Engineers sometimes miss soft and communication skills and even with best intentions in mind they cannot clearly communicate with business stakeholders. In previous articles I mentioned System Thinking as way to understand our organization and our clients. In order to deeply understand the business we need to extract knowledge from out business stakeholders.

Let’s see if we can build a checklist of predefined questions we can use to start conversation about business features.

Before the meeting – preparation

Before you can count anything you’ve got to know something.

According to Gerald M. Weinberg this is one of the most general of the systems principles. To rephrase that: we should know how to distinct one thing from another and only then, we can count what interests us. This concludes to the first step:

1. Focus on main topic. Bound context of your conversation to lower the cognitive load. Try to differentiate things that the feature is composed of.

Things are the way they are because they got that way.

Be productive.

In Poland we have following expression: Panie, kto to panu tak sierdolił?*

Translation would be: Mister, who fcked this thing up?*

There is a great chance that you will be modifying existing system. Applying new feature may be easy or hard – it depends on previous implementation. When it potentially be hard, keep your criticism and opinions to yourself. Probably you don’t have bigger picture and you don’t know previous constraints, architectural drivers etc. It leads us to another point:

1. Study and listen for understanding. Do not judge. Look for what is the business question that current system answers. Focus on positive outcomes when using existing system.

When you will be adding features to existing system it may be easy to fall into “there is no need to do that” trap. Of course this feature may be unnecessary or simply bad, but we should not jump into premature conclusions. If we think that we do not need to work on that we should prove it.

1. We are not released form the liability to work with our business stakeholders.

How to build proper questions

With proper attitude we can start our meeting with business stakeholders. Let’s use Gerald Weinberg’s approach to form proper question. In his book Weinberg mentions meta-questions and self-validating questions.

Meta-questions

Meta-question is a question that directly or indirectly produces question as an answer.

What do you think I should be asking you right now?

Question above is simple, understandable by anyone and answer to it may give us a very valuable insight about a process. It’s great question when we stuck during an interview or simply do not know how to start.

Self-validating questions

Self-validating question borrows from technique in information theory called: error detection and correction. The idea is that our conversation with business stakeholders is full of noise the same way as transmission from the transmitter to the receiver. Our role is to detect errors and reconstruct original information given to us by business stakeholder. When we ask the question every reply is composed of three parts:

reply = information + validation + noise

The main idea is to form the question in a way that we will be able to easily extract information and check if we were understood. That is where validation comes. We want as little ambiguities in our conversation as possible. Imagine following example. We’re building a system that help to processes geospatial data. We need to define how much of the area are we going to scan and preprocess.

Question: What is the size of the area we will be scanning today?

Answer: Fifty.

Fifty of what? Squared meters or squared miles? Client didn’t understand what we meant and answered what he/she had in mind. Ask precise questions, but not too precise. Give your business client a little space to fill answer with natural noise.

There is another aspect to conversation with client: build engagement and discussion. Frame your questions with words like: how, what, which instead of will be, is. We want to avoid binary answers that gives us no validation part. We want to bring our clients to discussion and let them participate in solution design. Also you will be seen as person who shows interest and learning as much as possible about business domain.

Questions to discuss

When we ask questions we want to get information from the person we’re asking. As Software Engineers we need to build system that helps to solve business problem. There probably will be a lot of questions specific to given domain. However, armed with knowledge we can build some generic questions that will be great starting point.

Disclaimer: I will use concept of event as business change in the system.

We can start with meta question like:

1. What business questions our system needs to answer?

Our system must satisfy business requirements. Those requirements can be decomposed to rules and behaviours. So what are they?

1. Which events influence our system?
2. What is the reason of reacting to this exact event?
3. How often does this exact event occur?

All changes that happen in the system have some direct or indirect consequences. What are they?

1. What are the expected outcomes of the reacting to this exact event?
2. What events are reversible?

Business flow may be complex and long lasting. Our context needs to communicate with other business context. The boundary between those contexts becomes more and more blurry and we cannot distinct one form another. Where is this boundary? Sometimes objects and concepts from one context affects other one.

1. How things and concepts in our context become other concepts?

With these set of predefined questions we may start meeting with our clients. Let’s summarize.

Conclusion

Business meetings can be either productive or not productive. They are exhausting for both business stakeholders as well as Software Engineers. We can do our best to make them more productive by asking proper questions. How?

1. Focus on the main topic.
2. Leave your ego in another room.
3. Use open questions and give your business stakeholders space to express requirements.
4. Identify rules and behaviours and build questions around them.

You can use checklist down below when preparing to the meeting. As everything, this list may evolve into something new. Do not hesitate to build your own!

Download:

Resources

1. Rethinking Systems Analysis and Design, Gerald M. Weinberg https://www.amazon.com/Rethinking-Systems-Analysis-Design-Weinberg/dp/0932633080 buy used. Let’s give books a second life.
2. Error detection and correction, Wikipedia https://en.wikipedia.org/wiki/Error_detection_and_correction