In my last blog post about using visual software requirements models to inform my home buying experience, I laid out my business reasons for wanting to own a home (in the Business Objectives Model), my desired features in the dream home (in the Feature Tree), and how I was going to measure houses against each other (in the Objective Chains).

Business Analyst Tip: For a downloadable Zipped file of models templates, see our website here:
RML® Visual Software Requirements Models.

In applying visual models for software requirements to a real-life experience, I learned a lot about the value of these models. Using models helped clarify the many lessons learned about the home buying experience; that’s my main reason for writing this retrospective blog post. While I know it won’t apply to all our business analyst readers, I hope this helps some other business analysts and their families!

Since my last post, I have been in touch with a realtor, looked at various houses, made and negotiated an offer and am now under contract, pending closing.

I must say it all went much faster than I thought it would, but having the visual software requirements models to help inform my husband’s and my decisions really helped.

For one thing, we knew what we wanted in a home and how much we were willing to pay for it. This helped us nix houses that would need too much renovation or didn’t have the features we wanted. It also helped us know when to jump on a house that did meet our requirements.

Here are some of my lessons learned:

1. I found that there was really no one place where you could find all you needed to know on the home buying process, including information about realtor’s roles, how to negotiate offers, apply for mortgages, etc.
2. I found that banks want a lot of documentation to give you a mortgage, which I am sure is an effect of the housing bust and the recession; however, I was not prepared for the sheer amount of information about ourselves that we would need to hand over.
3. Lastly, I learned how many things have to go just right in order for a home sale to occur – not only do the buyer and the seller have to agree on the cost of the house, but also on any repairs from the inspection, and possibly about lowering prices if the appraisal for the house comes back low.

I tried to take everything I learned and display that information in requirements model form for any business analysts who are first-time home buyers who may come after me and want an easy to understand first stop in their own process. For the purposes of keeping this post (and the second part) to a reasonable length, there were many visual models I didn’t make about specific banking models or how your information is used to inform lending. Hopefully the visual software requirements models below are still useful!

Before reading further, note that I’m referencing chapters in Joy Beatty and Anthony Chen’s Visual Models for Software Requirements – you can find it on Amazon here.

I started with an Org Chart – because when we started, my husband and I weren’t really sure who communicated with whom and what communication went on. The Org Chart shown below is kind of a cross between an Org Chart (Chapter 8 of Visual Models for Software Requirements) and an Ecosystem Map (Chapter 12 of Visual Models) if you consider each person as his own system.

I say this because it doesn’t have the hierarchical order than an Org Chart does but shows the same basic relationships – and thus it may be a useful software requirements model, not just a “life hack” model. If you are the home buyer, most of your communication will be through your realtor or buyer’s agent. He/She will speak to the Seller’s agent about contracts, offers, viewing the houses, etc. The seller’s agent will then talk to the owner. Once you are under contract, the Title Company, who usually acts as the escrow agent, comes into play and can basically talk to anyone. They run the title checks on the house for any liens or deed restrictions. They also run everything on the day of closing. Finally, you will likely be in touch with some sort of 3^rd party lender, probably a bank to secure a mortgage.

Next, I decided to try to use a Process Flow (Chapter 9 of Visual Models for Software Requirements) to document my experience of the entire home buying process end-to-end. Usually you would start with an L1 Process Flow to show all the steps together and work your way down to L2 and L3 flows. However, to save space in this post, I decided to try to cover everything at one level, probably the L2 level.

You can see that Process Flow model below (click on the image to enlarge).

It starts with the home-buyer deciding to buy a house for whatever reason and contacting a realtor. The buyer then look for houses online through MLS and determines what the features and/or requirements in the house are. When the buyer has those (see the Feature Tree from the last post), they can create a checklist and are ready to visit houses.

If you’re the buyer, you go look at houses and evaluate them with your checklist, and as you can see in the Process Flow, you continue looking at houses and comparing them until you find one that meets your requirements and then you make an offer on the house.

From there, you can negotiate with the sellers on the price, the option period (that period in which you can withdraw your offer for any reason and basically get a full refund, minus the option fee), and many other things in the contract. If you can reach an agreement, you are then under contract, and the option period begins. During the option period, you arrange for the inspection of the house/property. If the inspector brings up any major repairs or things you want done before closing, you go back to negotiating with the sellers. If that negotiation works out, you move on to funding; if not, you go back to looking for houses.

For this post, I’ll leave it at that. In the next installment of my retrospective, I’ll go over obtaining bank funding as well as one final look at the overall process and the things I learned along the way!