When starting a new project, have you ever felt as if you are setting sail for a distant treasure island? Ever felt lost at sea? Did you ever find yourself among mutineers who used to be your team, the ship of your project adrift, and the deadline looming ahead like rocks?
This article contains some project specification tips from Onix’s experience that will help you avoid such situations, sail faster and more safely, and eventually make it to the hidden chests of gold.
A project specification in project management supports a successful, seamless development process since it defines a project's plan as a whole.
A treasure map is not a mere metaphor. A map is needed to locate a prize or for a trip. It can be represented as a plan for an activity or a tech specification for a project. Can you go after a prize without a plan? Well, yes - if it is hidden in your backyard, and you can dig it out on your own.
However, this is seldom the case with startups and small businesses: the future product owner has either no means, skills, or resources but an idea or needs that must be met. Not much, but these two basic requirements, the ‘who’ and the ‘what’ of the product, are equal to the ‘X’ mark on a treasure map.
The ‘business requirements document’ is one of the most frequently used terms referring to a project’s ‘treasure map.’ Requirements specification, product requirement document, design specifications, functional specifications, functional spec, technical details of a project, tech spec, project spec, or simply specs - all used when speaking of the document, and the list is still not complete.
Some use the terms interchangeably when referring to the same technical specifications document, while others identify different types of technical specifications by these words. Still, it would be fair to say that there are two primary types of specifications:
Functional specifications tell what to do, and technically how to do it. But tell whom? The captain (a.k.a. the project manager) and the crew, i.e., the developers, designers, testers, or other professionals who will be charged with the task of turning your business idea into a prototype.
If you were arranging a voyage, would you like to be able to calculate the time it takes you? To estimate the costs? To plan and know the options, risks, and ways around hazards? Would you like to sign up a competent captain and a diligent crew who perfectly understand the route and their tasks? Would you like to have a contract in place to ensure they bring you safely to the treasure island and back home safely after the treasure is found?
You certainly would!
The situation is very similar with software projects - you’d better have a project specification at hand as early as possible.
Generally, technical specifications are written at an early stage of the product development process because they determine product requirements such as:
Even some big corporations’ multi-year projects involved creating project specifications after migration to test and even to production, but let’s leave those scary tales to the mariners and look at the best practices instead.
Professionals write the best specifications, but anyone can draw a fairly good ‘treasure map’ on their own. They just need to follow some important key points.
You can use a project specification template as a guide through a technical writing process. You can find a variety of these templates available online.
To make things easier, prepare a list of questions that would add more details about their expectations, the problems they expect the new software to solve, the type of data software should collect, and what processes it would automate.
Start with general requirements for the product and then add more specific criteria. The requirements/criteria must be SMART, i.e., Specific, Measurable, Achievable, Relevant, and Testable. Read them critically, pretending you are not familiar with the idea yet, or as if you were seeking to minimize cost and effort. Show the draft to someone else. At the requirements analysis stage, it would be great to seek advice from other stakeholders, potential users, and software development professionals to evaluate all items and determine if they are essential to the product at the moment.
It is important to remember that many people with different backgrounds will be reading or even collaborating on the document, and all of them must understand the requirements. These tips should help:
Some say that ‘a functional prototype is worth a 10,000-word specification’. However, this method instead belongs to the product design, and at the initial stage, without approved requirements and a team, you may need professional help to do this. So, before hiring a designer or business analyst, make sure your general requirements will be precise, at least to them.
Project specification must describe the minute detail of either all or specific parts of a design, such as:
Technical writers would help translate a ‘user-friendly’ and functional spec into highly formalized technical language as the development phase requires. This will provide your project specification document consistency and clarity.
When the team agrees that functional specification consensus is reached, it may be deemed ‘signed off.’ The developers and QA team can write source code and test cases using the functional spec as the reference. Suppose it is not a big project with complex functionalities to be implemented. In that case, you’ve been happily working with the team before, and there are no restrictions whatsoever - that’s it, happy sailing!
Otherwise, you may need another iteration on the requirements specification to make it a full-fledged comprehensive technical specification.
Whatever the format, a functional spec should enable both you (the customer) and the development team (contractor) to measure the degree of conformance. Both parties must achieve a consensus before writing source code or test cases, beginning debugging or making other time-consuming efforts.
Moreover, a good specification enables professionals to define the scope of work and provides a means for identifying options and risks early in a project - to decide whether it is worthwhile to set out with the map at all. Although a spec does not include cost information, it should help the development team estimate the job quickly and give you a more accurate quote.
A tech spec document is essential when a contract is issued: acceptance criteria defined in a tech spec can be enforced under the business contract terms. (It’s worth mentioning that one of a project’s success measures is often called ‘quality/specification,’ i.e. ‘specification’ means ‘quality,’ and vice versa.)
When experts write technical specifications, they list success criteria and add other essential factors, such as conditions under which the product must meet the specification, determine a life for the product, establish safety standards to be applied, etc.
Not surprisingly, the creation of project specification documentation has its own ‘specs,’ which professionals refer to as technical briefs.
It is a project outline or a list of participants and roles in a project. It should help you save time writing and ensure that all involved can understand your plan for the project early on and be prepared for it. A technical brief usually implies the following steps:
Every project specification is based on tech and engineering requirements and specific details of a particular project. Here is the list of what your project specification document should include:
Your development team should understand your customer’s identity. So you can include the following details about your company:
However, there is no need to go into extra details. Just give enough information for the contractor to understand your company’s goals and your project idea.
Consider this your project presentation. Outline the project idea, briefly introduce the overall concept, and explain why you are creating the project. Subsequently, it should include:
The more accurate the description of your end-user persona, the more chances you have to make the product your audience will love. The ‘end-user persona’ term refers to the fictitious profile of your end-user, with as much vital and relevant information about the product as possible, including age, gender, interests, income, etc.
Such information can be collected from various sources, such as:
You can identify your unique selling proposition through your primary and secondary competitors’ analysis and understanding of their strengths and weaknesses. Knowing your unique selling point will help you offer new value that might potentially beat your competition and help your product win the market.
Describe the project cost structure and where the funds come from. The development company you’re partnering with can help you with estimations.
Set a deadline by which the project must be completed, including the time required for each stage of the project, and set milestones to track the progress. You can request the help of your development team to set reasonable deadlines.
Translate project requirements into functionalities to describe how the software should perform and what each functionality should achieve. Describe each as follows:
This part is about the tech requirements that would meet the needs of your end-users. Explain what types of features in the new product your users will benefit from, and the project engineer will describe how to implement them to the team.
Here you can place details that the team will need to complete the project, e.g., wireframes, mock-ups, drafts, etc. It’s the reference point for them as they begin their work.
Project specification examples, like this one ‘Requirements Specification document for a new web-based sales system,’ can be found all over the internet. This one is detailed, but not every project document will look like this.
Here you can access a shorter example of a project specification document to develop that shows how to develop a forum for the library.
The following example contains a flow chart diagram outlining the product development process.
An adventure often starts with an idea, and a project specification document starts with core functional requirements, the ‘who’ and ‘what’ of a product - which means that virtually anyone can write them down. Or, you can skip the step, launch without a basic map, and hope for the best. However, in that case, beware
… Okay, the last is probably safe.
Do you need assistance with a specification? Are you confident about your ‘treasure map’? Are you looking for a reliable, seasoned crew? If you are contemplating a software project or would like an impartial review of your current product, drop us a line! The experts at Onix will be happy to offer professional advice.
A project specification is a complete description of a software’s functionality and purpose. It depicts how the software will be used and performance details, such as speed, availability, response time, etc. The critical issue it addresses is communicating to the developers what course of action they need to take.
While many organizations have moved to Agile and minimal requirements, knowing how to write a project specification document can be a benefit. The most common way to learn how to do it is by trial and error. Check examples listed in this article or search the web for more inspiration. There is no universal rule on how to do it, and every project specification document is pretty much unique.
Generally, the components may vary from one project specification to another, but the following components are universal:
A thorough technical project specification ensures the overall progress of the project and its compliance with a project proposal: