Software Projects

(Supplementary materials for Software Engineering Process)

Software Engineering Laboratory

Dept. of EECS, KAIST
{kayoon, sujeon, igkim, bae}@salmosa.kaist.ac.kr
2003년 3월

Contents

1. Project Phases & Schedules ............................................................................................. 2

2. Candidate Projects ............................................................................................................ 3
3. Evaluation Criteria ............................................................................................................. 9
4. Report Form ..................................................................................................................... 10
Appendix: Nonfunctional Requirements ............................................................................. 16
1. Project Phases & Schedules

Problem statement
4/15 refinements Problem statement

4/20

4/29 Analysis Software Requirement Specification

5/8

5/13 Design Software Design Description

5/22
beginning date
5/27 Implementation & Implementation &
Demo Demo report due date
expected report
6/5

phase

Figure 1. 4 project phases & schedules

2
2. Candidate Projects

You can choose one of the following projects:

- Hotel Reservation System
- ATM
- Document Sea

3
2.1 Hotel Reservation System

The hotelier of KAIST Hotel wants to develop a new hotel reservation system that will
allow reservation to be made via Internet. In this system, not only the hotel staff but
also customers can make a reservation.
When making a reservation, a customer must register his/her personal information.
To speed up the process, details of previous customers will be stored and made
available later. By this system, the customer can make a reservation and cancel it.
When making a reservation, the customer can choose the number of rooms (how many
rooms do you want?), the type of rooms (Single, Double, Suite). When check in, the
customer can choose which rooms to use. After the reservation, the customer will get
an e-mail of the details of the reservation.
Within a hotel, there is a reservation administrator who is responsible for controlling
reservations at the hotel. He/she is also responsible for processing no-shows (when the
customer doesn’t show up at reserved date) and can make a reservation for a customer.

Basic functions of this system are as follows:

- Make a reservation
- Cancel a reservation
- Check in
- Check out
- Process no-shows (by Administrator)

You should refine above problem statement. That means, you can define your own
business purpose based on the given problem statement, and you can consider some
additional functionalities to clarify the problem statement given above for your project,
if they are needed.

4
2.2 ATM

The ATM system has the following business purpose.

- To provide the convenient withdrawal service in everywhere, even if user don’t
come to a bank

The preliminary problem statement for the project is as follows:

Each bank provides its own computer to maintain its own accounts and process
transactions against them. ATMs communicate with a central computer which clears
transactions with the appropriate banks. An ATM accepts a cash card, interacts with the
user, communicates with the central system to carry out the transaction, dispenses cash,
and prints receipts. The system requires appropriate recordkeeping and security
provisions. The system must handle concurrent accesses to the same account correctly.
The banks will provide their own software for their own computers. The cost of the
shared system will be apportioned to the banks according to the number of customers
with cash cards.

Figure 2. ATM system

The functional requirements are organized in two sections; First requirements of the
ATM and second requirements of the bank computer.

* Requirements of the ATM

- authorization process

5
 - transaction (withdrawal process)

* Requirements of the bank computer

- authorization process (bank code and password)
- transaction

The non-functional requirement is bellowed.

* The ATM network has to be available 24 hours a day.

* Each bank may be processing transactions from several ATMs at the same
time.
* The ATM must be able to use several data formats according to the data
formats that are provided by the database of different banks.

You should refine above problem statement. That means, you can define your own
business purpose based on the given problem statement, and you can consider some
additional functionalities to clarify the problem statement given above for your project,
if they are needed.

6
2.3 Document Sea

Document Sea is designed with the following objectives in mind:

- To allow an individual, who may not be familiar with any file sharing technologies
and tools, to use easily.
- To encourage the file-sharing in small organization which has intranet facilities.

The preliminary problem statement for the project is as follows:

Our organization needs document sharing system to facilitate frequent documentation

jobs in the organization. The document sharing system is a system which provides
searching and downloading operations of the documents in the users' local computer
which are connected by network system. We call our document sharing system as
Document Sea. Document Sea system consists of Document Sea Server and Client.
More than one Document Sea Client could be connected to one Document Sea Server.

Document Sea Server system stores information of the documents in each user's local
computer where Document Sea Client is installed. Whenever Document Sea Server
system receives a service request from a Document Sea Client, Document Sea Server
system should provide the corresponding service through processing information in the
Server. Document Sea Client system should provide user interfaces for executing of log
in, searching, download operations, at least.

Basic functions of Document Sea are shown as follows:

- Login/Logout

7
- Upload documents
- Search documents
- Download documents

You should refine above problem statement. That means, you can define your own
business purpose based on the given problem statement, and you can consider some
additional functionalities to clarify the problem statement given above for your project,
if they are needed.

8
3. Evaluation Criteria

The final score of project is compiled from the following.

- Problem Statement refinement (10%)

- Software Requirement Specification (40%)
- Software Design Specification (30%)
- Implementation & Demo (20%)

Project reports are evaluated by the following criteria (these criteria are not complete.
We can use additional criteria if needed).

- Are reports readable?

- Are reports unambiguous?
- Are reports consistent?
- Are reports complete & detailed?
- Do reports provide justifications about design decisions?
- Are designs reasonable?
- Do reports include the table of contents and page numbers?

We will give feedback for each phase report before your next phase project begins. You
have to consider our feedback and incorporate into your project. If you do not want to
incorporate it, you have to provide justifications about your design decisions for
teaching assistants.

You have to deliver on time. You must remember that the delay penalty will be applied
rigorously by the ratio of –15% per day. Thus, if your report is later than 7 days from
the due day, your score of the report will be even less than zero.

9
4. Report Form

4.1 Problem Statement

1. Title Page: You should include name of the document, team name, team members
(including preferred e-mail address among team members), date and something if
you need. You should also prepare Table of Contents (including page numbers and
so on) of your document.
2. Business Purposes: describe business purposes of your project. Motivation may be
included
3. Functional requirements: major functionalities
4. Nonfunctional requirements: requirements other than functional requirements (e.g.
Quality issues, H/W & S/W requirements)
5. System Architecture: describe the architecture of project system. The architecture
shows the components of the system and the relationship of the components
6. Assumptions (optional): describe the assumptions about the project
7. Development Approach (e.g. SA/SD) & Implementation Techniques including PL to
be used

10
4.2 Software Requirement Specification

1. Title Page
You should include name of the document, team name, team members (including
preferred e-mail address among team members), date and something if you need.
You should also prepare Table of Contents (including page numbers and so on) of
your document.
2. Introduction
You should explain both technical goals and business goals. Also, you should include
the purpose of the document and potential users of this document.
3. Informational Description
Give a detailed description of the software in a structured manner, clearly showing
how and where information flows
Present a clear, easy to comprehend description of the information FLOW,
CONTENT, and STRUCTURE. Contains the following:
(1) A data dictionary (2) Data Flow Diagrams
4. Activity Specification
For each bubble (activity, process) in your lowest level DFD’s, name and describe
the basic function of the corresponding process. Use a separate page for each.
5. Preliminary User Manual
Identify who the user of the manual should be (State assumptions about the reader).
Give the reader a good idea of the human interface. Show expected menus,
command lines, interaction screens, report formats. Discuss types of input and
output. Describe the overall functional capabilities of the system.
6. Validation Criteria
Describe how the user or evaluator can determine whether the end product actually
performs the way it is described. This is best done as a check list.
It gives a way to determine whether the project has been completed and you have
delivered what was promised. What tests should be performed to verify that it
functions as described earlier (especially in section 3 above)? (Unless you have a
complete understanding of the requirements of the software, this section is hard to
write. Later, if specifications change, this section will have to be updated.)
7. Nonfunctional Requirements
State all the important non-functional requirements. You may make reasonable
assumptions about the scope of your project.
You can refer to Appendix for the detail about nonfunctional requirements.

11
8. Summary
Some readers will study all the details presented. Some may review only the main
points which you summarize here for the overall picture.
9. Acknowledgement
Include authors of this document, by section, and editor of document.
10. Appendix (optional)
You could discuss here possible enhancements to the project. Also more detail of a
more elaborate system that might be proposed as a large future upgrade (‘beyond
scope of this course’).

12
4.3 Software Design Description

1. Title page and table of contents

2. Introduction – describe the following clearly and briefly
2.1 The objectives of the computer-based system and the role the software will
play.
2.2 Major software functions.
2.3 Major design decisions you made and constraints
3. Reference documents
3.1 Existing software documentation.
Mention the existing software documentation
3.2 Other hardware and software documents and manuals that may be of use to the
designer, programmer, user or to management personnel
4. Data flow diagrams and data dictionary
Include the revised data flow diagrams and the revised data dictionary
4.1 Revised data flow diagram
4.2 Revised data dictionary
5. Design description
Present a precise and detailed description of the software structure with structure
charts obtained by transforming the data flow diagrams. Use the consistent notation
throughout the document. You may have several levels of structure charts, i.e. the
first structure chart shows the highest-level modules and subsequent structure
charts show lower-level sections of the system for each of the modules in the first
chart.
6. Module design
Show the specifications of the modules shown in the structure charts.
The module header should include the following:

Title: the name of the module

Module ID: module identification number
Purpose: describe the module’s purpose or objective
Method: represent the module design using pseudocode
Usage: list all modules that may call the module being described
Subordinates: list all the modules which can be used by this one
Input: describe input arguments (optional)
Output: describe output arguments (optional)

13
 Input assertion: state assumptions on input arguments (optional)
Output assertion: state assumptions on output arguments (optional)
Variables: list all the variables which are not part of input, output arguments
Author: who is responsible for the completion and the correct functioning of t
his module?
Remarks: state additional comments if any

7. Data structure design

Describe or display graphically the major data structures for data elements traveling
among the arcs in the structure charts. Describe and/or display graphically the
structure of external data files.
8. Assumptions made
List all the assumptions made in the design phase (including a brief explanation of
each).
9. Requirement tracing
List the major requirements and the modules which implement each requirement.
This can be done in a cross-reference table with requirements listed down the left
and modules across the top.
10. Summary
Summarize the overall design in order to help the reader to understand quickly.
11. Acknowledgement
11.1 Author of the document by section
11.2 Editor of document
12. Appendix
List and describe briefly the changes made since the publication of the previous
document.

Special Note:
A document must stand on its own as a unit.
All assumptions made should be stated explicitly.

Expect that the document will be reviewed by personnel who have not been
involved with the details of planning and decision making.

14
4.4 Implementation Report

Implementation Report includes the following:

1. Install
A. System requirements (hardware, software (OS, DB), network, etc.)
B. Install procedures
2. User manual
A. Describe available functions and how to use them
3. Screen shots of major functions
A. Show the real screen shots of major functions
4. Changed parts from the design
A. You have to implement the systems that conform to the design. When parts in
the design are changed in implementation phase, you have to explain why the
parts are changed
5. Software
A. Source codes (softcopy, not print), executable files (.exe)

15
Appendix: Nonfunctional Requirements

User Interface and Human Factors

 What type of user will be actually using the system?
 Will more than one type of user be using the system?
 What sort of training will be required for each type of user?
 Is it particularly important that the system be easy to learn?
 Is it particularly important that users be protected from making errors?
 What sort of input/output devices for human interface are available, and
what are their characteristic?

Documentation
 What sorts of documentation are required?
 What audience is to be addressed by each document?

Hardware Considerations
 What hardware is the proposed system to be used on?
 What are the characteristics of the target hardware, including memory size
and auxiliary storage space?

Performance Characteristics
 Are there any speed, throughput, or response time constraints on the
system?
 Are there size of capacity constraints on the data to be processed by the
system?

Error Handling and Extreme Conditions

 How should the system respond to input errors?
 How should the system respond to extreme conditions?

System Interfacing
 Is input coming from systems outside the proposed system?
 Is output to go to systems outside the proposed system?
 Are there restrictions on the format or medium that must be used for input
or output?

16
Quality Issues
 What are the requirements for reliability?
 Must the system trap faults?
 Is there a maximum acceptable time for restarting the system after a
failure?
 What is the acceptable system downtime per 24-hour period?
 Is it important that the system be portable ( able to move to different
hardware or operating system environments) ?

System Modifications
 What parts of the system are likely candidates for later modification?
 What sorts of modifications are expected?

Physical Environment
 Where is the target equipment to operate?
 Will the target equipment be in one or several locations?
 Will the environmental conditions in any way be out of the ordinary ( for
example, unusual temperatures, vibrations, magnetic influences, and so on)?

Security Issues
 Must access to any data or the system itself be controlled?
 How often will the system be backed up?
 Who will be responsible for back up?
 Is physical security an issue?

Resources and Management Issues

 What materials, personnel, computer time, and other resources will be
required to build, install, and maintain the system?
 What skills or knowledge must the developers have to develop the system?
 What are the proposed intermediate and final deadlines for system
development costs?
 What is the proposed budget for hardware, personnel, and other
development costs?
 Who is responsible for system installation?
 Who will be responsible for system maintenance?

17