Software Development Life Cycle (SDLC)

Did you ever want to know how each process in Software Development Life Cycle is handled? Did you ever find the contents on the internet to be too
generic? If so, this article is for you. With this series of articles, we will be explaining each process of SDLC and giving practical examples for each of them. Be ready; this and other articles in this SDLC series are not general and will give you only specific information.

There are multiple steps that need to be accomplished even before starting actual software development. The whole customer journey, from beginning to end, needs to be analyzed carefully so that this journey can be personalized according to customers’ experience to streamline their decision journey.

In the lead discovery phase, the requirements engineering process begins. This is the phase where Business Analysts start gathering requirements (Requirements Elicitation), which is an initial step of Requirements Engineering.

Later on, when we start gathering requirements for the software, we will be preparing documents like Statement of Work (SoW) and Technical Specification Document (TSD), which are included in the documentation package. The process of writing SoW and TSD will be explained in our next articles.

Now, let’s imagine that the client is ready to start. Would it be a good idea to straightly jump into the design stage? The simple and short answer is no, the long and complex answer is that there are a few steps of the Requirements Engineering phase that need to be accomplished before jumping into the design stage.

In the later part of Requirements Engineering there are steps like Requirements Validation, Stakeholder Analysis, and Interface Prototyping, to name but a few.
This article was intended to give only a short introduction to a series of articles in the SDLC series. In the next articles, we will be highlighting each touchpoint of the customer journey depicted above.

What is Statement of Work (SOW)?

Imagine you want to hire a software development company to build the software you want. How do you make sure that you choose a reliable company that understands all of your requirements and a company that is capable of meeting your requirements? And how do you ensure that all expectations and requirements are fully documented even after choosing the company? Statement of Work (SoW) comes for help with such struggles. This article is aimed at explaining why a Statement of Work (SoW) plays a crucial role in the software development industry.

Purpose of the SoW Document

The purpose of SoW is to cover and document all the requirements and information about the project and to regulate the agreement between the two companies. It documents all responsibilities of both a software development company (project requirements, technical requirements, timeline, etc.) and a client (payment schedules, terms to collaborate, etc.).

It is very important that the software development company you have chosen provides you with highly-detailed SoW. Otherwise, there is a high chance that there will be a misunderstanding between the two companies throughout the entire project life cycle. SoW boosts cooperation and minimizes the conflict and confusion between two parties.

SoW is a business document rather than a legal one. But still, the importance of the SoW shouldn’t be underestimated because it defines and documents every bit and piece of the project. That is the reason why we regard SoW as an important part of the requirements engineering phase of the project.

Who will provide SoW Document?

In other industries (i.e. construction, healthcare, etc.) SoW is prepared by the party who is requesting service (client). But in the software development industry SoW is usually prepared by the software development company itself. Because not the client, an outsourcing vendor is the one who can prepare and deliver high-quality SoW with detailed project information.

At NovaLab Tech, we prepared our custom SoW template and we deliver highly-detailed SoWS for each project regardless of its size. Below there is an example of the custom SoW template we have prepared. You can also access our open-source SoW here.

What is included in SoW in the software development industry?

What is Scope of Work and is it the same with Statement of Work?

The process of defining the scope of the project is called preparing Scope of Work and it is considered to be an important component of the project. Although the terms “Scope of Work” and “Statement of Work” are used interchangeably by some people, this doesn’t necessarily mean they are the same terms. Scope of Work is only a crucial component of Statement of Work and correspondingly, Statement of Work means much more than Scope of Work.

The purpose of the Scope of Work is to define what is included in the project. If we look at the core meaning of the word “scope”, we can find out Cambridge Dictionary’s definition of the word “scope”:
the range of a subject covered by a book, programme, discussion, class, etc.

So, the purpose of the Scope of Work is to clarify the range of the features covered by the Statement of Work that is prepared for the project.

Summary

To summarize everything, the Statement of Work is an important part of requirements engineering process and it serves as an collaboration tool between a client and a software development company. It provides both parties with a shared and common understanding of the project. It can also serve as a legal document to make an agreement between two parties.

We, at NovaLab Tech, have created more than 150 SoWs for startups and organizations all over the world. So, as the company who have dealt with so many SoWs, we can say that SoW serves as a differentiation point that separates a successful collaboration from a failed one.

What is Technical Specification Document?

In the last article, we explained what is Statement of Work. Writing a Statement of Work is an initial step of the Requirements Engineering Process in the Software development life cycle. Statement of Work is the first document that is included in the documentation package in the software development industry. While SoW is mainly for external stakeholders (product owner: the client), Technical Specification Document is for both external (product owner and investors) and internal stakeholders (project managers, engineers).

Let’s imagine all the requirements of a project have been documented and confirmed by the client and both parties are ready to move on to the design and development of the project. In such a situation SoW itself wouldn’t suffice for starting the actual development of the project because SoW clarifies the business requirements of the project. Jumping straight into coding isn’t actually a good idea if you want to launch a successful project. Before jumping into coding there is a need for Technical Specification Document.

The purpose of the TSD document

While SoW outlines how we are going to address business problems by technical features, the TSD outlines how we are going to address technical problems via design and development. By breaking down the scope into components, organizing them, and time boxing all the work that needs to be implemented during the project, stakeholders will get a better picture of the technical solution. By writing TSD you will create common and shared documentation so that you don’t have to repeatedly explain the project to teammates and stakeholders.

TSD also increases collaboration within the team because all of the team members will actively participate in the process of writing specs and the collaboration will give them a sense of ownership and increase their responsibility for the work.

Chart 1.1 explains what is used as an input to writing TSD. As stated above not only the SoW document but also regular meetings with external as well as internal stakeholders will be used as an input to writing TSD.

What will be included in Technical Specification Document?

TSD serves as a central repository for all documents and materials related to the project. Notion is a great tool to write TSD since it is a great place to collaborate with the team and it has integrations with many other PM and BA tools (Miro, Github, Slack, Google docs, Google drive and etc.), which means you can open these tools staying within the software and can have your job done just in a single place. At NovaLab Tech, we usually draw a business flow chart for the project and integrate it into Notion so that all stakeholders access it in the same place when needed.

In a nutshell, Chart 1.2 explains what can be included in the content of the TSD:

Conclusion

Writing TSD is an important part of the Requirements Engineering (RE) process. TSD concludes the RE phase and helps all team members smoothly move on from one phase of the project to the other. TSD requires time and collaboration but it is a great investment to make your software successful and impactful.