CS375: Software Engineering - Requirements Report (100 Points)

Assignment Goals

The goals of this assignment are:
  1. To identify a compelling software project, its stakeholders, and a capable team to build it
  2. To prepare a software requirements document for a software project

Background Reading and References

Please refer to the following readings and examples offering templates to help get you started:

The Assignment

The Requirements Report is the first of the four graded project documents (Requirements, Objects/API Summary, Test Plan, and User Manual). It is submitted in two installments: Part 1 (Project Concept) early in the semester, in which you propose what you will build, for whom, and with what team; and the full report a few weeks later, which incorporates a (possibly revised) Part 1 along with your stakeholder-informed functional and non-functional requirements and project schedule. Each installment is submitted and graded on the schedule; the full report is graded using the complete rubric on this page, and Part 1 using its Project Concept criteria.

Part 1: Project Concept

For the project concept, you will identify a potential software project based on an existing perceived need. You do not have to fully specify all the details of your project at this stage; however, the goal is to define the goal of your project, the members of your project, and identify a compelling need for that project. As part of this “compelling need,” you will identify multiple stakeholders: people who would use or be impacted by the use of your software project.

Later (after the concept is accepted), you will speak with members of these stakeholder groups to the extent possible, to identify and document software requirements that will frame the scope of the remainder of your project.

Project Group Members and Roles

For now, you will identify a potential group of at least 3 and up to 4 people, and assign each of them a role or area of expertise in completing the project.

You will rotate a few project roles among the group throughout the semester. Your group should include:

  1. A project lead: responsible for ensuring that everyone remains on-schedule, and adjusting the schedule with the group as-needed
  2. A document lead: responsible for ensuring that the reports are well-organized and written in a single voice (although everyone should write all the reports all the time)
  3. A scrum lead: responsible for leading the project group meetings, preparing the agendas, and keeping the project meeting minutes to be included in the periodic scrum reflection report
  4. Code lead: responsible for the codebase and software repository, and ensuring that code coverage is sufficient and that test cases pass

Include a rotation schedule for these roles. Every 3-5 weeks, these roles should rotate such that every member has served in every role. This schedule should be included in the project concept.

Required Elements of the Project Concept

Your concept should contain the following, likely as document sections:

  1. A description of your project
  2. A compelling need for the project
    • Be clear about the problem you are solving, and for whom you plan to solve those problems
  3. A description of your stakeholder groups
  4. The technical expertise of your project group, as well as each member’s roles and responsibilities
    • A discussion of technical aspects your group may need to learn in order to be successful
  5. The minimum viable project scope: what functionality would you absolutely need to complete to be successful?
  6. Aspirant scope: what additional features do you want to incorporate if time permits?
  7. A rough timeline of the project scope, estimating on an hourly basis (assuming 8 hours per week per group member) the duration of each feature you identified as minimally viable and aspirant.
  8. A summary of the intellectual merit of your project: why is it worth doing, and what is novel about it?
  9. A summary of the broader impacts of your project: who benefits beyond your project group, and how?

Suggestions

To help you identify potential project areas, consider external needs. For example, what might benefit the campus community? Think of your own experience and any challenges you encountered that could be aided by the use of technology. It is perfectly acceptable to use this project as an opportunity to solve a problem from your own experience, but reflect carefully on the community benefit. In this project, you will focus primarily on the needs of others, and assume that it will be other people serving as the primary users of your software.

Part 2: The Full Requirements Report

Stakeholder-based Design

Before you decide upon your software requirements, it is necessary to obtain input from your stakeholder groups. Prepare a list of questions to ask them that will help you obtain information about their needs.

Keep in mind that their answers will be non-technical, and so your questions should be non-technical in nature. Do not delve into the technical aspects of your project with your stakeholder group. Rather, it will be your job to translate their feedback into technical functional requirements.

Include your stakeholder questions, responses, and your reflections upon their input (for example, how you translated their feedback into requirements) as a section of your report.

Functional Requirements

To create the software requirements document, begin by establishing a list of numbered functional requirements for your software system.

For each requirement, design a use case or user story. A use case provides a flowchart of user actions that culminates in the completion of the software requirement. A user story is similar but takes the following form:

As a <type of user>, I need to <action I need to perform> because <reason this action is necessary>

In either case, requirements may depend upon each other. For example, it may not be possible to open a project until the user has logged into the system and obtained a user token. Therefore, the login requirement would be a dependency of the project listing requirement. Because your requirements are numbered, you can cross-reference them in this way.

Non-Functional Requirements

Finally, identify those non-functional requirements (for example, hardware deployment requirements, network bandwidth, computational power, and so on) for your project.

Gantt Chart

Include a Gantt chart for your project that schedules each of your sprints. Each sprint should culminate in a prototype or proof-of-concept toward your final project. The Gantt chart should identify dependencies between tasks within each sprint, and every task must have an assigned owner (a single responsible group member) – either by organizing the chart with one section per person, or with an assignee column in an accompanying task table, as practiced in the Gantt activity.

Press Release

Write up a “press release” document that describes your project to the layperson. Show this to at least three people outside of your class project, and validate the feasibility of your project as well as their understanding of its goals and capabilities. Provide and answer a list of frequently asked questions about your project.

Website

A goal of this project is to help you develop a portfolio that you can share with others as you start your career. To aid with this, one member of your group will create a github repository to hold the website for your project, where you will house your reports. This repository must be shared with all members of your group. Post your project concept, and later your full requirements report, as pages to this repository. You will publish this repository as a GitHub Pages website as part of your User Manual deliverable, so it pays to keep it organized from the start.

Setting Up Your Team Repository

Your shared repository is also where you will practice the collaboration workflow that real teams use, so set it up deliberately (the mechanics are covered in the git assignment):

  1. One member creates the repository and, under Settings then Collaborators, adds every teammate so that all of you can push branches and review each other’s work.
  2. Protect the main branch (Settings, then Branches): require a pull request with at least one approving review before merging, and – once you have set up continuous integration – require the test check to pass. No one, including the repository owner, should push directly to main.
  3. Do your work on branches and integrate it through Pull Requests that a teammate reviews and approves, so that every change is seen by at least two people before it reaches main.
  4. Track your tasks as GitHub Issues, assigned to owners and grouped into milestones that mirror the sprints in your Gantt chart; reference the issue a pull request resolves with Closes #<n>.

This is exactly the branch -> pull request -> review -> merge cycle from the git assignment, applied to your real project from day one.

Submission

In your submission, please include answers to any questions asked on the assignment page, as well as the questions listed below, in your README file. If you wrote code as part of this assignment, please describe your design, approach, and implementation in a separate document prepared using a word processor or typesetting program such as LaTeX. This document should include specific instructions on how to build and run your code, and a description of each code module or function that you created suitable for re-use by a colleague. In your README, please include answers to the following questions:
  • Describe what you did, how you did it, what challenges you encountered, and how you solved them.
  • Please answer any questions found throughout the narrative of this assignment.
  • If collaboration with a buddy was permitted, did you work with a buddy on this assignment? If so, who? If not, do you certify that this submission represents your own original work?
  • Please identify any and all portions of your submission that were not originally written by you (for example, code originally written by your buddy, or anything taken or adapted from a non-classroom resource). It is always OK to use your textbook and instructor notes; however, you are certifying that any portions not designated as coming from an outside person or source are your own original work.
  • Approximately how many hours it took you to finish this assignment (I will not judge you for this at all...I am simply using it to gauge if the assignments are too easy or hard)?
  • Your overall impression of the assignment. Did you love it, hate it, or were you neutral? One word answers are fine, but if you have any suggestions for the future let me know.
  • Using the grading specifications on this page, discuss briefly the grade you would give yourself and why. Discuss each item in the grading specification.
  • Any other concerns that you have. For instance, if you have a bug that you were unable to solve but you made progress, write that here. The more you articulate the problem the more partial credit you will receive (it is fine to leave this blank).

Assignment Rubric

Description Pre-Emerging (< 50%) Beginning (50%) Progressing (85%) Proficient (100%)
Project Concept: Need, Stakeholders, and Team (Part 1) (20%) No project motivation, stakeholder identification, or group identification is given The concept motivates the project in some way, but the external need, the stakeholder groups, or the group member roles are missing or unclear The concept describes a functional need that can be satisfied within the scope of the course, identifies at least one stakeholder group and their role in shaping requirements, and proposes a group of adequate size in which each member has a specific role The concept describes a compelling functional need that can be satisfied within the scope of the course, identifies multiple stakeholder groups and their roles in shaping requirements, and proposes a group of adequate size with specific member roles and a role rotation schedule
Functional Requirements (35%) Cross-referenced functional requirements are not provided for this project One or more functional requirements is missing or unclear, and/or not adequately cross-referenced A mostly comprehensive description of each functional requirement is given with a use case or user story and that is cross-referenced A comprehensive description of each functional requirement is given with a use case or user story and that is cross-referenced is provided
Stakeholder Feedback and Analysis (25%) No stakeholder feedback is present Evidence of stakeholder interviews is provided Stakeholder feedback is included, including questions and answers to each group Stakeholder feedback is included, including questions and answers to each group, as well as a thoughtful digest translating those inputs into functional requirements
Gantt Chart and Project Schedule (10%) The Gantt chart is missing or incorrect The Gantt chart is incomplete or leaves tasks without an assigned owner The Gantt Chart assigns an owner to every task The Gantt Chart identifies project dependencies and assigns an owner to every task
Non-Functional Requirements (10%) Non-functional requirements are missing from the report Non-functional requirements are not appropriate to the project, but are provided Non-functional requirements are too strict or too minimal for the project scope Reasonable non-Functional requirements are offered for the project

Please refer to the Style Guide for code quality examples and guidelines.