ARTICLE

The importance of software requirements

“Working software over comprehensive documentation” is a statement that is part of the Agile Manifesto. At a quick glance, this statement may insinuate that documentation isn’t required or worthy when creating software. However, this is a mistake to think that. What this statement implies is that it is all about striking a balance. We do not want developers or software engineers spending their valuable time creating onerous documentation. But we do need them to capture information that is practical, informative, quantifiable, and fits within the agile philosophy.

When it comes to creating software for a new product this couldn’t be more important. How will the software engineers know what to create if there aren’t correctly documented requirements? How will the test engineers verify the software is operating as originally intended? How will the project managers know when the software is completed without having a set of requirements to work toward?

Firstly, let’s recap what requirements are in terms of software development.

Requirements specify what features a product should include and how those features should work. They help to define the test criteria, which is vital for verification and validation.

At the beginning of the software development process, collating and analysing the requirements is one of the first tasks to be done. This usually takes place between the client, software engineer, and tester. All three stakeholders, must come to an agreement as to what the final product should do and how. In addition, to understanding how the product will be verified and validated according to the requirements
set out.

This activity takes place when creating a new product as well as when modifying or making changes to an existing product. It enables the work to be quantified and bound providing the scope for the project.

This activity of defining and verifying requirements takes place in both agile and waterfall methodologies.

There are several types of requirements that should be considered when it comes to designing or modifying software. They each depend on what the product is. These are: business requirements, software requirements, and hardware requirements.

These outline the business case and reason for making the product in the first place. If a company doesn’t have a business case that stacks up then why is the company investing money and time into taking the
project on further.

Also known as stakeholder requirements, they describe the characteristics of the proposed product from the point of view of the end user. They don’t define what the system should do or how it should be done, but instead they define the ‘why’ requirements. For example, why does this customer need your product? It sets the tone and vision for the product.

These can be categorised into Non-Functional and Functional requirements. The difference is as follows:

Functional requirements are the ‘what’ requirements. They outline what is the system designed to do. For example, say you were a medical company looking to develop a COVID testing device. The types of functional requirements, which might exist could be that the product must be able to identify a COVID test or the product must display a positive or negative test result to the user.

Non-Functional requirements are the ‘how’ requirements. They outline how the system will do what it is designed to do. For example, the product will run a COVID test within 20 minutes and the device will send results via Bluetooth to the end user’s mobile phone.

Both set of requirements are important as they provide input into what will be required for developmentand testing.

These are the requirements that a required to develop and create a hardware device. Sometimes a product is completely software-based and so they may not be needed. But if your company is making a physical product then there are many aspects to consider before designing and making the device.

There are many aspects such as what processor speed is required, how much memory is needed, what shape will the product take that all need to be reviewed. Hardware and software requirements need to be considered together to determine the software compatibility for the system being designed.

Requirements need to be established and bottomed-out at the beginning of development so that there is a clear path to verification and validation. Without a view of how to verify and validate the product then there is no sure way to claim that it is of good quality and ready to be released to market.

Requirements are fundamental to the verification and validation as they help test engineers to design and implement test strategies across the entire development cycle. Verification testing takes place as new software is built and released. Several test methods are used to verify that the software is being built correctly according to the requirements and design specifications defined. Validation testing is completed in parallel, with the aim to check whether the product satisfies both the market and business requirements. This is equally important as it determines whether the product designed will meet the users needs one it has been placed in the intended environment.

Iterative agile processes means that changes can be introduced at any stage of development. At AND, we implement agile methodologies and are therefore experienced in development taking a slightly different path if the requirement arises. Working closely, with clients to discover requirements and develop solutions through a collaborative approach is part of AND’s ethos. This means that software engineers, testers, product owners, and quality assurance is involved in the process of capturing and reviewing requirements.

Process for capturing requirements implemented at AND

One important activity, that often can be forgotten is making sure that the requirements have firstly been verified before that are actually verified. This de-risks the development process as both engineers and clients know from the beginning that the requirements are both achievable and verifiable. The software requirements document is a living document and can only be verified once the software is tested. Unlike the waterfall model, which is a linear life cycle model, for example define requirements, then develop, then do all testing, and then release. Agile processes allow greater flexibility and communication between stakeholders. This means requirements can be changed once development has started permitting the opportunity to catch bugs earlier in the process.

If we don’t have requirements that are properly captured then this can lead to a multitude of problems. Usually, the first place to find the pain point is with the testers as they will have the tricky job of trying to work out how they are going to test a product without no clear guidance on what or how it is supposed to operate.

Not only will you have angry testers on your hands, undocumented requirements can lead to:

• • • • Software not implemented correctly.
    • • Gaps in functionality across the system.
    • • Hardware that isn’t operating as expected.
    • • Project managers with no idea whether the product is finished.
    • • A customer unsure of what to expect or pay for.
    • • Software engineers left in the lurch.
    • • A system littered with bugs.

Even a set of really detailed requirements can be inconsistent and this is partly to do with miscommunication. The number of times a software engineer and a client will use the same language yet their understanding both completely misaligned. This can lead to significant delays, rework, and bug fixes within the project.It is imperative that all parties understand the product and the process of its development to ensure the project runs smoothly. No question is too ‘dumb’ and breaking the communication barriers will help in the long run.

The way in which requirements are captured and the level of detail that is documented can differ between companies. Some businesses require hefty documentation, while others like to keep information high level and minimal. Whatever approach taken; the information recorded needs to be clear and concise ensuring that the technical detail is correctly noted.

Some things to consider when planning and managing requirements capture:

• • Accurate. Sounds simple but the requirements should be accurate. They need to be checked and agreed between client and engineers.
  • Unambiguous. Use language that is clear and concise. It is so important to eliminate the risk of miscommunication.
  • Reliable. Make sure that statements within requirements do not contradict each other.
  • Verifiable. All requirements must be able to be tested. They should be quantifiable and measurable at a unit, function, and system level.
  • Modifiable. The structure of the specification document should be easy to update and maintain.
  • Traceable. Requirements should be easy to identify and traceable across the entire system.
  • Communicate. Champion communication between client and engineers. Keep an open dialogue and have a collaborative mindset.

Requirements won’t be captured perfectly first time. The level of detail that an engineer wishes to capture will differ depending on the project and every customer will want it presented to them in a different way. But welcome flexibility in processes and be open to change – as this could save headaches as well time and money later down the line.