Diane Davis, Business Consultant, FINEOS
Missed requirements cost money, so before engaging with FINEOS (or other vendors) companies should know their own business. Often the knowledge of how you do what you do is scattered among departments, company documents and people. Having an inventory of your company’s inner workings in one central place before engaging with your software vendor is a vital step to ensuring that your requirements are complete and accurate.
It is widely known that it is far less costly to fix requirement misses than to fix bugs or add functionality later. A 2010 study by NASA in which three methods were used to calculate the escalation in costs summarizes its findings by saying that “the study revealed that costs escalate [as a project moves through its lifecycle] in exponential fashion”, and “the early detection of errors is highly important to the success of any project”. The paper cites, among many other sources, Barry Boehm’s 1981 findings that “Finding and fixing a software problem after delivery can be upwards of 100 times more expensive than finding and fixing it during the requirements and early design phases”. Therefore, it is worth the effort to identify and ensure that those critical but not widely known processes are included in the final solution before development starts.
Prior to embarking on the detailed work of requirements analysis and documentation with your software vendor, the first internal discussions should almost toss software completely out the window and talk about what people do in each process, what regulatory agencies are about to make them do, what “Bob” does, and what you plan to do in the future. This may seem like a waste of valuable hours away from desks, but it allows experienced people from pertinent areas in the company to define what they are doing without determining how the system should be doing it. I have found that people tend to be most animated, creative and collaborative when they talk about what they know without imposing boundaries of what the system should do or trying to define how the system should do it.
One of the deliverables of these sessions should be a comprehensive set of documentation on what people do in each process. This should include all entry and exit points to each process, including those steps thought to be far downstream of the new system. For example, perhaps a specific bar code font must be supported so that when a document generated by the new system is returned by the recipient it can be read by equipment that is not linked to the new system in any other way, but it needs to read the bar code. This is just one example of requirements that may be missed in a normal requirement gathering session with your software vendor. The following existing resources will help identify more elusive but critical requirements:
Company Handbooks. Training, Process and Regulation Manuals often contain detailed calculations, processes and rules that will not only help with system definition but may describe activities currently done outside the system, maybe with pencil and paper, that can be incorporated into the new system. Reviewing training manuals can reduce missed requirements and reduce the cost of elaboration, since the documentation may only need translation into formal requirements.
Correspondence Library. Correspondence is usually mentioned in process discussions, but only as a reference, such as, “then we send a notice to the Claimant”. Documents, for example, are complex pieces of work. In addition document wording and layout, to get it right the first time your software vendor will need a list of the pieces of information required from other areas in the system (Doctor’s name, disability rating, requested information, etc.), a list of those who may receive the document or a copy of it, the trigger conditions for an automatically generated document and the period of time the document is effective.
Data. Finally, as a mop up, it is helpful to analyze the current system data and database structure. Analyzing and summarizing information gleaned from existing data can reveal an immense amount of information that can be helpful when defining requirements for the new system. For example:
- How many items (such as payments) are processed each day? The answer to this question will help with performance requirements, batch scheduling, high volume day trends, projections for future volume, per claim payment analysis, per payment transaction analysis, etc. Date/time stamps can be used to find the current average time to process an item.
- What’s this table for? “Oh Bob uses this table for that thing he does.” Analysis of tables that don’t seem to fit with the general data model can be helpful. They can spawn discussions about processes that were inadvertently missed but are needed, and identify reports that are run every day that should be discarded because nobody reads them.
Ultimately, the more sources of information used to assemble your vision for a new software solution the better, more intuitive and well-rounded the solution will be. This means creating an inventory of your business using existing documentation of all forms as well as gleaning from the expertise of people who will be using it. Taking the time up front will reduce the final cost of requirement documentation hours, development and testing. It is also likely to increase user satisfaction and reduce missed requirements.
Now that you are ready for us, let’s talk about how FINEOS can help you make your vision real.
Source: https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20100036670_2010039922.pdf
