3. Proposed
System
3.2
Functional Requirements
3.2.1 Account Administration
3.2.1.1 Non-register user must register
for an account before using the BBSb.
3.2.1.2
During registration, the non-register user must provide his / her name
and email address
3.2.1.3 The non-register user must choose
a unique user ID.
3.2.1.4
The non-register user
must provide a password which only contains alphabets and numbers and with a
minimum length of 6 characters.
3.2.2 Login into the BBSb
3.2.2.1 A user must enter a valid user ID and password
3.2.2.2 The system must check the user’s ID and password and prompt again if invalid user ID / password pair is
entered.
3.2.2.3 After successful log in, the user can view a
list of all messages on the bulletin board.
3.2.3 BBSb Administration
3.2.3.1 The system should
display the list of messages in chronological order.
3.2.3.2 The list should contain the subject, author, post time, and status of
each message.
3.2.3.3 After the user have click on the subject of a
particular message, the content of the message must be displayed.
3.2.3.4
The status of the
message should be updated from unread to read for the user who read the
message, after the message has been read.
3.2.3.5 The system must allow a log-in user to compose message under their user
ID.
3.2.3.6 The system must refresh the message list automatically after a message is
posted.
3.2.3.7 The system should allow users to refresh the message list manually.
3.2.3.8 The system should allow user to sort the
message list by subject, sender, or date / time, in the order of ascending or
descending.
3.2.3.9 The system should allow user to filter the message list for read / unread
only.
3.2.4 Moderator Administration
3.2.4.1 The system must allow a moderator user to permanently delete messages from the bulletin board system.
3.3
Nonfunctional Requirements
3.3.1 User Interface and Human Requirements
The system should be
simple to use for untrained users. All instructions and necessary information
should be clearly displayed in the application window.
The bulletin board system
should be able to handle 1000 concurrently logged in users with a maximum
response time of 30 seconds per request. All functions in the software should
be accessible with only a keyboard (i.e. tabbing through buttons / links should
be supported). The colour choice of the system should
take colour-blinded users into consideration.
Different encoding format (Big-5, Unicode, etc) should be supported in the
system for international users.
3.3.2 Documentation
The RED document will
soon be extended with the Requirements Analysis Document (RAD). This document
will be maintained by the developers, but will remain accessible to the client
at all times. The designers will create and maintain an internal System Design
Document that will support the system implementation and facilitate further
development and maintenance. At the conclusion of the deployment phase of the
project, a Design Rational Document is required.
In conjunction with the
preliminary testing phase of the project, a draft of the maintainer's User
Manual is required. This manual should include instructions for installation,
standard maintenance, preventative maintenance, troubleshooting, and repair.
This User's Manual must be completed before final deployment of the system.
No normal bulletin board
user manual is required.
3.4 Pseudo
Requirements
All related software
associated with the Basic Bulletin Board System, including the system software
runs on the client’s computer, will be written using Java, to
fulfill the goal of OS platform independent.
3.5 System
Models
3.5.1 System Context
There are three human
actors:
Non-login user: He / she is either not registered with the BBSb
system, or has not logged into the system by entering his / her username and
password.
Login user: He / she has
entered the correct username / password and logged into the system using the
software.
The moderator is a normal
login user with an extra function. The moderator can delete specific message on
the message board by typing in the message number and click "Delete".
3.5.2 Use Case Model
Since the Refresh List
case needs to be invoked every time Post Message and Read Message is invoked,
therefore there is an <<include>> relationship between Post Message
and Refresh, as well as Read Message and refresh. After the list is refreshed,
the View List case is invoked. Therefore, an
<<include>> relationship links Refresh List and View Lists.
After a non-login user
registered, he/she can have the option of downloading the software. Therefore,
an <<extend>> relationship exists between the Download and Install
System Software use case and the Register use case.
Use Case Diagram
|
Use
case name |
Register |
|
Participating
actor |
Invoked
by NonLoginUser |
|
Entry
condition |
|
|
Flow
of events |
|
|
Exit
condition |
|
|
Special
requirements |
1. The download of software has
completed successfully |
|
Use case name |
Download and Install
System Software |
|
Participating actor |
Invoked by Non-login
user |
|
Entry condition |
|
|
Flow of events |
|
|
Exit condition |
|
|
Special requirements |
|
|
Use case name |
Login to system |
|
Participating actor |
Invoked by Non- login
user |
|
Entry condition |
|
|
Flow of events |
|
|
Exit condition |
|
|
Special requirements |
1.
The non-login user shall have the system software installed to be able to log
in. |
|
Use
case name |
ViewList |
|
Participating
actor |
Invoked
by LoginUser |
|
Entry
condition |
|
|
Flow
of events |
|
|
Exit
condition |
|
|
Special
requirements |
None. |
|
Use
case name |
RefreshList |
|
Participating
actor |
Invoked
by LoginUser |
|
Entry
condition |
|
|
Flow
of events |
|
|
Exit
condition |
|
|
Special
requirements |
None. |
|
Use case name |
Read Message |
|
Participating actor |
Invoked by Login user |
|
Entry condition |
|
|
Flow of events |
|
|
Exit condition |
|
|
Special requirements |
None. |
|
Use
case name |
Post
Message |
|
Participating actor |
Invoked by Login user |
|
Entry condition |
1. The Login user shall have the system software installed in his / her
computer. 2. The Login user intends to post on the bulletin board. |
|
Flow of events |
|
|
Exit condition |
|
|
Special requirements |
1. The post message page should provides advanced formatting tool such as
bold, italic, fonts, etc 2. The text box should be able to display at least 20 rows and 300 columns
of characters. |
|
Use
case name |
DeleteMessage |
|
Participating
actor |
Invoked
by Moderator |
|
Entry
condition |
|
|
Flow
of events |
|
|
Exit
condition |
|
|
Special
requirements |
None. |
|
Use case name |
Logout from system |
|
Participating actor |
Invoked by Login user |
|
Entry condition |
|
|
Flow of events |
|
|
Exit condition |
|
|
Special requirements |
None |
3.5.5 User Interface
This is the screen that an user who is not logged in will see. The only option is to
log into the system.
After logging in, the
user will see the above screen. Post message, view list, refresh list as well
as go directly to a post are made available to the user.
This is the moderator's view of the software system after he/she has logged in.
In addition to the access to features that a regular registered user has, the
moderator also has the option to delete certain posts.