When planning the development of a software application, consideration must be given to whether it is an open-requirement system or a closed-requirement system. This single distinction will have more impact on the development process than any other single factor in an application’s development cycle.

A closed-requirement application is the easiest application to develop. The requirements are well-known in advance and do not change. The best illustration of this scenario is a business unit that has been operating the same way for many years. Their processes are well-defined and rarely, if ever, deviate from the established norm. If they do deviate, they do so in reliable and expected ways, making them simply additional known requirements. Creating a software application to automate some or all of this business unit’s processes would be very easy to do.

To develop a closed-requirement system, the business process (composed of the business requirements) is recorded and the development team studies what needs to be created. Once the developers fully understand the requirements of the application, the only task left to do is actually write the lines of computer code that precisely meets those requirements – no more, no less. Once the application is ready it is considered feature-complete, meaning no further changes will be needed and no further considerations for the application need to be given in order for it to successfully accomplish its goals. The application simply continues to execute the same way every time it is used, because the requirements of the application do not change.

On the other hand, an open-requirement system is very difficult to develop and requires considerable engineering effort before the first line of software code is ever attempted. An open requirement system is often characterized by the terms “agile”, “configurable”, “componentized”, “scalable”, “extensible”, “customizable”, and “integrated”. The implication of this scenario is that the application being developed is never feature-complete by itself, but rather requires continual outside influences to round out the specific requirements for the situation in which the application is being used. This comes in many forms, from a single add-in for a specific feature to full sub-systems that add an entire feature-set to the application.

In an open-requirement scenario, the full details of what needs to be developed are never fully known as they instead evolve and adapt over time. What must be understood then by the developers is an approximate idea of how such an application is expected to evolve. Understanding the “how” requires considerable engineering effort long before any coding is ever done, as the developer must fully and completely understand the entire expected life cycle of the application in order to account for the ever-evolving expectations the users will place on it over time. This involves understanding of both technological and business objectives involved with the project.

Once the development team understands how the application is expected to evolve, the engineering work has only just begun. The developers must then carefully architect the application’s basic skeleton in order to account for every possible scenario that is expected during the application’s lifetime. Often this process becomes very complex and requires countless weeks, months, and sometimes even years of design and prototype work before an informed decision can be made on the best way to proceed. A failure at this critical point often results in an application that cannot successfully evolve into certain scenarios because of a weak design point in the system, or even worse fails in spectacular fashion due to system collapse.

One of the biggest reasons for the glut of poor software today is the simple failure to recognize and react accordingly to the large developmental differences between closed-requirement and open-requirement systems. Most of the time a software project is driven by business people who naturally have a firm understanding of the requirements, but simply don’t realize that the type of requirements make a fundamental difference in the development process. The resulting failures are often blamed on the development team involved, and this is partly true. It is ultimately the development team’s responsibility to know the differences between open-requirement and closed-requirement systems development and to educate the business leaders of the differences involved.

In many cases the business side of the equation, due to budgetary and/or timeline concerns, drives development of open-requirement systems into a closed-requirement development mode above the objections of the development team. Such an approach is the largest cause of late or unfinished software, or even worse, software that is poorly designed (or not designed at all) for the requirements. These software applications are always very fragile and loaded with critical bugs, leading to massive user rejection and permanent loss of user trust.

While it is not impossible to develop high-quality open-requirement applications, the success of both the development team and ultimately the business relying on the software lies directly with all parties understanding the critical distinctions between developing open-requirement and closed-requirement systems and proceeding accordingly.