Choosing the Right Software: 3 Tools for Getting it Right the First Time

By Brian Gannon, Technical Relationship Manager on Thursday, July 28th, 2011

Way back when, in the early 2000’s, my roommate Joe and I would often find ourselves watching “Leave it to Beaver” on Saturday mornings. One of our favorite scenes was one where Beaver was choosing a book for his book report from Ward’s library. Beaver pulls out a book and hands it to Ward for the requisite parental approval. Ward is puzzled by his choice and says to Beaver, “’A History of Mexico… why did you choose this book Beaver?” Beaver responds enthusiastically, “I chose it on account of its neat green cover!” And then Ward, in his perfectly sardonic father-knows -best tone: “No Beaver, no. That book is not for you.” You can almost hear him saying “No Beaver, that is a terrible idea”, which is why we found it so humorous. Ward then chooses The Three Musketeers for Beaver, and yet another Cleaver household catastrophe is narrowly averted. (Well, not really, because then Beaver watches the Three Musketeers movie instead and gets in big trouble.)

The important take-away from the Beaver story, as is the case with most stories involving the Beaver, is to not be like Beaver. Be like WardIn the case of selecting a new software solution for your business, that means having a clear, well-defined, and documented idea of what problems the solution needs to solve and what key characteristics it ought to have. Now this doesn’t mean that a huge tome has to be written. That would largely defeat the purpose. It simply means creating a few lightweight documents that confirm understanding within your team of what is needed, which can then also double for communicating the same to prospective vendors. Here are a few examples of what form those documents might take:

Business Requirements Document

In its simplest form, a business requirements document (BRD) is a short summary of the problem and a list, often in the form of a table, which enumerates the capabilities that a solution should have. They are often rated in terms of necessity – “must have”, “nice to have”, and “wish list” are common classifications. When completed, a BRD can be used as an RFI/RFP-type document to share with prospective providers, allowing them the opportunity to illustrate for you via a written response, demonstration, or both, how their solution meets your stated requirements.

Use Cases

The potential downside with traditional business requirements alone is that it is often easier said than done to sit down and create a list of “the solution needs to do X” type statements. That’s because such an exercise doesn’t reflect how systems are used in the real world. In the real world, features aren’t used in isolation, but rather in concert to achieve desired user goals. In other words, a washing machine doesn’t have a buzzer because it needs to buzz. It has a buzzer because the user wishes to know when the cycle is done while doing something else.

With this understanding in mind, the concept of a “use case” was formalized by the software development community in the mid-1980’s. Use cases are stories. They tell the tale of how a user achieves a goal. For our purposes, a use case is a great way to identify what those aforementioned “the solution needs to do X” statements ought to be, and can be included in a BRD. As far as format is concerned, a use case can be expressed as steps (step 1, step 2, etc.), or as a couple of paragraphs. Whatever the format, a use case has a few basic ingredients:

  • A title that starts with a verb – i.e., “Calculate Management Fees”

  • A primary actor – i.e., “Operations manager”

  • A main success scenario – i.e., “Each account’s management fee is transmitted to the custodian” which is described over a series of steps or a few paragraphs

There is one particularly important guideline to follow when it comes to use cases and business requirements: focus on what a new system needs to do, rather than how it needs to do it.   This means using statements such as “The system indicates any fees which are a specified percentage higher or lower than the previous period’s fee”, rather than “The system displays an Excel report where large increases and decreases are highlighted in yellow”. Don’t get caught up in the how…that’s what a solution vendor is there to help with.

Domain models

 A domain model is a simple thing with a complicated sounding name. A domain model is just a picture. It is a picture of the conceptual “things” related to the problem that needs solving and how those things relate to each other. In the realm of client relationship management for example, your firm may use the term client. That would be a box in your picture. A client may belong to a professional association. That would be another box, and you would draw an arrow from the client box to the association box and label the arrow with “may belong to”. Your client may be one of a few different kinds…one may be a high net worth individual while another is a small business. Those would be two more boxes with arrows going to client. You get the idea.

A domain model is a great thing to create during a small brainstorming session with your internal team, before talking to any potential solution providers. It forces you to get on the same page about what’s what, and quickly brings to light any misunderstandings about what the different entities are and what they mean. And when you are done, you have a very handy piece of documentation to share with a prospective vendor. A domain model proves that a picture really is worth a thousand words.

There are of course generally accepted guidelines for creating each of the items described above. You can learn more by looking up the terms “business requirements”, “use case”, and “domain model” on Wikipedia, or by just Googling them. But the good news is that you don’t need to worry about getting whatever you do “correct”. Just by going through the exercise of creating a few documents to help define the problem and what a solution might entail, you are way ahead of the game already.   You now have a few things to share with potential vendors, and time previously spent on explaining your particular situation can instead be spent on their answer to, “How can you help me do this?” So don’t be like Beaver, and go with the first flashy thing that catches your eye. Be like Ward, who knows what he is looking for before he starts searching for it.

You Might Also Be Interested In:

comments powered by Disqus