Software is Abstraction
Software is a representation of reality. A computer-based tool that is analogous to, and often replaces, a tool from the real-world of touchable things. You may think this is painfully reductive: protesting that computers accomplish tasks that would be all but impossible otherwise. And yet, computers were once humans. All we've done in recent years is make the math machine-based.
It is easy to forget that all this technology is really just a substitue for doing things on paper. Apple wanted users to understand that the calendar application was... well, a calendar, so they made it look like one. Complete with leather binding. Some appreciated the familiar feel—iCal is a replacement for paper calendars. Many found it off-putting. Mow.
Why must a virtual calendar look anything like a physical one? The short answer: it mustn't. Yet, we use familiar terms for digital things because they replace physical ones. If digital things replace physical things, what are we doing when we develop software? Creating a virtual tool to solve a tangible problem. We could, and did, do it with pencil and paper. All computers do is enable a whole lot number crunching, problem solving to happen real fast.
Process is Not an Advantage
Businesses want to deliever computer products to solve palpable problems. The two exists in a loop: market feedback informing business decisions. In between is process: drafting ideas, managing change, and delivering improvements. This is intuitive, but its simplicity hides an important truth.
Product is at the mercy of process. We know that process can slow delivery, the illustration of short iterations empowering rapid improvement is by now famous in agile development circles.
Developers have the tools they need to continuously deliver software, deploying changes in near realtime, yet business leaders are sadly limited in tools to align and communicate their vision before it gets to developers.
Lost in layers
We know we must do so if we are to keep our product from becoming a mess, yet we have not to investigated the journey an idea takes to becoming a usable tool. As long as it remains mysterious, we miscommunicate, the process slows, delivery is delayed, and the product suffers.
"The system shall have four legs and a trunk."
If we want to understand how to improve the process of turning ideas into product, we must first deconstruct process.
Requirements Versus Vision
A catchall phrase in business is "requirements." This buzzword is damaging. Many have been mislead into believing a requirement is a highly detail technical specification. They assume broader vision is not worth documenting.
The Institute of Electrical and Electronics Engineers offers a pragmatic definition that encompasses the diversity of requirements that should be recoded (IEEE 610.12).
1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in 1 or 2.
As IEEE states, the first step in the process of crafting a quality product is understanding the objective. These are the non-functional requirements, that will eventually make their way into functional requirements.
This model is adapted from Microsoft's Software Requirements Best Practices (ed. 3, 8). In their assessment, authors Karl Weigers and Joy Beatty emphasize that documenting vision is a fundamental step in software development. They remind us that "writing requirements" is not sufficient to communicate vision.
When we say 'writing requirements,' people immediately think of writing textual requirements in natural language. . . . translate the phrase 'writing requirements' to 'representing requirements knowledge' . . . choose an appropriate mix of communication methods to ensure a clear, shared understanding of both the stakeholder needs and the solution to be built.
To succeed, we must move beyond simply writing down specifications. We must document, communicate, and share a vision.
In the coming weeks, more will be shared here on how to document vision. Bookmark this page and check back.