We are now moving into the second unit of the course, focused around the first (and, arguably, one of the most important) phases of development - requirements.
We build software to solve problems and hopefully improve people's lives in some way. If we as software engineers don't understand the problems we are trying to solve or do not put the time in to really listen to what our stakeholders or customers needs are, then our effort is wasted.
Requirements engineering is a sub-field in software engineering that is concerned with the systematic, rigorous approach to how to elicit requirements effectively from stakeholders and then convert those requirements into something actionable (e.g. specifications) for developers to act on. Communication, like in most areas of software engineering, is incredibly important here. Communication with the stakeholders and customers and communication with the design and development teams.
The types of requirements we are after tend to fall into one of three categories:
* Functional Requirements: Things "the system shall" do; the features of the system;
* Non-functional Requirements: Aspects of the system that encompass the entire software solution, like security, usability, and availability; and,
* Constraints: Limitations put on the possible set of solutions you could build (e.g. "you must build this with Django and Python)
By understanding the needs of the stakeholders better, you have a much higher chance of successfully completing your project on time and within budget.