What Is A "Requirement" in Software Engineering?
Published: 2022-01-17 10:20:00

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?

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1642093358523/a7gf5N0Ml.png)

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.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1642093114323/vFlIq8Rk_.png)



**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](https://en.wikipedia.org/wiki/Requirements_engineering) :

> 
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**.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1642092961153/o59Gx-NaN-.png)

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.

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1642093558696/gHZRp1AbF.png)

A popular example that I remember is the one of the  🚑[London Ambulance Service](https://www.wired.com/2009/10/1026london-ambulance-computer-meltdown/).

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

![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1642092543584/w77ASD6qv.png)

**What are the benefits of good requirements management?**

This [article](https://www.ibm.com/topics/what-is-requirements-management) 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](https://www.linkedin.com/in/maddalena-o-bb2372020/) or [Twitter](https://twitter.com/Maddy_Onyehara)

Until next time! 👋🏾

P.S: did you enjoy this article? If so, I invite you to subscribe to my [newsletter](https://techwithmaddy.com/newsletter). I share interesting stuff around career development, software engineering and technical writing.

**ADDITIONAL RESOURCES:**

-  [MindStudios - Why are requirements important](https://themindstudios.com/blog/why-are-requirements-important/) 

-  [DZone - The Importance of Requirements](https://dzone.com/articles/importance-of-requirement) 

-  [freeCodeCamp - Greg Byrne: Why You Need to Understand Software Requirements as a Software Engineer](https://www.freecodecamp.org/news/why-understanding-software-requirements-matter-to-you-as-a-software-engineer/) 

**IMAGES**

- [*Software specs*](https://dilbert.com/search_results?terms=software)
- [*Inefficiency*](https://dilbert.com/search_results?year=2020)
- [*Software Already Done*](https://dilbert.com/search_results?terms=software)
- [*Bad User Interface*](https://dilbert.com/search_results?page=11&terms=User+Requirements)
- [*Common sense*](https://dilbert.com/search_results?year=2020)  

**ARTICLES THAT YOU MAY ENJOY READING**

- [Ten Rules to Refactor Code](https://techwithmaddy.com/ten-rules-to-refactor-code)

- [Brief Introduction to Scrum](https://techwithmaddy.com/brief-introduction-to-scrum)