Deliverable 1.0

The software requirements are the essence of any project. Generally, a company does not deliver code, it delivers features. So it makes sense to specify them in the very early stage of project work. There are various standards proposing a common format for a document specifying software requirements, one of them is the IEEE SRS (Software Requirements Specification), that we will be basing on.

We provide a template here that you should use for your requirements specification. This is a standard IEEE document with some of the sections grayed out. You don't need to fill in the grayed out sections: they are there to give you a general feel of how the full template looks like, but for the sake of this course we only ask you to fill in the sections in black.

The number of functional requirements should be 12 +/- 1 and the number of non-functional should be 5 +/- 1. The +/- depends on how complex they are. There are also at least 4 scenarios required. Every scenario should illustrate as many requirements as possible and show examples of using the system. Furthermore, each scenario should illustrate different requirements, minimizing the overlap with other scenarios.

The deliverable is finalized by creating a release in your GitLab repository using the Releases functionality.

Access for feedback

After your SRS is complete, you need to give access to your GitLab repository to the team you are paired with. They will download the final document and prepare their feedback. We will send emails to team leaders with instructions on how to provide access.

Feedback - Deliverable 1.1

Your feedback should be provided as a CSV document with a specific structure:

title,description
"My Issue Title", "(1,1,something): My Issue Description"

It should contain one row for every issue you find.

  • title is a short summary of the issue.
  • description should have the form "(page, paragraph, starting phrase of the text you are referring to): description of the issue".

If the starting phrase is a diagram then write the word diagram#n where n is the number of the diagram in that page. This process makes it easier for the other team to find and correct their mistakes.

Keep in mind when giving feedback for an application that the other team is thinking differently than you. So try to understand what they are trying to design before writing a negative comment.

You should send a merge request to the other team's repository adding your feedback CSV document once you're done.

After you receive the feedback from the other team (and merge it so the file is in your repository), you should use the Issue Importer API to import the feedback contents as issues into your repository.

After the feedback round each team should produce a new release of their fixed requirements document, before continuing to the next deliverable. This new version does not have to address all reported issues, but the ones the team thinks are actually problematic. The new release should have a comment indicating which issues were handled. Also, for each issue in the Issues tab there should be a reply either addressing the issue or explaining why it's not important.