Functional Requirements and Use Cases: Avoiding Accidents and Mix-ups in System Engineering

Ok. You have decided to make a monumental decision: you are going to hire an architectural company to build a new house for you. After months and months and what has to equal hundreds of thousands of dollars, you drive to your new home, walk in and…realize things aren’t quite right. You flip the switch for the garbage disposal and the upstairs toilet flushes. When the dryer runs, the air temperature drops thirty degrees. This is not what you had in mind. You have wasted lots of time and lots of money on a product that, in the end, was nowhere near what you wanted.

This is a legitimate concern in the software engineering and development world as well as any other type of construction. It’s easy to just build a house or just design a car if a customer asks you to, but there is so much room for error and disappointment, cost in both time and money, that we choose a little more intimate of a route. Not only do we develop websites for our clients, but we also develop business systems. To do this in at our most efficient level, we go over the functional requirements of the system with the client and follow that up with use cases.

Some sites can be basic, flat html pages, where the user can visit multiple pages via links and learn about the company, the products the company sells, and navigate pages without really doing anything other than that navigation. For example, a florist shop – let’s call it Fiona’s Flowers, based out of Tampa – has a website with a few pages that give the company’s bio, some contact information, some pictures and a list of various plants and boutiques one can purchase at the shop. All in all, it’s not much more than an online Power Point presentation that the user navigates. One can’t buy anything online, nor can one compare prices to other companies when Fiona boasts that her prices are the best in the area.

Now let’s backtrack and say Fiona hasn’t had this business designed yet, much less a website, but she knows what she wants there. She comes to us and says, “Hey, I’m going to be building a floral company. I have nothing except my idea and how I want it to work.” It is then our job to define the functional requirements – what Fiona’s system has to do – for the business system and the company. She has to have customer’s able to purchase online, has to have a shipping service and options for shipping, has to be able to compare prices for each and every plant she sells with the competitive market, etc. We end up with a laundry list of the client’s desired functions for their system because we want to design a complete system for you. Software engineering is, in essence, no different than engineering a car; what are the pieces and parts I have to build to make all this happen?

We’ve listed what the customer wants and documented what this product should do, and now we have a laundry list for system purposes – the functional requirements. Once we have that, we lay it all out into modules, creating a model for everything from application to the storage database. After looking at this list and modules, each building block in the application model, we start creating use cases.

Let’s look at an insurance company, for example. One objective for a use case, the process associated with it, might be creating a quote and saving it to the database for future viewing. The functional requirements are the ability to print the quote, generate a pdf file for emailing, etc. A use case for this quote creation would documents the flow of a user’s steps to creating a quote, from interface appearance, generating a quote number, attributes of the policies available and coverage, and so on and so forth. The use case basically walks through the steps of how a user uses the web page of the insurance company and its components.

Also documented are the specific business rules applied. The customer enters information on the screen  and clicks “save.” The next step would be applying a business rule according to what is laid out in the use case – what has to happen. A quote number needs to be created. What numbers are generated? How are they generated? These are business rules that have to be applied to meet the functional requirements discussed earlier. What happens if the driver’s license isn’t validated or wrong information is entered? What happens if a license number has expired? These are logical business outcomes that need to be very clearly laid out. If a user wants to take a policy on Dodge Viper and the business isn’t willing or able to take on that car value, what is the process that needs to occur that sends a message of refusal? The response is documented in the use case.

---

We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone.

---

Use cases are important because it forces both our client and us to agree on everything that is going to happen. We get sign off on everything before we sit down and design the product. We fully disclose to the client what we are going to develop before rather than during the building process, which makes construction both cost effective and easier to understand for everyone. It’s not only a system for agreement, but it gives the developer, who doesn’t make much contact with the client until the use case is developed, a very specific idea of what they’re going to be building and how to go about doing it. As the blocks agreed upon in the functional requirements are built, what we had previously discussed and agreed upon is enforced.

So, back to the house example from the very beginning. If we built houses, we would sit down with you and discuss – and agree upon – the functions for everything in the house. This switch will turn on the garbage disposal, this will turn up the heat, and this will lock the door. There’s no room for confusion or the possibility of a devastating mistake either on your expectations or our construction. The whole purpose is to get confirmation that what we’re developing is in essence what you need before the product is created. It saves you money. It makes us efficient. And it makes the products stronger, better, and faster.