Specification-Only Method Overview

The method for the developer and the client is simple:

Wireframe the user interface - PC, Pad, Phone.

Give all dynamic data items an identifier, eg. “Supplier”.

Specify a source for each dynamic item eg. “Supplier.Name” (from database).

Specify actions for buttons.

For example, this form lists orders for a nominated supplier and customer:

Orders.form

Supplier : Supplier.Name

Customer : Customer.Name

List each Order

Ordered : Order.OrdDate(24) (24) shows 24 hour time

Confirmed : Order.Confirmed(24)

Delivery Date : Order.DelDate(d) (d) shows short date, eg. 20/11/2023

Shipped : Order.InvDate(d)

Amount : Order.Total(0.00) (0.00) shows amounts like 1234.90

Paid : Order.Paid(0.00)

Notes : Order.Notes

[Review Order] Load OrderItems for this Order

>OrderDetails.form display the details for the order

[New Order] Load all Products

RestoreSavedOrder customer might have an unfinished order

>RetailShop.form if SavedOrder.Id = Nothing no saved order

CalculateOrderTotals

>Review.form review saved order

[Back] >Customer.form

End of Orders.form

Dynamic items have been identified on the form (or page) and associated with a source, eg:

“Supplier : Supplier.Name” means “Supplier” is bound to “Supplier.Name” in database.

Actions when a button is clicked are specified, for example:

[Review Order] Load OrderItems for this Order

>OrderDetails.form display the details for the order

Comments are in italics. Navigation is indicated by “>”. Database requirements fall naturally out of the sourcing process. The need for temporary items and processes will be identified, eg:

CalculatePrice

If Customer.Type = ‘Govt’

Price = Product.Price - GovtDiscount

ElseIf OrderTotal > 1000

Price = Product.Price - VolumeDiscount

Else

Price = Product.Price

EndIf

End of CalculatePrice

When all of the user interface has been wireframed, all observable data items have been sourced and all processes have been specified, the specification is ready for approval by the client and automated building of the application including creation or update of any database schemas.

The application is immediately ready for testing or general availability in the host environment. Test data can be automatically generated.

Early projects used Ms Word to directly create the specification; this option always remains available. Later projects enabled data sources and action statements to be edited interactively within the UI designer and used a project editor to manage projects and guide the development of the specification. A project editor provides error and completion checking; ensures all data items are uniquely identified and properly sourced; catches typos; validates specification statements; checks consistency with databases and validity of files and images; and provides context sensitive, interactive help.

The system specification can be generated from the editor at any time. The specification is the basis of the contract with the client and the application is always built from the specification.

Examples of specifications can be seen under Projects at www.specificationonly.com . The simple To-Do project example demonstrates how a useful running application can be created from wireframes with almost no specification language at all. The specification-only method uses inference where it can to automate the building of an application, however, a specification is meant to be specific with no ambiguity. It is not sufficient to say “calculate the price”, the calculation must be specified and approved by the client.

So it’s a simple but disciplined process for the developer and the client. Of course, there’s a lot going on under the covers to make this simple process work.

Specification Language:

The proof-of-concept specification language grew from the original manual specification language that had proven so successful. Over time it has been improved and extended to enable clients to use their own domain specific language. The proof-of-concept language has proven to be effective in delivering client applications and being acceptable to all stakeholders, however, there always improvements to be made.

The underlying structure of the language should support a curated core while enabling domain experts to extend the language to meet specific requirements using a managed language extension tool and repository.

Tools:

Intelligent wireframe designer

Project editor

• project management

• user interface refinement

• contextual user help

• process specification

• database review & management

• file management

• specification generator

• application builder

• generation of test data

Specification language manager

The proof-of-concept application builder generates very small driver files that are interpreted by purpose-built native host engines to execute the applications. Engines were created for Windows and Cloud (Azure) hosts. An alternative architecture could generate java from the specification and use java virtual machines to execute the application.

The proof-of-concept used Balsamiq Mockups for wireframes. Very easy to learn and use but needs work to make it the ideal specification-only tool.

Host Environment:

The natural hosting environment for hosting specification-only systems is the cloud. This could be a public cloud like AWS or Azure or Google; or a private cloud fully managed by a large enterprise or government agency. Specification-only systems, however, are not limited to cloud hosting, all popular in-house and native device environments can also act as hosts. A significant advantage of using a major public cloud is that you can get best available security, reliability and scalability by default.

The specification-only execution environment allows you to get the best deal from the best host provider by enabling you to move systems or sub-systems to a new host.

Approval:

Ideally, all of the specification should be formally approved by the responsible end-user(s) or client representative(s). Where the developer is leading the project and is the project technical expert, the optional and more technical sections (Lexicon and Data Storage & Access) can be signed off by the project leader/facilitator.

Our experience is that the client representatives are comfortable in approving the specification and retain a good understanding of what will be delivered.

Ecosystem:

Specification-only systems will always operate and interact in a world that includes a wide variety of past and present technologies. Ease of integration with other applications and use of commonly used services and devices via simple specification language is vital.

There are an infinite variety of system requirements that may be confronted by a developer. The core specification language will frequently meet all of the system requirements, however, there will be occasions where it is necessary to extend the language to enable the client stakeholders to use the natural language of their domain using either the optional Lexicon within the specification or the language manager for storage in a domain repository.

Developers will find that their existing skills transfer easily to the Specification-Only method of development. They will enjoy a more creative, productive and satisfying experience.

Current and future program coders will continue to prosper within and outside the specification-only world. Within the specification-only environment, program coding will still be required to build tools, unique processes, language extensions, integrations to legacy systems, etc. For DBA’s and application product specialists it will generally be business as usual.

Software system consumers will experience a more consistent, professional process that gifts them genuine control of their software applications and budgets from initial contract through to ongoing maintenance of the running systems.

Software development and professional services organisations can remove risk and increase profit while providing a better service for their clients.

IT departments can focus on providing rock solid infrastructure and security while optionally outsourcing much of the business application development to business analysts with both technology and business domain knowledge.

For specification-only tool and platform providers, it’s happy days beginning with cloud-based services for UI design, project editor, language management and optional run-time services.

---------------------------------------------------------------------------------------------------------------------------

Beyond AI - a path to automated software creation

What do the owners and end-users want from their software systems? A good starting point is:

• Reliable: bug-free software with no downtime

• Effective: meets the needs of the end-users

• Secure: safe from lock-in, program bugs, malware, hacking, unauthorised access

• Current: can be maintained in parallel with changing end-user needs

• Understandable: stakeholders can access and understand documentation that is always consistent with the running system

• Efficient: developed, deployed and executed using optimal resources

• Scalable: user numbers and other application limits can be adjusted dynamically

We can make a neat acronym RESCUES from this.

I want to add a further desirable and transformative quality to the above RESCUES set:

• Quotable: enables a fixed cost and delivery quote

Vendors of software development tools and current practitioners of software development may feel that they meet the RESCUES requirement but I know of no current combination of methods, tools and people that does. If you throw enough of the right resources at a project it can be delivered to achieve the reliable, effective, secure and scalable requirements but not efficiently and not in a form that is understandable to all stakeholders and/or maintains its portability and currency throughout its life. Fixed price and delivery quoting of software development is virtually unheard of for any serious project.

These quality objectives can only be achieved consistently across the software industry by the use of automation. Automation is necessary to guarantee our quality objectives but it should also invite human intuition, experience and creativity which remain irreplaceable.

Current AI offerings are not capable of automating the development of software systems. Equally current development software development methods are not suited to using future AI advances to optimise automation. Program code assistance can be helpful to programmers but will not provide the transformative efficiencies and certainties that an automated software system development and delivery method promises.

The key to the promised land lies in the use of a standard system specification structure and language that provides a single source of truth for all stakeholders.

No software development project can begin without a stated requirement and no software development project can be advanced without first specifying the deliverables to meet the requirement. It doesn’t matter if it is a large formal document or a discussion with an end-user, specification is always required.

Given that we need specification, why not create a specification document that that can be comfortably signed-off by all stakeholders and has a structure that enables automated building and deployment.

The basic requirement for such a specification is to provide a clear and intuitive document that contains natural language to specify system functionality with sufficient precision to enable a computer to transform it into an executable software system that complies with all of our RESCUES+Q quality objectives.

This is a challenge but has been proven to be both possible and effective in complex real-world exercises and is well within the capabilities of current software development and productivity tool builders.

The running application must be generated directly from the approved specification. This provides truly transformative benefits to software developers and their clients:

- a clear unambiguous contract between developer and client

- certainty of cost and delivery time

- documentation that is accessible and understandable by all stakeholders

- documentation that is always consistent with the running system

- ease of change

- consistent reliability, security, scalability, portability and efficiency

- focus on system functionality instead of program code

- very large cost reductions over the application lifecycle

I call this a "specification-only” method or environment because the specification is the only authoritative document that describes the functionality of the subject software system and is the single source of truth for all stake-holders.

This specification-only method does not rely on the use of generative or general AI but it does provide great potential to benefit from future development of machine learning models based on specification-only systems. In the future, it could be possible for a complete system specification to be generated from requirement statements.

The specification-only method is conceptually simple but its implementation entails complex underpinnings. The technology and skills to implement it are all currently available in abundance, however, the secret of success will not be found in the technological underpinnings but in the faithful adherence to the basic requirements for the specification:

1. The use of natural language that can be understood by all stakeholders

2. Sufficient precision to be transformed by a computer into a running application

There are, of course, many other requirements that must be met by the specification structure and language. It needs to cater for the whole of a software system including UX, data management and the processing of business rules and algorithms. It needs to be extendable so that approved new language can be added to a curated core and to enable libraries of standards-based domain-oriented language. It needs to enable integration with legacy systems, unique custom coded software and physical devices.

A fully implemented specification-only environment should be able to cope with any software system project of any size and complexity.

This concept is not just theoretical, it was first used in manual form to provide complex turn-key enterprise resource planning systems, ie. the core business systems for manufacturers, wholesalers, retailers, finance providers etc. The systems specification was created in a proprietary structure using natural language, signed-off by the client and then the specification sections were distributed unchanged to programmers for coding without preparing separate program specifications. This method obviously carried risk within the program coding phase but it still enabled fixed cost quoting and faster delivery.

The success of the manual specification-only method led to an ambition to automate the build phase in order to eliminate the risk posed by manual program coding and to accelerate delivery time.

Over a period of more than a decade, a specification language was developed for automated building of the specified systems; run-time engines for desktops, phones and the internet were built; and a number of challenging projects were successfully implemented.

For example, a tactical intelligence system for the Department of Defence that integrated third party vendor software, military messaging systems and embedded military software algorithms.

This system automatically parsed relevant military messages to extract objects of interest (people, organisations, locations, events, weapons etc) and data related to those objects (names, addresses, phone numbers, images, dates, times etc) for inclusion into a repository. A typical use of the repository would be a preparatory report showing activity in a patrol area including mapped hotspots; people of interest (with photos); relationships between people, organisations and events; and time-of-day and day-of-week patterns of activity.

Incumbent providers were not able to demonstrate a solution nor were they willing to take on the project within an acceptable budget. We were able to provide a clear specification and demonstrate its functionality. We were able to quote a fixed price and delivery time. The specification could be embedded within a contractual DoD document. The clients were comfortable in signing it off. The executable application was generated directly from the specification ensuring it was always compliant with the approved contract.

Another challenging problem was solved for a large taxation agency. Targeted entities were identified for further research which could take a month or more for a single entity. The proposed system dramatically shortened this process by providing all relevant data in a single chart at appropriate points in an analyst’s workflow. Data from disparate sources were selectively merged into a single view. The client could understand exactly what would be delivered and the system used the client’s preferred charting technology. A fixed price and delivery time was quoted to fit within their budget constraints.

More conventional information management systems such as Case Management and WholeSale/Retail collaboration systems were also successfully developed using the specification-only method.

The opportunities to deliver the projects were entirely dependent on the specification-only method. Without the specification-only method we were nothing, the competition were typically heavy hitters with very deep pockets (eg. IBM). We were successful because of the understandable specification, the clarity of the contract that could be signed off, the fixed price quote and the speed of delivery.

Some examples of what a specification-only project might look like can be seen on this site www.specificationonly.com . The examples are small but range from very simple to quite complex. They optimise automation while demonstrating the tension between the need to be understandable and the need to be precise.

Don’t be fooled by the brevity and simplicity of the specifications. An infinite variety of software systems of any size can be delivered using the same method.

Experienced developers will see language in the specification that looks a bit like program code or scripting. This is because specifications need to be specific and these statements have proven over time to be the most efficient and natural way of specification, eg:

AmountToPay = Price + VAT

AmountToPay = Price - Discount if Customer.Type = ‘govt’

In all of the specification-only projects we have implemented, no-one has pushed back against the structure and language of the specification. Each stakeholder has been able to understand the relevant sections of the specification and comfortably approve them.

A recommended development method that goes hand-in-hand with the specification-only infrastructure works back from the specified deliverables (a similar concept to Amazon’s much vaunted process of “working backwards”). Each deliverable data item must be identified and sourced (it must come from somewhere). This is a simple process and can be assisted by tools to ensure that identifiers are unique and sources are valid. Database requirements fall out of this process so that where database schema creation or change is required it can be automatically generated using the provided tools.

The automated specification-only method provides a clear competitive advantage because of ease of contracting, lower costs and faster delivery. Fixed prices can be quoted with certainty of delivery while still retaining high profit margins. Support responsibilities are clear; the application always operates in accordance with the approved specification.

So we have a proven concept and successful implementation projects! Why hasn’t the

whole software development world adopted this to the benefit of their clients and themselves? One thing:

- support of a major software tools and platforms provider

The committed support of at least one major software industry player is a must My preference is for an open system specification standard, however, the commitment of a trusted and influential leader is the more important element.

There are compelling arguments to be the first mover. The first successful mover into this space can create a defacto standard and become “the" software development company. The specification-only method is a conceptually simple change to the software development process but it will have a profound impact on the software industry.

There is further work to be completed to enable industrial strength language, tools and platforms. The responsibility and capability for that work lies where it should; with the trusted industry experts, ie. proven software development tool and platform providers.

Developers will find that their existing skills transfer easily to a more creative, productive and satisfying process. Software system consumers will experience a more consistent, professional process that gifts them genuine control of their software applications and budgets from initial contract through to ongoing maintenance of the running systems.

I have written this article as an introduction to the development of software systems using the specification-only method. After spending many years working with a wide variety of software development tools and methods, I know that the specification-only method provides a huge competitive advantage and can bring a new level of professionalism and simple efficiency to the production and maintenance of software systems.

I don’t claim to have built the ultimate specification-only system but I have gained a wealth of knowledge from experimentation failures and implementation successes. Our proof-of-concept specification language and enabling tools have proven to be effective, however, an expert tool and platform provider could build something really wonderful provided they stay faithful to the two basic principles:

1. The use of natural language that can be understood by all stakeholders

2. Sufficient precision to be transformed by a computer into a running application

and respect our RESCUES + Q quality objectives.

Courteous and thoughtful commentary is welcome.