Requirements Glossary

Design Requirements Format

• ID. A unique identifier for the requirement to help you track the requirement. Git commits that refactor code implement this requirement should include the requirement ID in the commit message in brackets. For example, [DESIGN-04] removed duplicated bounce code. Commits that add new functionality should include the functional requirement ID in the commit message rather than the design requirement.
• Name. A short name of the requirement, summarizing what the requirement is. This name will be used in discussing the requirement.
• Adherence. To what degree are you accountable to ensure your design adheres to this requirement? See Adherence below for a complete description.
• Description. A detailed description of the requirement, spelling out exactly what needs to be done to meet the requirement. The requirement is met if the final code committed for the project is designed and implemented so that it adheres to the description of the requirement. These requirements summarize ideas that are taught in class, and provide a criteria by which those concepts will be assessed.

Adherence

Unlike functional requirements, which will be new and unique for each project, the list of design requirements will grow with each successive project as you learn and incorporate new design techniques. Design requirements are labeled with an Adherence criteria to help you understand how closely the requirement will be assessed in grading for the current project.

• Complete. The code for the current project is required to completely adhere to this design requirement as specified. Complete is used for requirements that were introduced on previous projects.
• Consistent. The code for this project is required to consistently adhere to this design requirement as specified. There may be minor, isolated violations of the requirement, provided they are documented and how to fix them is discussed in your post-project Analysis Journal. Major violations, particularly those that impact overall design of the project, will be penalized, but insightful discussion in your post-project Analysis Journal describing what changes could have led to adherence will be rewarded. Consistent is used for the first project where adherence to the requirement is being taught.
• Forthcoming. Forthcoming requirements are generally taught at the tail-end of a project timeline, so the code of a future project will be required to adhere to this design requirement. Adherence to this requirement in the current project is considered an extension. Since design is more important than functionality, this is more important than functional extensions.

Functional Requirements Format

Functional requirements describe what your project is supposed to do. “Functional Requirements” is an industry-standard term; “functional” is used in the sense of “What is the function of this piece of software?”. Each project has a different set of functional requirements, which together define the unique behavior of the software you will build.

• ID. A unique identifier for the requirement to help you track the work. Git commits that address this requirement should include the requirement ID in the commit message in brackets. For example, a commit that implemented paddle movement using the direction keys would have a commit message like [BREAK-02] paddle moves left and right in response to key presses.
• Name. A short name of the requirement, summarizing what the requirement is.
• Priority. How important is implementing this requirement to successful completion of the project? Priority can be one of Core, Extension, or Variation [X]. See Priorities below for a description of each priority.
• Description. A detailed description of the requirement, spelling out exactly what needs to be done to meet the requirement. The requirement is considered completed if the code implements the behavior that is described in the requirement. Descriptions of requirements may be unintentionally ambiguous in parts — if you are confused about what is required, ask!

Priorities

• Core. Essential for the basic functionality of the software. These requirements are fundamental, and the program is not considered fully functional until all core requirements are met. Completing these requirements involves designing the entire software project. Therefore, to receive a grade of ‘B+’ or higher, a project must satisfy all core requirements.
• Extension. Enhance the program, often making it more user-friendly or flexible. Adding extensions is typically more straightforward in well-designed programs. Consequently, ‘A’ grade projects usually include multiple extensions. These extensions are also excellent opportunities to demonstrate how your project’s design accommodates additional functionality by discussing how you could implement further extensions in your post-project Analysis Journal.
• Variation. Involve implementing multiple versions of a similar functionality, each with small modifications. A well-designed program will allow new variations to be added without disrupting existing ones or adding special case code. Demonstrating good design in your program requires the implementation of project variations.
  • Variations are categorized under the same requirement ID but with different letters. For example: BREAK-16A, BREAK-16B, and BREAK-16C are all variations of BREAK-16. Each variation has a specified number requirement, such as Variation [2]. In this scenario, you must implement 2 variations of BREAK-16. The priority of these 2 variations is the same as the core requirements. Once the required number of variations is implemented, additional variations are considered the same priority as extension requirements. Any combination of variations is acceptable.
  • When Custom Variations are allowed (the requirement name ends with the word ‘Custom’ and the variation letter is ‘X’), you can implement multiple Custom Variations to satisfy the requirement. However, at most half (rounded down) of your variations can be Custom Variations. For example, BREAK-17 has three provided variations (BREAK-17(A-C)) and requires three variations. To satisfy the requirement for BREAK-17, you could choose to do any two of BREAK-17(A-C) and 1 custom variation (BREAK-17X), or you could do all three of BREAK-17(A-C) and no custom variations (BREAK-17X). You could not do two or three custom variations (BREAK-17X) since that is more than half of the required variations.
  • Extra variations offer another chance to showcase how your project design allows for seamlessly adding functionality in your post-project Analysis Journal. For instance, if you implement BREAK-17A, BREAK-17C, and BREAK-17D, you could describe how to implement BREAK-17B in your post-project Analysis Journal to illustrate this point. When you implement Custom Variations, you must document their behavior in your README.