No matter if you go for the waterfall method or Agile Project Management: You do need a specification sheet at the beginning of every software project. With just one difference: In a project based on the waterfall method (e.g. for a public authority) the specification sheet is key reference document, while in agile projects the specification sheet is merely a starting point. Nobody should fall into the illusion that agile projects don’t require specification sheets, that you can “get started immediately”. Agile projects shouldn’t be used as an excuse to skip preparation of a guideline documentation, that defines the target, limitations and provides some knowledge items on the relevant domain. In short: “This is how our business processes work and this is where we want to go”. In order to resolve any doubts about the relevance of the specification sheet, here are the main reasons.
First, you need this document for the selection of suppliers, that is: A Software Development Company. If you do not at least roughly describe the requirements, the objectives, technical challenges, how should the shortlisted IT service providers present their approach and make a proposal? Second, even if requirements specification may be adjusted over the course of the project, you need a reference point in the contract negotiation phase to define the cost/budget framework. It does not matter whether the compensation model is ultimately designed as a classic fixed price, Time&Material, Agile fixed price, fixed price per sprint or guaranteed maximum price. You always need a starting point. Especially if you start an innovative software project (for such scenario agile development would be the method of choice), there should be a rough target vision for a software project within the company, some guidelines should be defined; experience shows that this requires time-consuming coordination processes. Running into such a political gridlock phase in the middle of a software project can lead to frustration, so it is advisable to put this process at the beginning.
Feasibility Study for innovative software development projects
If your software development project turns out to be very ambitious with quite a number of innovative ideas for features and workflows, you may want to evaluate whether these ideas can be implemented at all with existing technologies – or whether this can be done at reasonable costs. In this case it should be considered to do a feasibility study in a 4 to 8 week project.
Such a feasibility study suggests several software designs / technology stacks and analyzes each option with regard to strengths, weaknesses, limitations or risks. Sometimes it may be helpful or required to build a small prototype. A feasibility study can under no circumstances be considered as waste of time, because the necessary clarification processes are due sooner or later anyway. In the worst case, a feasibility study could reveal that an initial idea does not work at all – in this case, not only has a lot of time been saved, but also a lot of money.
The specification sheet: Which technical specifications are required
One central feature of the specification sheet is that it gives the potential contractor (that is: the IT provider or software developer), a well-structured guidance about what the desired software should be able to do and under which general conditions the software will be used. What the requirement specification does not contain, is the specification, how these requirements are implemented (technology stack, software design). Everyone who writes a specification sheet certainly has ideas how he or she would implement certain requirements, especially if the internal IT department is involved in the creation of the specification sheet. However, the less detailed the technical specifications are put, the more software developers can contribute their expertise and ingenuity.
I am constantly working in the midst of and with software developers, I am watching technical trends – yet I am always aware that the technical scope of possibilities is so enormous and is growing daily that it is impossible to keep track of it as an individual. Just take programming languages as an example: Until the mid-1990s, only half a dozen of them were actively used (C, C++, Delphi, …), but today there are already dozens of them, each with a strengths-weaknesses profile that only specialists still have an overview of. In addition, there are low-code platforms, AI services, a plethora of No-SQL databases, a trend towards cloud-native applications: Do YOU have the full overview here? My experience is that the internal IT departments of medium-sized companies (unlike in large companies) are not geared to maintain a full overview. The smart design (and justification) of the technology stack lies within the responsibility of the potential contractor (software developer).
In some cases a client organization intends to take over maintenance of a tailor-made software; in such cases the client organization may pre-define a technology stack which is consistent with the technologies that the organization has decided to support in the future. A client organization may also have excluded some technologies due to their security policy; this has to be considered then, by the contractor. There may be requirements such as this: If the software is to work with an industry-standard third-party library or web services, then this should also be formulated. An example of this: A document management software should integrate the OCR module of ABBYY, for example, because this enjoys particularly high customer acceptance, offers an attractive pricing model or is a quality leader.
And, of course, the client must specify the technical framework conditions: On which platform should the application run, Windows, Unix, Linux? Is operation in a public cloud or private cloud conceivable? What is the quantity structure (number of business transactions), number of users, how should the software be able to scale within the next 10 years (what growth does the company expect)? Which technical interfaces are required (e.g. to existing ERP applications)?
The specifications: Who does what with what for what purpose
Of course, the technical framework conditions only come at the end. The actual starting point of a specification sheet is obviously the requirements from domain (power) users. First of all, it’s about the objective for the software project: What purpose should the software serve? Do you want to replace an existing software (which no longer meets the requirements), do you want to migrate an ecosystem of MS Excel applications onto a robust technology platform, or do you need a mobile APP for a new digital business model? What are the criteria for success of the Software Development Project (X number of new customers, throughput time of X seconds for a given workflow, etc.)?
Once this overview is established, the requirements must be specified in detail. The structure of the document (quite common: WORD document with attachments) and description of the requirements must enable even a reader with little domain knowledge to understand the requirements. Requirements / specifications should be categorized according to the MUSCOW principle, meaning: What are MUST-HAVE requirements, what are SHOULD, COULD and WOULD requirements. This is particularly important with regard to the need to keep a software project within budget limitations.
The specifications should also list which points are yet Work-in-Progress, so that a potential contractor can estimate the implications for the time schedule. Above all, the specifications must also indicate which extensions for the future might possibly be necessary or are being considered, because such future requirements must be considered in the software architecture of an application from the very beginning.
The client should also provide information on the (desired) project organization. What’s the target time frame? These expectations allow the potential contractor (software developer) to align his capacity planning with the schedule. If expectations prove unrealistic (overoptimistic), the software developer can enter into discussion with the client organization. If the client already has expectations regarding the remuneration model (e.g. fixed price, Agile fixed price, fixed price per sprint and the like), then this can also be entered in the document. Similarly, it should be formulated if there are preferences for the project management method: PRINCE2, Waterfall, Agile.
