Do you sometimes wonder how software engineers turn "words" into working software? Precisely, how do they ensure that the end product meets the employer or client expectations?
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 kind of the "entry point" from which software engineers start designing a piece of software.
We express functional requirements in terms of:
Data storage.
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:
Performance: for example, the number of transactions that the software should do in a day.
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)[1] is the process of defining, documenting, and maintaining requirements[2] 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:
✅ 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.
Fewer defects.
Minimized risk for safety-critical products.
Faster delivery.
Reusability.
Traceability.
Requirements being tied to test cases.
Global configuration management.
CONCLUSION
In this article you've learned about:
✅ What is a requirement.
✅ Functional and non-functional requirements.
✅ What is requirements engineering.
✅ The cost of requirement engineering.
✅ Why do projects fail.
I hope you've enjoyed this article.
If you enjoy my content, please consider subscribing to my newsletter.
Follow me on LinkedIn or Twitter
Until next time! 👋🏾
P.S: did you enjoy this article? If so, I invite you to subscribe to my newsletter. I share interesting stuff around career development, software engineering and technical writing.
ADDITIONAL RESOURCES:
IMAGES
ARTICLES THAT YOU MAY ENJOY READING
Top comments (0)