Requirements Engineering

Requirements Engineering

Lecture Date: Thursday, September 9


Project -

  • You have your teams now and your TAs
  • TAs will setup your Google Drive folder and Discord channels (if this hasn’t been done yet, you should probably ping your TA on Discord)
  • Between now and next Sunday/Monday, complete the items in Sprint 1 (choose roles, fill out form, init GitHub) AND the Scrum Master should submit your Sprint Report to Gradescope
  • Meet with your TA on Sunday/Monday (online or in-person)
  • TA will score your first Sprint Check
  • Start on Sprint 2 (due in two weeks)

Assessments -

  • GP-A grading finished and returned in Gradescope
  • GP-B due tonight by 11:59 PM / grading has already begun and we will return them as soon as possible
  • Quiz 1 is available today and is due next Thursday by 11:59 PM
  • Django Practice has been posted and is due in two weeks

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.

The requirements engineering process is effectively spit into two stages:

  • Requirements analysis or elicitation: the act of working with the stakeholders to document their needs
  • Requirements modeling or specification: the act of converting the “plain language” requirements from stakeholders into something actionable by developers

Slide Deck
Requirements Engineering

Prof. Sherriff