Skip to main content

Requirements

Requirements define what a software system should do. Software developers work with various stakeholders for a software system to fully understand the needs of all interested party. Those needs are defined into software requirements - statements of functionality for a software system. There are three types of requirements:

  • Functional: Functional requirements define what the system should do or the functionality of the system. There are many ways to write functional requirements. We describe functional requirements in use cases.
  • Non-functional: Non-functional requirements describe characteristics that the system should have that are not related to direct functionality. Non-functionality requirements typically fall in the areas of performance, usability, security, and reliability. For example, a page on a website shall load in less than a second would be a non-functional requirement.
  • Constraints: Constraints describe limitations on the development of the system. For example, constraints define the operating system or programming language that the system must be developed for/with.

For CSC216, we will focus on functional requirements - or what the system shall do - rather than non-functional requirements or constraints. There are implicit non-functional requirements (i.e., no infinite loops, no bugs, etc.). The main constraint is that all work must be completed using Java 1.8, JUnit 4, and other libraries and tools as needed.

Use Cases

Use cases are a user centric way of defining functional requirements. A use case combines together related scenarios about using a software system from the user’s perspective. A use case may be specific to a particular user or general for all users.

A use case is broken into four sections: preconditions, main flow, extensions, and alternative flows. The only required section is the main flow.

A use case may be referred to by another use case using brackets (e.g, [ and ]). Each use case should be referred to by another use case to connect all parts of the system together.

Extension flows and alternative flows are also referenced using brackets. Each extension flow and alternative flow should be referred to at least once from another element of the use case. If a extension flow or alternative flow is part of the use case, then only the [E] or [A] is needed. If a extension flow or alternative flow from another use case is referred to, then the use case is used in the reference (i.e., [UC-E]).

We’ll use WolfScheduler Use Case 1 as our example use case.

Use Case 1: Load Course Catalog

Load the catalog of courses so students can make personal schedules for planning.

Main Flow

  1. The user provides a file containing the listing of courses in the catalog for the upcoming semester.
  2. The system processes the course catalog file line by line and stores valid courses in the system [Processing Course Information] [Missing File].
  3. The name, section, and title of the courses in the catalog are displayed in a list.

Extensions

  • [Processing Course Information] Information about scheduled courses are stored in a file with one course record per line. A course record is a comma separated list of the course name, course title, section number, the number of credit hours, instructor’s unity id, meeting days, start time, and end time. The start time and end time may be omitted if the meeting days are listed as ‘A’(rranged). Valid course records are stored in a list of courses [Invalid Course Record]. A course record is invalid if one or more of the following are true, and an invalid course records is skipped:
    • an item is missing
    • the course name is null or an empty string
    • the course name is contains less than 5 characters or more than 8 characters
    • the course name does not contain one space between letter characters and number characters
    • the course name does not start with 1 to 4 letter characters
    • the course name does not end with three digit characters
    • the course title is null or an empty string
    • the section number is NOT exactly three digits
    • the credit hours are not a number
    • the credit hours are less than 1 or greater than 5
    • the instructor’s id is null or an empty string
    • meeting days consist of any characters other than ‘M’, ‘T’, ‘W’, ‘H’, ‘F’, or ‘A’
    • meeting days have a duplicate character
    • if ‘A’ is in the meeting days list, it must be the only character
    • the start time is not between 0000 and 2359 an invalid military time
    • the end time is not between 0000 and 2359 or an invalid military time
    • the end time is less than the start time (i.e., no overnight classes)
    • a start time and/or end time is listed when meeting days is ‘A’
    • a course with the same name and section

    An example of what a course schedule file might look like is below:

    1
2
3
4
5
6

    CSC 116,Intro to Programming - Java,001,3,jdyoung2,MW,0910,1100
CSC 116,Intro to Programming - Java,002,3,spbalik,MW,1120,1310
CSC 116,Intro to Programming - Java,003,3,tbdimitr,TH,1120,1310
CSC 216,Programming Concepts - Java,001,4,sesmith5,TH,1330,1445
CSC 216,Programming Concepts - Java,002,4,jtking,MW,1330,1445
CSC 216,Programming Concepts - Java,601,4,jep,A

Alternative Flows

  • [Missing File] If the file does not exist on the system, an error message, “Cannot find file.” is displayed and the user is re-prompted for a file.
  • [Invalid Course Record] An invalid course record is ignored and not added to the list of courses stored by the system.

Preconditions

The preconditions describe how to reach a given use case. In WolfScheduler UC1, there are no preconditions listed.

Main Flow

The main flow describes the steps that the user would follow to complete the task the use case describes. Additional details are provided in Extension flows. Errors or alternative paths are provided in the Alternative flows

For the example use case above, the main flow provides a listing of the steps the user would complete when interacting with the user interface for WolfScheduler. Each step is numbered and has a specific task. If needed, the step may be annotated with a named extension flows or alternative flows to direct readers down different paths.

Extension Flows

Extension flows provide details to portions of the main flow. In WolfScheduler UC1, extension flow 1 describes the details for processing a file containing course catalog entries. The description of valid and invalid input is quite complex, so providing the details in an extension flow provides a way for the developer to focus on either the high-level functionality of the use case or the detailed information about processing the courses file.

Alternative Flows

Alternative flows provide details about error conditions, or how the program should fail gracefully if the user provides invalid or incorrect information.

In WolfScheduler UC1, step 2 connects to alternative about a missing file. The missing file alternative flow describes what happens if the user selects a file that is not in the file system. In this case, an error message is displayed and the user is reprompted for the file.