Capture and specification of requirements in software projects.

Requirements are the conditions that a product or service must meet in order to satisfy the needs defined by a customer, standard, contract, etc. They’re a fundamental component of any type of project, all the more so if we’re talking about software development projects.

In this article we offer you some best practice tips when it comes to the capture of requirements and recommendations to follow in order to obtain a good software requirement specification, enabling you to streamline the development of the whole project.

The importance of capturing and defining requirements in software projects

When it comes to software, the needs to be met can be defined by multiple stakeholders, such as customers, partners, operations departments, certification bodies, etc. And in many cases these needs are not entirely clear.

This is crucial, since the definition and management of requirements will have an impact on the entire project, determining its scope, the limits of the job, quality criteria, etc. Poorly defined requirements can lead to delays and errors. It is estimated that 40-60% of software errors are caused by a poor specification of requirements.

It is also important to bear in mind the cost of implementing changes to the project. While making modifications in the requirement specification phase is simple and economical, some studies indicate that making modifications in the project when it is already in more advanced phases multiplies its cost: x10 if they occur in the development phase, x20 in the final test phases and even x100 once the software is already in operation.

Capture and specification of requirements in software projects

Best practice in the capture and definition of requirements for software projects

As we have seen, there are amply-justified reasons for devoting the necessary resources to requirement gathering and definition. We’ll now turn to some good practice that can help you in this task.

Conducting surveys

The use of questionnaires and surveys is a very common formula for gathering information on the requirements demanded by users and customers. It’s a simple, fast and cost-effective way of pinning down information when both customers and developers are clear about the first-level requirements. In the event that this information is not clear or there are complex requirements that oblige further communication, this method is not sufficient and will have to be complemented with other techniques.

Group meetings

Talking directly with customers and/or users is necessary when the development team has no information about the requirements and needs to know the needs that the software must cover. It should be emphasized that in order for group meetings to be effective, the gathering and analysis of the needs of users and the context of their organization should be carried out in advance by means of reports, analyses, statistical data, etc. This enables the meeting to be much more focused, taking an understanding of the overall needs of the organization as its starting point.

Use of prototypes

The use of developer-created interface prototypes can help customers confirm that the software meets their requirements and detect possible new needs. This is especially useful when developers have a good knowledge of the industry and its features, while users do not have a clear idea about the requirements.

Internal and external research

Sometimes the information available is so scarce that it’s necessary to carry out a research process to obtain answers, and with these the requirements. For example, answering questions such as why does the customer need this software, what does the customer want the software to do, what have other companies done about it, etc. can provide important information.

Use of scenarios

Supplementing the previous point, the use of scenarios can help to map requirements when information is scarce. In a scenario, a case in which various actors use the system is put forward, determining which functionalities or characteristics the software must exhibit in order to be usable. Implementing different types of use in collaboration with the customer will help to provide an overall idea of everything they need the system to do.

Capture and specification of requirements in software projects

Characteristics of a good software requirement specification (SRS)

The document setting out software requirement specification (SRS) describes how the product will work, what it will do and how it will meet the needs of customers and/or users. It is therefore the outcome of all the earlier process of analysis and requirement gathering.

The SRS is the basis on which all systems engineering work is developed once the requirements have been defined. It is the goal to be achieved, hence its importance in the whole process. It is essential that the requirements are properly captured and analyzed first, and then appropriately accounted for in this document, which will serve as a guide for users and developers alike.

A good SRS should meet the following characteristics:

  • Be accurate: customers should see reflected here each and every one of the needs they expect the software to cover.

  • Be complete: it must include requirements at all levels: functionality, design, attributes, etc.

  • Be consistent: in other words, avoid having mutually conflicting requirements.

  • Be unambiguous: each requirement must have only one possible and unequivocal interpretation.

  • Prioritize by importance: requirements should be ranked in order of importance and stability by means of a clear identifier.

  • Be modifiable: projects may undergo modifications, so the SRS must enable changes or extensions to be added.

  • Be verifiable: such that fulfilment of the requirements can be checked and verified.

  • Be traceable: so that the origin of each requirement may be known during development or future changes.

  • Be independent in terms of design: so as to allow the selection of several technical alternatives for the creation of the system.

  • Be testable: enabling the creation of tests for analysis in a simple way.

  • Be understandable: especially for the customers, bearing in mind that they may not be experts and they will use this document to check that it includes all their requirements.

Centum, your partner for software development projects

CENTUM Digital has more than 16 years of experience offering Critical Systems Engineering services in the most demanding environments, such as the Aviation, Naval, Defense, Railway and Automotive industries, mainly oriented towards Certification, Safety, Environmental Qualification and HW/SW Assurance processes. If you want more information about our services you can contact us.

Critical Systems Engineering

At CENTUM Digital we have more than 16 years of experience offering Critical Systems Engineering services in the most demanding environments.
Share on facebook
Share on twitter
Share on linkedin
Centum

Centum

Artículo propiedad de CENTUM Solutions, S.L

You want to know more? Contact us

We are digital, and that is why we know the value of a conversation between two people. Please, if you have any questions, have any suggestions or just want to talk to us, contact us through any of the channels we offer you. You have our commitment that we will not use your information to send you SPAM, we like it as little as you do.

NEWSLETTER

Do you want to know the latest news? Subscribe

Would you like to be the first to know what is happening in the sector? In our newsletter you will discover everything.


Loading