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.

Being Explicit

Be explicit on what you mean can sometimes save from headaches and troubles. If you go to a restaurant, and there things you don't like to eat, you need to make it explicit to the Waiter (specially if you are allergic, which is my case), before ordering a dish. If you manage to make it right, your dish will be as you wish. Notice that to be successful here, you needed to be explicit with the Waiter, otherwise he wouldn't get your right,
Ok, lets see now hot  all these is relates with software development. Lets start with a couple of questions:

• Have you already, debugged an API or any software unit in order to realise what it does? 
• Have you spend hours using the approach "try and fail" to be sure about the side effects of a design change? 
• Have you looked to a method/function/procedure that returns nothing, receives no parameters and throws meaningless exception?

If you said yes for any of these questions, then you have already dealt with a design that is not explicit enough about its intentions. On those scenarios, we are not able to be sure about the consequences of changes on the design or even be 100% sure about what expect from there, at least not easily. This is a problem I've seen quite often in some systems, and there are some variables that can make the scenario a bit more complex:

• New people joining on the team.
• Lack of tests
• No "useful" documentation.

What means be Explicit?

First of all, lets look for a definition of the word explicit:

• Fully and clearly expressed; leaving nothing implied. Meaningful
• stated clearly and in detail, leaving no room for confusion or doubt. Fully Understanding.
•  Fully and clearly defined or formulated: "generalizations that are powerful, precise, and explicit" (Frederick Turner)

Meaning and understanding are the key things here and that is why they are highlighted. A software unit is explicit enough when we make the right assumptions about what it does without go into details about how it does and also having full controls over its side effects. A whole design is explicit enough when we are able to recognise the right concepts/abstraction and be able to predict what is their behaviour when working together.

How to get there?

Here are some tips I use to make my designs more explicit:

• Look for deep understanding on the domain - This a a pre-requisite to all items that are gonna follow. In order to find out the right abstractions, you need to understand the rules, see the entities, recognise its behaviour, the boundaries, etc. Everything starts from here. If you don't find the right abstractions, something will be missing in your design and the chances to achieve explicit will be smaller. This knowledge usually comes with time but as soon you get there, the explicit we are talking about Will emerge.
• Minimise the side effects - side effects are hard to make explicit. When trying to make them explicit we usually end up with a complicated and unclear solution (i.e, checked exceptions, sharing state). On the other hand, hide it totally sounds unnatural  couse it will hard to predict them when using the system. If you can't get right of them, try to minimise shared state internally and use other software design techniques to deal with failures on the right place.
• Create meaningful interfaces - In the end of the day,  we  expose APIs and functionalities through interfaces. Interfaces need to be clear enough about what they are suppose to do when used. It pass through finding the right abstractions giving to it the right names.

Be explicit is a matter of being honest about what are the intentions (Intention reve of your design. It is  It does not mean an implementation should reveal all its internal details but instead,  providing the necessary information to the that are interested use it safely, without misunderstanding.

Building Changeable Software - The new Bridge Metaphor

In a Software Engineer daily job, there are several situations where a complete redesign needs to take place in order to make things work as they ideally need. The reasons to that happen (sometimes often than we'd like to see) can be many. I'll try to list some of them, but i can be missing some:

• As developers we make mistakes - this one is obvious, knowledge about the domain  will come with time, the same is also valid for engineering techniques and principles. Until there we are gonna make mistakes and lack of  Code Review and design sessions  can just potentialize it.
• Pressure to deliver - there are scenarios where we just need make things as faster as we can. Issues in Production that affecting the user experience can be damaging to business. So on this scenarios there is few space to huge refactorings  and redesigns and that is reasonable. The problem start when people start use this excuse to put pressure on anything we do, even it is not Production specific.
• Fear to touch on production code - lack of test coverage can make it worst.
• A mix between all them.

Understand the reasons why it happens and learn how deal with them is important for a Software Engineer also. Given the frequency it is scenario is presented to us, know how to deal it sometimes is the key in order to start introduce changes.

The new Bridge Metaphor

Let's say there is a bridge over a river. It lets people go here and there with their cars, but it is becoming too old. It's maintenance is becoming expansive and it is no long supporting the traffic volume. A new solutions needs to take place, otherwise users will suffer on the next years with the problems the current bridge is gonna present.
Ok, what about rebuild the current bridge in order to attend the new demands? The idea looks promising in terms of costs, but in the end of the day, it'll represent the bridge unusable during days or even weeks, which is unacceptable. Does not matter what happens, people needs to be able to keep using it.
Well, what could be done then? An alternative is keep the old bridge working and build a new one. At some point, when the new bridge is ready, the whole traffic can be switched to the new and fresh bridge disabling the old one.
Even more expansive, this is the most feasible thing that can be done once the other approach would bring several headaches to the users

Ok, but what it is the relationship with software development? I'd say it is all.
Business needs to keep moving, most part of the time there isn't much space to stop deliver functionality to make big redesigns. Try to sell this approach to business usually does not work. Moving things little by little is much easier to sell once it can be conciliated with functionality being delivered to production. This is like keep the old bridge working while new one is being  built, as far you can see on the picture.

As a Software  Engineer, I usually spend most part of my time maintaining software rather than working on green field projects  On such scenarios i have been following this approach in order to delivery good software and keep things moving. It also fits pretty well when dealing with legacy software.
The downside when following this metaphor is that at some point you will need to accept some code replication and some "ifs" on the code being delivered while the new bridge isn't done.