PROJECT NAME
D2: Requirements (v0.0)
Advanced Programming Laboratory Course
Turku Centre for Computer Science
Åbo Akademi
Department of Computer Science
AUTHORS
DATE
Copyright © 2001 AUTHORS.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the “D9: Licenses” document entitled “GNU Free Documentation License”.
History
This documentation has evolved as follows:
Original version by AUTHORS, 2001
Abstract
Describe in this section:
-the project generally but concisely, at most 200 words
-what the program does
-what kind of users use the program
Contents
1. Introduction 6
2. Functionality 7
3. User Interface 8
4. Future Extensions 9
5. References 10
1. Introduction
Describe in this section:
-the problem domain at hand; what is the problem in your project
-shortly, without details, what your program is going to do
-the actors in the project: the customer, the users, other systems
-the background of the actors; what knowledge is assumed from them
-how the program is going to help the actors
2. Functionality
Describe in this section:
-if you use some special words with specific meanings, define them first
-WHAT the program does, NOT HOW it is done
-WHAT the customer wants, NOT what you can/cannot do
-WHAT is expected from the program, NOT HOW the program looks like
-the main flow of events
You may use Use Case views to clarify the text.
3. User Interface
Describe in this section:
-what the program LOOKS LIKE
-sketch all input forms and report layouts, with examples if necessary
-sketch windows, dialogs, menus, etc.
-how do these graphical elements link to each other
-how the windows, etc., are used to achieve the functionality that you described
in the previous section; give here a short verbal description
You may even provide the customer with a prototype, if you so desire.
Remember to discuss here how invalid user input is handled, i.e., what happens if the information supplied by the user is incorrect. Do NOT think how the error handling is actually realized, just indicate WHAT follows if some input is invalid.
4. Future Extensions
Describe in this section how the program could be extended in the near future. These are the things that will not appear in your implementation, but you will take these things into consideration in your design.
You may use here Use case views, window sketches, etc., to illustrate the future extension.
5. References
List here all the books, software, and www sites that are referred to earlier in this document.
10