Spotlight Issue 3 - 2013
The decision to roll out new software or a new system to your home office and sales force is a commitment. It’s a commitment of human, financial and time resources. At the end of all the planning, developing, testing and training preparation, the ultimate goal is not to just put something into production, but to put something into production that is going to be useful for the end user. And if successful, it becomes not only useful but invaluable.
According to Merriam Webster’s Collegiate Dictionary:
use•ful
adj \ˈyüs-fəl\
1: capable of being put to use; especially:
serviceable for an end or purpose
To deliver software that is useful and meets the needs of the end user, we have to start with quality requirements. When people hear the phrase “quality requirements”, the first thought that comes to mind might be “requirements without errors”. Minimizing errors in requirements is certainly part of the equation; however, when we are thinking of quality requirements in terms of usefulness, the content and subject matter is far more important than the format.
Quality requirements are complete and representative of your user base. Defining only the basic components of a system or piece of software is simply not enough anymore. When designing an illustration system, for example, the set of requirements has expanded beyond simply defining the User Interface, Calculations and Output/Reports format. We now have to attempt to define the user experience. Everything from how the user logs on to the system to how they log off and every interaction in the middle.
Software systems and illustration systems in particular are rarely standalone systems anymore. Illustration systems are required to integrate with administrative or back office systems, electronic application systems, underwriting systems, and the list goes on and on. To completely understand the work flow for your users, you have to understand the full set of use cases and the end-to-end process in which your particular system lives.
Illustration systems are also being used by more than just field agents or field users. Understanding the system requirements by “type of user” or “user role” is becoming more important. For example, the premium limits for a home office user of an illustration system versus the premium limits for a field user might be quite different. There may be internal systems such as batch processing that are only available to home office users and not to field users. If you don’t fully understand how the system you are designing is going to be used, and by whom, you risk putting the wrong tool or an unusable tool into the wrong hands.
For purposes of defining requirements outside of the traditional User Interface, Calculations and Reports scenario, we will discuss three main categories. By no means is this an exhaustive list of the types of requirements you might choose to capture, but it does include three important and sometimes overlooked areas.
One common thread in defining requirements is documenting use cases for each area of requirements. Gain user intelligence by speaking to future users of the system along with users of the current system you are replacing to find what works well, or not so well, and how they interact with the system to get an understanding of how to better meet their daily needs.
System Integration Requirements consist of all those requirements and scenarios that define the other systems and processes that your system is going to interact with. In other words, how is your system going to interact with the other systems that make up the end-to-end experience for your users? If the illustration system you are designing is going to be invoked via the user logging into the company portal and selecting your system to launch, that would be important to know. If you are going to have buttons within the illustration system that call back to an electronic application system or a contact system, that would also be important information to know and document.
The best way to uncover System Integration Requirements is to start with documenting use cases. How will end users interact with your system in conjunction with their other systems? What does their workflow look like? What kinds of interactions are critical to the way they do business? Speak to field users, home office users and any other user group that may have a distinct way of interacting with your system. Once the use cases are known, you can begin to talk to the developers and owners of the other systems to define the technical requirements for your system’s interaction with them.
Why would System Integration Requirements be so critical to the success of the system you are building? Because if you’re a user of your system, and it doesn’t flow the way you need it to and interact with the other systems you need on a daily basis, you’re not going to find it very useful.
User Requirements consist of all requirements and scenarios that define how different groups of users are going to interact with your system in a standalone capacity. In other words, does the way an agent is going to use the system User Interface differ from the way a home office user will use the User Interface? If your home office users are going to have a requirement to be able to override your maximum premium or maximum face amount limitations, that would be a key requirement to know. If you are going to have several different levels of field users, agents and office administrators for example, the rules for how each user can interact with the illustration system would be important to uncover and document.
Document these types of requirements with use cases. Talk to the different user groups and find out what their pain points are. What would make their lives easier if they could do it within your system? These types of requirements are generally specific to your system unlike Integration Requirements. Once the full set of use cases is known, you can begin to document the “one-offs” or other exceptions you have uncovered.
User Requirements are critical for the same reason System Integration Requirements are. Because if you are a user of your system, and it doesn’t work the way you need it to, you’re not going to find it very useful. You’re going to have trouble adopting and using it on a regular basis.
System Integration Requirements Non-Functional System Requirements are comprised of all the requirements and thresholds that define how our system is expected to perform. For example, do you have specific requirements for the speed of the system? Does it need to work on desktop operating systems and on mobile devices? What is the anticipated user load that it must support? Defining and vocalizing these types of requirements at the start of your software project can ensure that the right hardware is purchased, that the right system design considerations are made, etc.
Documenting these types of requirements can be a bit more difficult. You might want to review your other systems that are set up with similar hardware configurations for benchmarking. Interview your users to get an idea of what they like and dislike from the systems they currently use. Perhaps it’s frustrating to them that they cannot use their frequently used software programs on their iPad for example.
Non-Functional System Requirements are critical to the success of the system for many reasons. If you are an end user of your system and it performs slowly or doesn’t work with the operating systems or platforms you use on a daily basis, how likely are you to adopt the system and use it frequently? If your system is frustrating to your users then it is certainly not useful or of value to them.
While testing of the User Interface, Calculations and Reports can be very involved, writing test cases for these areas is often easier because they are based only on the documented illustration system requirements. Testing System Integration Requirements, User Requirements and Non-Functional System Requirements can be a bit more involved. You will need to coordinate testing of system interactions with the other systems in the work flow. The end user may need to run scenarios on their end or make changes to their system to allow testing to happen. User acceptance testing is usually a good way to ensure that your User Requirements have been met. Non-Functional System testing is often accomplished via software load testing tools, platform testing and other performance measurements. Testing for “usefulness” is accomplished through a combination of test plans to address all three of these main areas.
Much of the discussion around usability may seem obvious. For your system to be received well, you need to collect complete and quality requirements around integration, usability and system performance. Often times when designing software it’s easy to get buried in the details of the specific business rules, data definitions, output text, etc. It’s very important to take a step back and think about the big picture requirements that will go into making your system not just useful and successful, but ultimately an invaluable tool to the people who use it.
Insurance Technologies