Requirements - Problem Discovery

When Eliciting requirements, these are question I usually raise independently on the domain:

• Why It is a Problems for you?
• Why do you need this?
• Why It needs to be different?

I believe the answers are crucial for the requirement analysis. They basically will show the customer's real needs, their business problems. Detail requirements from this point is supposed to be safer and we'll see why.

What is a Business Problem?

A problem on this context is something that does not let business goes forward as it needs. You can think on it as the reason why you (Software Engineer) was called. A Problem is usually characterised as something that involves money somehow. When talking with business people about some problem, try to get from him how the problem (usually mentioned as a business need) he is talking about makes his company loose money.

Why Identify Problems is Important?

As a Software Engineer, have you received a complied requirements list ready to be implemented? If your answer is yes, how were you sure these requirements are really the ones your customer is waiting for? If you manage to correlate requirements to business problems to be solved, you'll  be able to have this answer. By doing that,  you avoid resources to be wasted by implementing features that are not valuable to business. 

Spreading this mindset to the whole tech team is also valuable due several reasons:

• Team can prioritise refactorings and design efforts on parts of the systems that will really makes the difference.
• The feeling that the team is building something really valuable.
• Team is able to understand what makes business slow down, then create solutions that properly  address these issues.

How to Identify Business Problems?

Looking for business problems when eliciting requirements may seem too vague, a good tip here is look for problems that make the company loose money directly or indirectly. Business people usually report them as ".. this process it taking too long .. " or ".. Because it is too complex and involves too many people be coordinated..", etc. Even not mentioning the word "money" explicitly, they are talking about time, resources, etc. 

Achieve this point may be tricky and will demand you some experience on the field depending the domain you are. BTW, a technique is which is helpful is here to use Business Objective Models. It helps to identify business problems  and objectives. Going through this process, you will also be able to have a set of high level features that the final solution will need to provide. 

Even looking obvious, there are projects where this process is just ignored.  By doing that, people are assuming the risk to be working on requirements that doesn't bring the value business is expecting.  Be suspicious when your customer came to saying: "My solution needs to do this and that...". You are may running in this scenario.

By doing the Problem Discovery approach, it is gonna be also easier to have everyone on the same page (business and tech team) on which regards where the efforts needs to be applied, once the objectives are clear to everybody.

It also works well with the Iterative approach. You'll may have a chance to work with your customer showing him business problems that even him isn't not aware of.

Requirements Discovery - The Iterative approach.

Requirement Analysis is crucial part of development of any kind of system. This is the point where Engineers start shape the solution that  is gonna be built. During this phase, they also need to consider constraints that each particular project will demand (i.e cost, risk, time,quality, schedule, etc).On  the Requirement Analysis, business and IT people start get on the same page in which regards the problems that need to be addressed.
Without a proper Requirement Analysis, certain solutions are almost impossible to be built. There are some problems that are too complex to be solved without a proper understanding. It does not means Engineers will need to spend the whole budget available just be on the same than business. Here is where the agile mindsets and the lean principles came into the show. Ok, So far, so good, but why are we still seeing problems like misunderstanding on projects where there is time and space for Requirement Analysis? There can be plenty of reasons, Each project has It's own context with different problems, but I'll talk more about one I've seen several times in different projects. As  Engineers, we frequently fail to help business, go through the right direction.
I've seen quite often on projects of any size.  You may have experienced it already in case you are able to answer some of following questions:

• As a software Engineer, have you received a list of requirements to be addressed and schedule already defined? 
• Did someone get any input from the final user who is gonna be using the system?
• Have someone thought  how complex is the architecture that needs to be built in order to attend the requirements?
• What about some business concepts  that are still hidden on this requirements list that we may realise only few months after the project is already started?

All the aspects that involve the previous questions are the people usually ignore. Basically answering these questions will lead you to the symptoms the problem. Even in projects where people say they are agile, they are not free from situation. The issue to be solved here is not the methodology but involves approach and trust.

The Iterative Approach

In order to help business to find out the right requirements, the first step is to be more involved on the Requirements Elicitation process. The Iterative approach suggests this phase happens by constantly getting feedback from business. There are two main advantages by following this approach to Elicit requirements:

• Engineers and Business people on the same page: By Applying series Engineering techniques, we can help business to find out the right requirements to solve the problem they have. Engineers and business tend to be on the same page once they get constant feedback from each other in which regards the how problems  will be addressed and  technical challenges around them.
• Just enough analysis - As far it is a iterative process, business can see the list of requirements as they are being formed and they understand the challenges around them. They can decide the the right time stop and go forward with the release. On this way, you wont spend the whole budget available on the requirement analysis.
• Looking for the right Architecture  - Make business understand the challenges sometimes pass through making proves that the architecture chosen will work as expected. By doing POCs, you can get these answers before making calls that will involve more money and risk.

The Iterative approach can actually be something continuous. It means the process can be repeated as soon you reach the Implementation phase. It also means you can go back to the modelling step once the result from the POCs does not attend the expectations. This approach works pretty well on cases where teams are looking for a MVP, for instance. It also means the cycle can restart as soon you  reach the implementation phase.(i.e plan the next release).

In order to make this approach works, collaboration is mandatory. Engineers needs to get feedback from people that fully understand the business and the problems they are trying to solve, otherwise the chances of wasting resources and time building a solution that wont attend the business expectations is high.