Informatics 43 Spring 2009, Course Project, Phase 1: Requirements Engineering

Background

Philadelphia Polyester Polytechnic University — Triple P — presently uses a very old, not-especially-user-friendly system for managing classroom space, scheduling courses into classrooms, and enrolling students into those courses. Due in part to its age — it's becoming difficult to maintain the hardware necessary to run their current system — and its poorly-designed user interface, Triple P is interested in replacing that system with a new one, which you will be designing and implementing throughout the quarter as you work on this course project.

This phase of the project asks you to write a requirements specification for the system, in which you'll focus your efforts on discovering your customer's needs, organizing them, and writing them. Note, in this phase, that you should be focused on what the system should do and not how the system should do it; it is important that you specify things that must constrain the design and implementation, but not things that constrain them unnecessarily. Note, also, that the goal here is not to be creative; your goal is to describe your customer's requirements, so that you ultimately build the system that your customer wants, as opposed to the system that you want.

Your requirements specification

Your requirements specification should be comprised of the following sections.

Title Page. Include your name and student ID#.
Table of Contents, with page numbers.
Introduction. Introduce both the system and the document. The Introduction describes why the system is necessary, gives a concise overview of its functionality, and explains the role that it plays in the organization.
User Requirements Definition. This section's audience is the non-technical customer and user. It should address the goals of the system and why it is needed. Describe the major features of the system and the rationale for each. Identify and describe other software, processes, hardware, people, and policies that the system may or will affect. List in this section any assumptions made about the existing world. (Assumptions that may be revised in the future should also be addressed in the "Expected Changes" section below.)
System Requirements Specification. Describe the functional requirements of the system in precise detail. When possible, identify the entities (components, sections, areas of functionality) that make up the system. Characterize the properties, states, functions, and interrelationships of each entity. Since this section is the core of the requirements specification, it warrants its own brief introduction. Make sure this section is carefully organized.
Constraints and Non-Functional Requirements. Discuss constraints pertaining to speed, space, safety, portability, robustness, operating environment, implementation bias, etc. Your audience here is the system designers and programmers, who will probably not be in direct communication with the users. This section will help them assess trade-offs in the system's implementation.
Implementation Phases. If applicable, and following the request of the customer, identify one or more subsets of the system's functionality that can or will be implemented first.
Future Directions and Expected Changes. If applicable, identify other goals or features that are not addressed elsewhere in the requirements specification. Again, you are providing insight and guidance to the system designers and programmers.
Acceptance Test Plan. Describe a procedure for testing the system to determine whether it adheres to the requirements, both functional and non-functional. Define several scenarios and sequences of tests. You do not need to provide a test case for every item of functionality, but you should provide a representative subset containing a few instances that are completed worked out.
Glossary. Define all terms or jargon used in the document that have a special meaning in the system.

Grading criteria

As we read through your requirements specification, we will be looking for the following qualities:

Adherence to the stated structure. Please organize your document as described above.
Clarity of writing. You should write your document in clear, precise, business-like English prose, avoiding jargon, humor, and wordiness. Correct spelling and correct grammar are essential. Avoid acronyms; common ones should be defined when first used and should appear in the glossary. Do not put diagrams, graphs, or pictures into your document. Bulleted and numbered lists can be used, with restraint, and not as a substitute for completed sentences and readable prose.
Fidelity to customer's desires. It is important that your document be true to the requirements stated by the customer. Don't add or remove requirements without the approval of the customer.
Completeness. Your document should address all aspects of system functionality and constraints that are important to the user.
Consistency. Your document will contain many detailed requirements. Careful thought is necessary to ensure that no subtle contradictions are introduced.
Testability. State detailed requirements in a manner that facilitates determining whether they have been met in the final implementation.
Avoiding implementation bias. Remember that a requirements specification should focus on what the system should do, not on how the system should do it.
Modularity and separation of concerns. Try to divide each section into subsections or paragraphs that are largely independent of each other. Ideally, each requirement or feature is discussed in its entirety in one place.

Interacting with your customer

Your TA, Hye Jung Choi, is acting as the customer for this phase of the project. To keep things simple and prevent the problem of receiving conflicting requirements, Hye Jung the sole arbiter of the requirements during this phase. I will not be answering questions about the system's requirements during this phase; I will direct all such questions to Hye Jung. I will, on the other hand, be happy to answer other questions about this phase of the project, such as questions about the structure of your requirements specification or the process of requirements engineering. (I will also be more involved in question-answering during future phases of the project.)

The discussion sections on Friday, April 10 and Friday, April 17 will be devoted to requirements elicitation, negotiation, and clarification. Attend these discussions and be sure to ask questions; these are your only two chances to speak with your customer directly, so it's important to make the most of your time.

Deliverables

You are required to deliver your requirements specification in one of the following formats: Microsoft Word (.doc or .docx), Rich Text Format (.rtf), or PDF (.pdf).

Follow this link for a discussion of how to submit files via Checkmate, an ICS-built online assignment submission system. Be aware that I'll be holding you to all of the rules specified in that document, including the one that says that you're responsible for submitting the version of the specification that you want graded. We won't regrade your work simply because you submitted the wrong version accidentally.

Originally written by Alex Thornton, Spring 2009, with heavy influence from Dan Frost.