Author(s): Hayden Smith
Before we code anything, we need to know how to test it.
Before we code anything, we need to know how to design it.
To test or design anything, we need to know what our objective is - or more specifically, what the requirements of the system we're building are
IEEE defines a requirement as:
A condition or capability needed by a user to solve a problem or achieve an objective
βThe hardest single part of building a software system is deciding what to build. No part of the work so cripples the resulting systems if done wrongβ (Brooks, 1987)
What are some examples of requirements?
Example: Chair specifications
Example: Australian Design Rules
Functional Requirements specify a specific capability/service that the system should provide. It's what the system does.
Non-functional Requirements place a constraint on how the system can achieve that. Typically this is a performance characteristic.
For example
Requirements don't just appear out of thin air. We have to derive them, and to do that we apply the process of requirements engineering.
Requirements Engineering is:
Requirements engineering often follows a logical process across 4 steps:
Questions and discovery
Building the picture
Refining the picture
Checking you haven't gotten lost
Going back to stakeholders and ensuring requirements are correct
What are some challenges we may face while engaging in Requirements engineering?