Have you ever wondered what is a "requirement" in software engineering and why we need them in the first place?
This article is for you, then.
Let's dive straight in.
What Is a “Requirement”?
A requirement in software engineering is a feature of new software that someone either wants, needs or commands.
It describes what the software does and any limitations it should have.
What’s the Goal of Determining a Requirement?
We can ask these four questions:
What do we want the system to do? In terms of storing data, any processes, and the behaviour.
Who are the users of the system?
What are the needs of the users?
What does the system need to do to achieve those needs?
Requirements can be split into functional and non-functional requirements.
What Is a “Functional” Requirement?
A functional requirement is a requirement that describes what the software does.
It's the "entry point" from which software engineers start designing a piece of software.
We express functional requirements in terms of:
Any processes that transform data.
Any outputs that it can produce.
What Is a “Non-functional” Requirement?
A non-functional requirement defines any limitations that the software may have.
We express non-functional requirements in terms of the following:
Performance: for example, the number of transactions the software should do daily.
Security and access: it should comply with the law.
Technical constraint: run on an existing network.
Project constraint: the software should be ready within a set period.
Organisational constraint: the software should be teachable to new staff in a short amount of time.
Usability and reliability issues.
Analysing and categorizing requirements is part of requirement analysis, also known as requirement engineering.
According to Wikipedia :
Requirements engineering (RE) is the process of defining, documenting, and maintaining requirements in the engineering design process. It is a common role in systems engineering and software engineering.
What’s the Output of Requirements Analysis?
The main goal of requirements analysis is to create a document that describes the software system to be built.
Requirements analysis produces the requirements specification document.
A requirement specification document contains the following:
An overview of what the system should do.
A description of the requirements.
A list of the functional requirements.
The requirements specification document doesn't contain:
Any information about the algorithms and logic.
Description of the User Interface.
Any detail about data entities.
Meaningless technical specifications.
Poor requirements engineering is one of the reasons why a software engineering project can fail or produce a highly defective piece of software.
A popular example that I remember is the one of the 🚑London Ambulance Service.
As for the software itself, three primary flaws hampered things from the start: It didn't function well when given incomplete data, the user interface was problematical and — most damning — there was a memory leak in a portion of the code.
A software project can fail for many reasons:
Miscommunication and misinterpretation between management and employees.
Poor testing practices.
Poor User Experience.
Unwillingness to change direction.
Complex to use.
What Are the Benefits of Good Requirements Management?
This article from IBM explains it gracefully:
Lower cost of development across the lifecycle.
Minimized risk for safety-critical products.
Requirements are tied to test cases.
Global configuration management.
Related: Why Do Software Projects Fail?
In this article, you've learned about the following:
What a requirement is.
Functional and non-functional requirements.
What requirement engineering is.
The cost of requirement engineering.
Why projects fail.
If you choose to land a software engineering job, you'll hear a lot about "requirements", so I hope you've enjoyed this article.
If you enjoy my content, please consider subscribing to my newsletter.
Until next time! 👋🏾