# What Is A "Requirement” in Software Engineering? 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. > Requirements Engineering is the process of establishing the services that the customer requires from the system and the constraints under which it is to be developed and operated.\[[The University of Edinburgh](https://www.inf.ed.ac.uk/teaching/courses/ip/CS2Ah0405-SoftwareRequirements.pdf)\] 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 align="center") 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: * 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 align="center") ## 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](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 align="center") 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. ![image.png](https://cdn.hashnode.com/res/hashnode/image/upload/v1642093558696/gHZRp1AbF.png align="center") 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 align="center") > **Related:**[Why We Need Architectural Design In Software Engineering](https://techwithmaddy.com/why-we-need-architectural-design-in-software-engineering) ## 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 are tied to test cases. * Global configuration management. > **Related:**[Why Do Software Projects Fail?](https://techwithmaddy.com/why-do-software-projects-fail) ## **Conclusion** 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! 👋🏾 **Additional resources:** * [Why do software projects fail?](https://techwithmaddy.com/why-do-software-projects-fail) * [Why We Need Architectural Design In Software Engineering](https://techwithmaddy.com/why-we-need-architectural-design-in-software-engineering) **IMAGES** * ***Software specs*** * ***Inefficiency*** * [*Software Already Done*](https://dilbert.com/search_results?terms=software) * ***Bad User Interface*** * [*Common sense*](https://dilbert.com/search_results?year=2020)