Project 1: Software Requirements Specification

Draft Version Due by: Friday, September 13, 2024 at 11:59 p.m.

Final Version Due by: Friday, September 20, 2024 at 11:59 p.m.

Introduction

The purpose of this project is for you to create a software requirements specification that you will use to guide the development of the semester-long software development experience at the heart of this course.

You should be detailed and thoughtful, but the final submission at the end of the semester will not necessarily receive a lower grade if there are many areas in which you do not meet or do not conform to your requirements. This class is intended to be a learning experience, and there is a long journey between requirements and final submission. Especially when describing functional requirements, you're encouraged to give a set of core requirements as well as stretch requirements that you may hope to reach if there is time.

The requirements document must be written in natural language, specifically English, and the document should reflect the expectation that you will use Java as your development platform. The requirements document may be submitted as a Word, PDF, or LaTeX file.

Sections

The requirements document should follow the guidelines below, including the following sections. For additional guidance, please see the Examples section or speak with me.

  • Introduction
    The introduction should cover several areas:
    • Purpose of this document
    • Intended audience
      Note that this document should be understandable to a general audience with some knowledge of computer science. It should not be written with only me or only the Otterbein University community as its audience.
    • Scope of the project
    • Definitions, abbreviations, and specialized terminology
    • References, if any

  • Overall Description
    This description should include, at a minimum:
    • Product functions
    • User characteristics and needs
    • Dependencies on other systems or software

  • Interfaces
    The following interfaces should be described, if they form part of the software system:
    • User interfaces
    • Hardware interfaces
    • Software interfaces
    • Communications interfaces
    Use diagrams and figures when appropriate.

  • Functional Requirements
    Functional requirements are the important actions that the software system performs. Each requirement should have a number, a name, and a description. For a real product, a contract might require that all these requirements are met. This list is the most important part of this specification, but the requirements themselves will vary a lot depending on your project. Look at the examples provided below.

  • Non-functional Requirements
    Non-functional requirements cover overall attributes of the system and might include:
    • Performance requirements
    • Safety requirements
    • Security requirements
    • Software quality requirements
    Describe each category that's relevant for your system.

    • Feel free to include additional appendices if you think they will be helpful.

    Examples

    If you've never written a software requirements specification before, it can be a daunting task. Here are a couple of useful examples of requirements specifications:

    The following two links have outlines and guidelines for software requirements specifications without examples:

    Submission

    Commit your Word, PDF, or LaTeX files to the private GitHub repository for your group. You should commit your requirements documents by copying them into a folder called docs in your IntelliJ project. Name the requirements specification Requirements.docx or similar. Create separate tagged releases with the names Draft Specifications and Final Specifications for the draft and final versions, respectively. Doing so marks the state of your repository at those points.

    The draft version of the documents must be submitted by Friday, September 13, 2024 at 11:59 p.m. I will grade and give feedback on these documents over the weekend and return them to you by Monday.

    The final version of the documents must be submitted by Friday, September 20, 2024 at 11:59 p.m. The final version will be graded based on the same standards as the draft document, with an extra grading category for how effectively feedback on the draft has been incorporated.

    All work must be done within assigned teams. You may discuss general concepts with your classmates, but it's never acceptable for you to look at another team's code. Please refer to the course policies if you have any questions about academic integrity. If you have trouble with the assignment, I am always available for assistance.

    Grading

    Your grade will be determined by the following categories:

    Category Draft Weight Final Weight
    Introduction 10% 8%
    Overall Description 10% 8%
    Interfaces 10% 8%
    Functional Requirements 40% 32%
    Non-functional Requirements 20% 16%
    Spelling, grammar, style, and formatting 10% 8%
    Incorporation of feedback from draft document 20%