Required timeframe with specified milestones

One of the most important parts of the thole product specification is it's estimated timeframe. Knowing the amount of time that is at our disposal when developing, lets us properly estimate the correct team size and composition. Some parts of the custom software development process cant go faster than it's physically possible, but we can align with the required measure by adjusting the development team composition.

Make sure to include all the crucial milestones of the software development project, if there are any. It's great if we know that the whole development process has to conclude in, say... 18 months, BUT, we NEED to know that you are supposed to report the progress to the Venture Capital every 3 months. We have witnessed projects that failed because that kind of fact was communicated after a couple of SCRUM sprint, and the investor has cut off the financing because of the misdelivery of KPIs. The worst part is, that the issue would be avoidable if the customer notified the dev team about the VC checkups. The entirety of the software development process can be adjusted. If there is a certain feature, which implementation is going to be measured, please let us know!

The business goal of the project

Even the best Idea, is just that - an idea - if it's not established in the actual reality. In particular - in business reality. One of the most important parts of the bespoke software development process is the Business Analysis. The BA engineers that will be the first people you will work with when creating custom software, will spend a lot of hours checking whether your idea is viable from the business perspective.

The process is not going to be free of charge, but thanks to spending a modest amount of the budget at the initial stage, you will potentially save a lot. By avoiding the development of the features, or even entirety of the project, if those are not feasible from the economical standpoint - we will let you know. At codelabs.rocks, we believe that the harsh truth is much better than pink-colored falsehood, and we will never go into actual development if we know that the final effect will be disappointing.

Use case scenarios

While there are many different "ways" to write down the project specification, one of them gives the best results. If you approach the creation of the custom software as you were it's final user, you will be able to create the most efficient and down to earth description of its features. Try to avoid being a technical guru that goes into details about the software technologies that are going to be included. Our BAs and project managers will do that part - they will communicate with the lead developers and assess which tech is going to be best in the case of your project, and the teams will develop accordingly. You need to provide a clear and understandable description of the desired effects of the user's actions. Be blunt and direct. Write down what should the user achieve when interacting with a particular part of your software.

i.e.: "By typing in a keyword into the search form, and clicking the button, the user receives a list of top 10 matches from the app database, ordered by the date the matches were added, with the preview of the other user's comments to those matches"

That way of describing the interactions simplifies the creations of so-called "USER STORIES" which are key elements of the SCRUM method that we use in codelabs.rocks. If the specification of the software project does not include the use of case scenarios, the development teams will have to create those themselves, which in effect will consume some part of the budget, and in the end, might turn out to be not 100% effective. 

 Essential, key processes

Some elements of your software are more important than the others. We know it's a truism, but it has to be said aloud: Let us know, WHICH parts of the software are essential for the whole project. You, the person that has the best knowledge about the environment of the future app, knows best what it has to include to make it work. Our Business Analysts will help out with mapping its particular parts - but we need to know if there is something ESSENTIAL. We know that there are certain situations in which even the features that are disqualified in the analytical process have to be included nonetheless.

If the project is co-financed by the government capital or European fund, it might be necessary to develop parts of the software, that seems not really crucial, or even unfit for the project.  If we know that there are other stakes to consider, we will be able to align. So again, as in the case of KPIs - NOTIFY us about the existence of such elements. 

The division into modules

Sometimes, especially in the case of more complex bespoke software projects, the specifications document can reach more than 100 pages. If the intricacy level of your idea is very high, it will be much better if you subdivide it into "modules".  Consider major parts of the application, to be individual software solutions that can be implemented by themselves, without reference to the others. If the features are broken down into segments, it's much easier to estimate the number of resources that have to be employed to make them work. That in effect translates to more efficient development - which to say bluntly - is just cheaper for the customer. 

Step-by-step descriptions.

While it's not essential for a specification document, its definealty something that is nice to have. If you spend additional time to break down the particular features into step-by-step descriptions, you get two different benefits: 

  1. You EXACTLY know how the interaction with a particular part of the software will/should look like. There will be no time wasted to go deeper should additional questions appear. 
  2. You can figure out potential problems and challenges in advance. This will ensure no mistakes are done during the development phase, and no resources will go to waste.

To do this efficiently and effectively, try to get images you are explaining how your custom software works, to a person that has limited experience with using the internet and even a computer. Try to write something that looks similar to:  "You click on the button - button turns red - new website appears".