May 16, 2014
Requirements are the rules that make software possible; they’re the building blocks upon which software is developed. Not only do they keep developers on track...
Requirements are the rules that make software possible; they’re the building blocks upon which software is developed. Not only do they keep developers on track as they build the software, they’re also important for testers to keep in mind. In fact, the definition that most people give for functionality testing is “ensuring that a software meets its requirements in the most efficient way possible,” and many other types of testing are performed while keeping the system’s technical requirements in mind.
Put simply, software requirements are a list of conditions or capabilities which ensure that the software meets the needs it was designed to address. According to Wikipedia:
Software Requirements is a field within Software Engineering that deals with establishing the needs of stakeholders that are to be solved by software. The IEEE Standard Glossary of Software Engineering Technology defines a software requirement as:
- A condition or capability needed by a user to solve a problem or achieve an objective.
- A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
- A documented representation of a condition or capability as in 1 or 2.
The process of defining requirements can be broken down into four steps: Elicitation, Analysis, Specification, and Management. Elicitation is the process of defining the needs which the software must address. The process of Analysis follows, wherein the elicited results are further honed to create a more detailed understanding of the requirements. Specification involves translating the analyzed results into well-organized standards, such as use cases or user stories. Finally, Management is keeping track of the changes the requirements undergo during the software development process and ensuring that the initial stakeholder needs are met.
A simple way to think of requirements is to break them into three categories:
- Technical requirements: these spell out exactly what is needed and how it should be performed it, but not necessarily the desired end-game functionality.
- Business requirements: desired outcomes without the instructions, such as “user must enter a valid email.” These leave a lot up in the air and up to the tester’s discretion, for better or for worse.
- Unrealistic hopes: sounds a bit harsh, but these are what the client really wants to system to accomplish, without necessarily considering how or why it should do so. Typically these lack the detail necessary to actually be achievable.
For testers, software requirements are vital to keep in mind during the testing process. They should be considered somewhere between guidelines and laws: rules set by people whose job it is to do so, the content of which should be considered before carrying out any relevant actions. This is particularly true when performing functional testing, as mentioned above, of which ascertaining whether or not the system meets its requirements is a huge facet. Beyond that, some could even consider it a tester’s job to question how the entire system works in relation to the requirements; more than just, “does it do what it’s supposed to?” a good tester will ask, “does it do those tasks as efficiently as possible?”