Whether your development team is using the Waterfall, Agile or iterative model, every piece of software that you release goes through the Software Development Life Cycle, which also includes the work your team does pre and post release.

secure-sdlc-requirements-phase

The classic SDLC includes several phases: requirements, design, coding (also called implementation), testing, deployment and maintenance. Deployment covers the final release of the software (or the release of the Minimum Viable Product), maintenance and testing cover bug busting after your software has been released and as it is being developed (respectively). Coding and designing involves building the structure of your software, while the requirements phase tells your development team what they should be building in the first place.

What is the SDLC requirements phase?

The requirements phase is where you decide upon the foundations of your software. It tells your development team what they need to be doing and without this, they would be unable to do their jobs at all.

The list of 'requirements' of your software should address who your customers will be and what needs of theirs your software is able to solve. For example, which demographics do they fall into; are they old or young, what's their gender, what do they already know and what are the issues that they face in their day to day life? You also need to know how they'll be using your software, what sort of information they need to put into it, as well as the outcomes they'll get from your software.

Once the list of requirements has been put together, the team will need to finalise and approve them, analysing each and every one on its ROI (Return On Investment) and whether it provides the user with genuine value or not. Following this, the list can be sent off to the design team who can put together their own specifications ahead of the coding work in SDLC phase three.

Who should participate in the SDLC requirements phase?

The participants of the requirement phase will vary from company to company; each one will have a different hierarchy including people of varying levels of knowledge. But as a general rule of thumb, the requirements phase should include everyone with a solid knowledge of how to cater to the needs of the customer, along with everyone who is involved in making key business decisions.

For example, the CFO (Chief Financial Officer) is a beneficial feature at requirements phase meetings as they will be able to figure out just how much development is going to cost. They can use their understanding of the company's financials to suggest which features are going to be the most lucrative, which are going to need a significant investment to implement and what the company's stakeholders have said that they require from the software too.

Meanwhile the CTO (Chief Technology Officer) or the IT Manager will need to step in and explain exactly what they need from the software, technology-wise. This may include detailing the limitations of the hardware that the software is limited on and figuring out which of the requirements detailed by other team members will be possible within the realm of the technical specifications. They may even have extra requirements that are necessary in order for the software to run smoothly on the hardware as well.

Furthermore, those who have direct contact with your customers must also be included, e.g Community Managers. These people have their finger right on the pulse and know exactly what your customers want as they interact with them daily.

What is the role of Security in the requirements phase?

But, while these requirements are sure to make your software appeal to the customers (and indeed, appease the stakeholders too) this matters very little if your software isn't secure. Proper software security should be considered right from the very beginning; to ensure that your software's foundations are made of sturdy bedrock, not unstable bricks and sand.

Security can be considered during the requirements phase with something we call the 'Secure Software Requirements'. The Secure Software Development Life Cycle Requirements phase takes into account the resiliency, the reliability and the recoverability of your software. Is your software resilient from attacks? Is your software reliable when it’s under attack? And can your software recover quickly from even the most advanced attacks? These questions require attention and experience, this is why a security expert is a key role during the requirements phase of your SSDLC project.

Takeaways about SDLC requirements phase

It is absolutely crucial that you consider security during the requirements phase as it means that your developers will be creating the product with software in mind. By doing this, security won't be an after thought.

  • Your protections will be embedded into your software every step of the way. Your software will be far less likely to have potential attack vectors as your development team will have taken the care to eliminate them (or not include them in the first place) and remove the possibility.
  • You will avoid customer information being stolen or having your network compromised which would result in a disaster for your business. You don't want that headache and neither do your customers and stakeholders, which is why it's all the more important that security is one of the first things on your mind when crafting the requirements list.
  • Adding security tasks during the requirement phase is a more cost effective solution than looking at an insecure code once the software has already been developed. Including security from the beginning of the SDLC can help your organization save time and guard your budget.
  • Make sure that your developers get the right tools to do their work. You need to be able to develop secure code, so help your team getting the right SSDLC training and learning how to handle static analysis of source code.

You need to have a well trained team to develop secure software

We here at Advantio understand that your development team may not have implemented Secure Software Requirements before which is why we offer several different methods for making your software more secure.

We can review your software's code for you, we can evaluate the Software Development Lifecycle to ensure that your team is taking the right steps towards secure software and we can also train your team so that they have a better understanding of Secure SDLC (SSDLC) concepts and practices. 

End note about this article

I have taken part to a few discussions about software requirements during my career and I find it extremely important to involve all the possible roles in this stage of the project. Unexpected input and a 360 degrees view can be achieved only when all the points of view and opinions are shared. The content of this article is based on personal experience and interviews that I have run within the Advantio team of SSDLC experts.

Igor Mancini

Written by Igor Mancini

Marketing Director at Advantio. The articles published in the Advantio Blog have the goal of supporting our mission: making IT Security simple for everyone.

My intention is to discuss IT Security related topics with the eyes of a non technical person, speaking a simple language and trying to show to the readers the benefit of IT Security best practices.