Let's imagine this scenario together: the love of your life has just gotten down on one knee and has asked the penultimate question - Will you marry me? Will you grow old and tired with me? Will you mix your underwear with my underwear for the rest of our lives?
And obviously you say yes! You pop some champagne, call your parents, and post on social media that you're tying the knot. And now, you're in planning mode for an extremely fun (and most likely expensive) party to celebrate your love with your closet friends (assuming it's not 2020 and COVID is gone).
Now this may be your first time planning a wedding, so what do you think you would normally do to start? Check out venues on The Knot? Figure out a wedding date? Plan an engagement party? All signs point to yes, but most likely you would start with some good old fashioned research. You would figure out everything that you would need to plan leading up to your big day, potentially create a checklist, identify people that you need to work with to make it a reality, and prioritize what things need to be done first.
This example is a fun way explain what domain analysis is. In the software development industry, domain analysis is the process where you try to learn background information about your domain or field that your customers or users are using your technology. Domains may be extremely broad like "wedding planning," or "financial planning," or "hospital management;" domains can also be super specific like "RSVP scheduling."
If you are performing domain analysis, then you are essentially trying to become an expert in that field. You are doing this by gathering as much information as possible from whatever sources you can find. That could include research from books or the web, to interviewing people, to actually walking through your product to understand how it works today. By becoming a domain expert, you have a clearer understanding about your field (and your product) and when solving for a problem or developing a new piece of functionality to support a process, the thought is that you'd be able to more quickly identify the needs of your customers, write more succinct requirements, and ultimately churn out faster results through your software development.
Let's go back to this wedding planning scenario now - let's say you have created a checklist now and you feel very confident about what you need to do for your big day. Fast forward one year later; you have selected a venue with a date, a caterer, an officiant, identified a guest list, and sent out invitations. You are coming up on your due date to finalize the number of guests you are having for your celebration, but you have noticed that only 40 people out of the 100 invitations you sent have responded. This is quite a problem, and you're not sure what to do!
When you identify a problem in software engineering, you would then perform problem analysis. This is the process where you investigate why a problem has occurred. It could be an incident or failure of a process with your technology, and also is done to identify potential improvements to your system or procedures that occur with your system. In this wedding planning scenario, you would try to understand why you're missing so many RSVPs. You would do that most likely through root cause analysis, which is the act of understanding the reason behind a problematic symptom. Software analysts will often ask the question of why several times to find the root of a problem, and then determine if the ultimate problem is a people, process, or technology problem.
When identifying a problem, you would use any resources you could to explore and define. That could include interviewing people, reviewing documentation, or even walking through a particular scenario to see how your software reacts (think of that like a cause/effect scenario. If I do this to the software, then the software responds how?) In our example of missing RSVPs, you would most likely call up your friends and family members that have not responded and determine why they haven't. In interviewing them, you've come to find out that they never received an invitation. You could even do some further investigation to find out if the invites ever left the post office, but ultimately your root cause has been found!
So where do you go from here? Well, you have a problem...so obviously you want to find a solution! That's where solution analysis comes in. This is the process where where you take the problem you've identified plus the information you've gathered in your domain analysis to define a solution. In software development, that often focuses on building a structure and features of a solution to be built, which becomes functional requirements and then eventually code! As an analyst, you would seek to collaborate with your technical subject matter experts and your business users to define your solution, and then document your requirements in the correct structure. Sound easy right? :)
In our example, you would problem seek a new way to get out your RSVPs. You could obviously try sending them again in the mail, but maybe instead of risking the same outcome as before you decide to use a RSVP management tool that already exists (or if you're feeling really fancy, you make your own!). For example, you might try out a tool where you can create your invites virtually and send them out through email instead of mail (like Evite! No they did not pay me to promote them btw. I just love Evite!).
What's important to remember is that there are usually multiple options for a solution, but in order to decide what is the best solution to enact, you need to understand your problem. That's why understanding your problem at hand the best that you can is so important, and it doubles down with understanding the industry (or domain) that you're in. If you can understand your landscape and the troubles at hand, then you're set up for success ultimately down the road.