Software Specification SRS - Your project cornerstone
Everything has its beginnings. And at Techs we know that good Software Requirements Specification SRS can be beneficial for any size or scope project.
Transformation of Business Requirments
Are You able to evaluate the complexity of Your project ? Are You sure that Your project description is good enough so the software house can construct for You a reliable project quote ? I saw it many times when people were providing a brief list of functionalities and expecting to get reliable project quote. But in reality what happens is, when You put trash in You get trash out.
Of course there is a set of exceptions to that rule. Number one, creation of the software that operates within the scope of existing platform, like creation of a bot for slack, slack exposes a software development kit for developers, it is a toolbox that allows You to construct a software in one of available and valid ways. In that situation a user interface (“frontend application”) is already existing, what You need to create is a backend service that listens on slack users commands in real time and executes business logic.
Number two, low number of parts that needs to be integrated, at Techs very often we have projects which require only backend development. Most of the problems and extra time consumption is appearing during the integration part, when our project is purely backend like creating an api that receives a request and triggers PDF generation. Technically this task may be challenging for a not experienced developer as it will require creating infrastructure on the cloud, integration with third party services, creating serverless code which will simplify project architecture but its business logic is very simple and does not require user interface to be created.
Transformation part is about materializing to some degree Your idea, giving a structure to it, so other people may find information easier and answer Your questions with better accuracy. Believe it or not but even a simple login/logout use case requires some thinking and questioning. Do we need two factor authentication 2FA, should the session expire after predefined time by default, can users have 2 tabs opened or 2 active sessions, maybe subscription is not allowing on that.
And don’t get me wrong, this is not done in order to accumulate a big pool of tasks and invoice more hours, actually this is opposite. At Techs we are always challenging and questioning client ideas, and our goal here is to simplify the project and refocus the project budget on most critical parts.
Clear Requirements
What You expect from the team or what is Your project purpose will be most of the time not clear to a people You work with and it doesn’t mean necessarily that they are not passionate about working with You, it may just mean that they operate on a different layer, maybe are more technical and have difficulties with grasping business requirements or functional requirements but this doesn’t mean You shouldn’t consider them as part of Your project, there is not so many people who perform well in all roles related to software development.
What I wanted to say here is that people will not share Your vision until You will not explain it well to them, and this is very true for project development. At Techs we start the full development cycle always from the software specification and there are many reasons behind it. Functional requirements are the glue between the business and technical world, that’s how it starts.
On top of that we add use case diagrams or designs to show the flow of the feature, next all of that is passed to developers who need to create a task that will cover implementation of the feature. Now, based on my programming experience, I worked on a feature so many times and I was not sure if I am covering all requirements or if I am implementing it in the right way, and in most of the cases the reason behind it was a missing business information.
We are all working in very rapidly changing environments, try to put Yourself in developer position who has technical skills but is now blocked by lack of understanding of business requirements, because project is now going super fast, developer is asking to a business analyst team but they don’t know too because requirements changed multiple times, and maybe finally developer find somebody who worked on the project 1 year ago and will be able to answer the question how something should work, and this is the real situation.
At Techs we can as well restore software specification from the code base, the process is more difficult but we went through it already.
Reliable Quote
Software specification is covering multiple layers of Your project and its primary focus should always be on the most complex part. It clearly states what needs to be done, listing all functional requirements and technical requirements, architecture and infrastructure diagrams.
Sometimes it may be supplemented by database design, backend service schema (REST API schema), designs, vocabulary and terminology from project scope.
The conclusion sounds like that, better You explain what is needed and a more accurate answer You will receive from the software team. And let’s be honest here no software house is spending too much time on initial project quote as they are not sure about Your goals or how serious about developing the project You are.
Showing a specification document means that You invested Your time and money so You are serious about that, additionally possibly You were given a well grounded expertise by somebody, so software teams will be more transparent with You.
Example
You can find a brief explanation here of how software specification is helping in project development.