Requirements are often considered a relatively minor portion of IT projects – they are used to specify the functionality of the system so developers can build that functionality and testers can validate the functionality is working properly. There are, however, several other uses for requirements that can help ensure the long term success of a software project and minimize risks.

Change Controls
One of the most frustrating things for IT management is when the solution to a problem ends up breaking several other pieces of the software. This happens when the solution is inadequately tested and/or other parts of the software are not considered. The issue can be avoided by making use of extensive change controls to determine what the impact of a change will be. Requirements, especially models such as Process Flows, Data Dictionaries and Report Tables can be used by change control software to link to each other to show what the impact of a change can be.

For example, specific data fields in a data dictionary can be linked to several report tables and a process flow. When a bug is discovered in the software that is affecting that process flow, the change control software will identify those report tables as being potentially impacted by the change. The testers can then determine if the reports are affected by the change and can prevent costly retro-active changes from needing to be made if the reports are affected.

Real-world case: ArgonDigital helped a customer identify issues with a version upgrade using requirements that would have had a negative impact on an upcoming state audit through the change control process. The customer held off making the version upgrade until the state audit occurred, helping preserve the $1 million/year line of business under scrutiny by the state audit.

Full Business Views
It’s surprisingly common for organizations to be extremely segmented and for each individual department to have little or no knowledge of what other departments do. This can result in significant inefficiencies: for example, when one department is compelled to undertake an effort that another department can perform much faster, and yet the first department is unaware that the second can do that work faster. Even if this information is shared, there will often be significant resistance. Helping another department will reduce the helper department’s throughput.

What is missing? An overarching view that the assistance will result in higher overall business throughput even if one department’s throughput is reduced. In this case, utilizing L1 and L2 process flows to get a holistic view of departments and the overall business will illuminate how each department works in conjunction with each other.

In addition, those process flows can be used to generate measurable KPIs focused on total organizational throughput. These metrics present a persuasive argument for departments working together and reducing the silo mentality that occurs in these types of organizations.

This reduces risk for IT projects in a twofold manner; improved KPIs will increase the value that the project is adding to the business justifying a higher budget and/or additional time to completion as well as more cooperation between departments will facilitate a more communicative culture, a valuable intangible.

These are just two of the many ways that utilizing requirements can result in a lowered risk for IT projects. Whether it’s reducing the cost of making changes, improving organizational culture, or improving the value a project adds to a business, requirements are strategic for IT success, and are more than the simple “build this function, test this function” documentation of projects past.