Whether your development team is using the Waterfall, Agile or iterative model, every piece of software that you release usually goes through a development model, or Software Development Life Cycle (SDLC), which includes a chain of activities that ultimately lead to a software release.

A classic SDLC would include several phases: requirements, design, coding (also called implementation), testing, deployment and maintenance. Deployment covers the final release of the software (like for example the release of a 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 and how.

At Advantio, we like to refer to the SSDLC, or the Secure Software Development Lifecycle, hence a securely implemented version of a standard software development model. We will try to cover a few aspects of the SSDLC in this article, mainly concerning its requirements gathering phase.

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 address. 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?

While software 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 security 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:

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, observation of the field and ultimately industry validated resources.

Secure Software Development Life Cycle requirements phase.

 

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

I am the CTO, Senior Security Consultant, and PCI QSA since 2010 at Advantio.

Having executed close to a hundred (and counting) assessments across Europe, Asia, South Africa, and North America, I was able to observe many different implementations of all classic security controls and much more.

Now I spend much of my time with cloud technologies. Being passionate about cloud security and cloud resources management, my research focuses on the implementation of streamlined and scalable processes in the field of Threat Management for cloud-based ecosystems.

At Advantio, I am also part of the ZeroRisk team. Our vision is to make security and compliance simpler for our users.

Schedule a call with an expert