Many organizations rely on heavy documentation for requirements, architecture, testing, and implementation. Often times these documents go largely unread, forgotten and exist for the sole purpose of creating a legally binding document between the IT department or consultant, and the business or organization. Iterative development, and defining solutions with close involvement with the customer is key to the success of an Agile project.
In a way, a Requirements document may be used by the business as a means to state the contractor or IT department did not exactly do everything which was written in the document. My question to that is, so why do we have a requirements document? Is it a deterrence in case an IT Department does not do what they were supposed to do? These documents go largely unread, and the development team is often confused by what is stated in the requirements, leading to longer development time and time to market.
Recently, I’ve had the chance to work with simulation software with several colleagues. Many software applications today are web applications, built using a standard n-tier architecture. At the top of the tier is the presentation layer (what a user sees), in the middle is the application layer (when a user clicks an element in the presentation tier, what it “does” is defined in the application layer), and the bottom is the Data Tier (stores all interactions, information, and interacts with the application layer).
The user (and often times the customer) only sees the presentation layer. So, why not build that first? Your business customer wants to see a solution, help mold it, shape it, and see what it will look like. The business logic is often times already defined; it is the way the user interacts with the system which will involve the customer into the design of the solution.
Many simulation tools and Integrated Development Environments (IDEs) provide the ability to build out a custom user interface with some functionality. It can be built on the fly, quickly, and demonstrated to the customer. A development team can then take software developed in the simulation environment, and build out functionality and code behind the presentation code. This increases agility, providing the customer with a functional prototype which can be quickly built with a level of functionality behind it. Developers can take it, and understanding how the presentation tier works define the application and data tiers.
The requirements document is key to documenting all requirements, but often leads to a large, unusable document for the development team. Creating software within a simulation environment provides a method for IT departments to quickly deliver a working prototype and functional software. Ultimately, this deters the customer’s notions “I’ll know it when I see it.” Forward to Agile!