|
|
|
Software
Requirements Specification
|
Version
1.1
Edition 1
| Document
ID: |
SRS |
| Author(s): |
Danny
Goulas
Daniel Woodhouse
Jaycee Phua
Tristan Austin
John Newbigin
Imron Alston
Christian Karolos
Matthew Evans
Shane Fitzgibbon |
| Reviewed
by: |
Danny
Goulas
Daniel Woodhouse
Jaycee Phua
George Panagiotopoulos
Matthew Sykes
Nicholas Phipps |
| Date: |
5
October 1999 |
Revision
History
| Date |
Modifications |
Reason |
Version |
| 1999.04.12 |
Adapted SRS
Template to HTML (and Style Standards) (DG) |
Based on hit3058-srs-0.1d
(Rajesh Vasa) |
0.2d |
| 1999.04.29 |
Various initial
sections combined (DW) |
Initiate document
collation |
0.3d |
| 1999.05.18 |
Added, updated and formatted
various sections (DG) |
Progressive document collation |
0.4d |
| 1999.05.19 |
Added, updated and formatted
various sections (DW) |
Progressive document collation |
0.45d |
| 1999.05.20 |
Document formatting
verified (JP) |
Conformance
to Latest Style Specification |
0.5d |
| 1999.05.21 |
Reviewer Added
to Cover Page (DG) |
Project Architect
content verification |
0.6d |
| 1999.05.22 |
Functional
Requirements section reorganised (DG) |
Reviewer (Project
Architect) suggestions (TA) |
0.7d |
| 1999.05.24 |
Functional
Requirements section revised (DG) |
Ensure document
readability |
0.75d |
| 1999.05.25 |
Document Scope
and Executive Summary added (JP) |
Finalising
document contents |
0.80d |
| 1999.05.27 |
Document contents
finalised (DG) |
1st Draft complete |
0.85d |
| 1999.05.28 |
Reviewers added
to Cover Page (JP) |
Quality Assurance
check (NP, GP, MS) |
0.9d |
| 1999.05.28 |
Updated (DG) |
Comply to QA review |
0.95d |
| 1999.07.26 |
Updated various sections
(DW) |
Comply to QA review |
0.96d |
| 1999.07.30 |
Reviewed contents and style
(DG) |
Ensure document
readability |
0.97d |
| 1999.08.03 |
Revised section 5 order
and contents (DG/JP/DW) |
Updating document
contents |
0.98d |
| 1999.08.03 |
Reviewed overall document
style (DG/JP/DW) |
Ensure document
readability |
1.0d |
| 1999.09.02 |
Cover Page formatting updated
(JP) |
Reflect changes
in Style |
1.01d |
| 1999.09.14 |
Reviewed entire document
content. (NP/SH/MS) |
Preparation of final version |
1.05d |
| 1999.09.21 |
Added inter-section links
(NP) |
Preparation of final version |
1.06d |
| 1999.10.05 |
Committed changes to document
(NP) |
Submitted final document |
1.1 |
Table
Of Contents
Executive
Summary
This Software
Requirements Specification (SRS) provides a detailed analysis on
the objectives of the Software Engineering Project team known as Team
Synergy, in developing a Computer Aided Software Engineering (CASE)
Tool titled Cohesion. The final software product, in conjunction
with all other accompanying components, are expected to be fully complete
by Week 11, Semester 2 (October) 1999, and will be implemented using the
Java Programming Language.
Expected requirements
and functions available with Cohesion have been outlined
in this document, including anticipated product users and details of the
structure and composition that will be developed.
1.
Introduction
1.1
Document Purpose
This document
details the functional and performance requirements for the computer software
to be developed by Team Synergy for the Client. The requirements
were determined during the analysis of the client's operations by Team
Synergy.
This document
will be subject to formal/informal review by the Team Synergy development
team and the Client. It will form the basis for ongoing development
and testing of software by Team Synergy to meet the requirements
of the Client.
This document
is intended to supply sufficient software requirement information to the
Client to establish a solid foundation for subsequent software assessment
and approval. It also provides the development team with a basis
for on-going software design, and the Quality Assurance team with a basis
to form test cases.
1.2
Project Scope
This project
will utilise the skills of all Team Synergy members in developing
a Computer Aided Software Engineering (CASE) Tool. The intention
of which is to create a product of the highest quality and functionality,
within the time constraints set by the assessing body.
The project
shall be undertaken with heavy emphasis on achieving realistic goals. At
the same time, assisting each team member in implementing their understanding
of the processes involved with software development, in an environment
typically found in the Software Development industry.
Once the project
is completed it will be available for download, free of any license and/or
on-going support or software updates.
1.3
Definitions, Acronyms, and Abbreviations
Upper case words refer to
abbreviations within the CVS. For more information on a topic, read the
relevant section within the body of this document.
| Aggregation |
One or more classes that
make up another class. |
| Arc |
An element on a model that
connects 2 nodes. |
| Attribute |
A piece of
data or knowledge that an object has. |
| Broadcast |
The action of transmitting
data through all available channels. Used to find local servers. |
| Class |
A definition
of an object, which contains a description of the data within the object
and the operations it performs. |
| Communication
Module |
The module that allows communication
between the client and the server. |
| CRUD |
Create Retrieve
Update
Delete |
| Developers |
The team responsible
for the development of the software system. |
| Hotkey |
A key (or combination of
keys) that performs a task otherwise available using buttons or menus. |
| Inheritance |
One class taking all the
data and operations of another class, optionally extending and/or altering
them. |
| Instance |
One particular
object that has been created from a class. |
| JLF |
Java
Look
& Feel |
| Jmetric |
A software product that
analyses Java source code or Java byte code, and provides metrics describing
it. |
| Local Space |
The coordinate space where
shape outlines are defined. (0,0) is in the center, positive x is
right, and positive y is down. See also Model Space. |
| Meta-Arc |
Defines the type of, and
attributes present in, an arc. |
| Meta-Model |
A collection of node, arc
and rule definitions that helps give meaning to a particular model. |
| Meta-Node |
Defines the type of, and
attributes present in, a node. |
| Meta-Rule |
Defines the contraints of
placement of nodes and arcs including connections between them. |
| Model |
A collection of nodes and
arcs, plus the meta-model that gives meaning to them, and a package which
determines how the individual nodes should be drawn. |
| Model Space |
The coordinate space where
the model is defined. Nodes are given model space coordinates to
indicate their position on the map. Positive x is right, and positive y
is down. See also Local Space. |
| Node |
An element of a model. |
| . Normal. Conditions |
Normal operating conditions
of the computer running the application. ie. plenty of free memory, no
. processor intensive. background processes etc. |
| Note |
An element on a model, that
is purely for information/documentation purposes only. |
| Object |
An instance
(single instantiation) of a class. |
| OML |
Open
Modelling
Language |
| Package |
Contains a way of drawing
nodes/arcs, for each node/arc specified in a meta-model. |
| Package Arc |
Defines how to draw/represent
a Meta-Arc, including where and how to draw/represent any terminating nodes. |
| Package Node |
Defines how to draw/represent
a Meta-Node, including where and how to draw/represent any attributes present. |
| Process |
An operation
or action which transforms data values (or attributes) of a class. |
| Project |
A collection of related
models, each stored in a separate file. |
| Project Tree |
The directory-type structure
of projects within a workspace window/pane. |
| Real-time |
Functions performed in real
time, should allow the user to interactively perform the function and get
feedback about what the function is doing. |
| Recursive |
An operation or object making
reference to itself. |
| Relationship |
Defines a specific
connection between two classes. They are defined by the context of
the problem that is being analyzed. |
| Repository |
A storage location for data. |
| Requirement |
A condition
or capability needed by a user to solve a problem or achieve an objective. |
| Rubber Box |
A method of selecting an
area with the mouse, the 'rubber box' is the selection rectangle shown. |
| Rule/s |
A rule is a means by which
nodes and arcs at the model level are given strict terms by which they
can interact with each other. |
| Selection |
A list of items on the model
that is currently selected by the user. The items can be anything
that is determined to be selectable i.e. nodes, arcs, notes etc. |
| SMTP |
Simple
Mail
Transfer
Protocol |
| Specification |
A document
that describes, in a complete, precise, verifiable manner, the requirements,
design, behaviors and/or other characteristics of a system or system component. |
| State |
Describes a
unique value, or unique combination of all values. |
| Sub Script |
Used to classify
scripts into more specialised versions. |
| UML |
Unified
Modelling
Language |
| UI |
User Interface |
| Use Case |
A disciplined
method of describing the typical behavior of a component of the system. |
| User |
The person
operating and/or using the software system. |
| Viewport |
An area on the screen that
is being used to view a model. |
| Viewport Space |
The coordinate space that
represents the screen. (0,0) is in the top left corner, positive
x is right, and positive y is down. |
| View Space |
The coordinate space where
the viewport is centered (0,0). positive x is right, and positive y is
down. |
| Workspace |
A collection
of projects. |
| Workspace
Tree |
The directory-type structure
of workspaces as shown in the workspace window/pane. |
| Zoom Space |
The viewport space after
it has been zoomed to the correct zoom factor. Positive x is right, and
positive y is down. |
1.4
Document Overview
This document,
the Software Requirements Specification (SRS), identifies the software
requirements in the form of a task and system object model. The model presented
within this document is an implicit statement of the requirements. It exhibits
the boundaries and capabilities of the system to be built.
This document
has 10 major sections and 4 appendices:
-
Executive Summary,
gives a brief summary of the document contents and their purpose.
-
Section
1 (Introduction) provides an overview of the entire SRS document and
the product being specified.
-
Section
2 (Development Process Perspective) describes the development methodology.
-
Section
3 (Product Characteristics) describes the product characteristics in
terms of functions, performance and interfaces..
-
Section
4 (User Characteristics) describes the requirements of the users of
the product.
-
Section
5 (Functional Requirements) describes the various tasks that are to
be performed, in response to user requests of the system, taking a Use
Case form (see also Appendix C).
-
Section
6 (Interface Requirements) describes the display modes and devices
supported by the product.
-
Section
7 (System Diagnostics) gives a brief description of the types of diagnostic
tools available for use with the product.
-
Section
8 (Verification Requirements) describes the quality assurance methodology
used to ensure a bug-free product.
-
Section
9 (General Constraints) describes the limitations of the product, addressing
the constraints, assumptions and dependencies, expressed in natural language.
-
Section
10 (System Requirements) describes the computers, printers, etc. anticipated
to be required within the new system for both the client and server computers.
-
Appendix
A (External Context Diagram).
-
Appendix
B (Internal Context Diagram).
-
Appendix
C (Task Scripts).
-
Appendix
D (Hierarchical User Interface Compostition).
1.5 Applicable
Documents
| Document
Name |
Document
ID |
| Web Document
Style Standards |
WDSS |
| Technical Style
Standards |
TSS |
| Project Plan
& Procedures |
PP&P |
Table
1.7.1 - 1: Applicable Documents.
2.
Development Process Perspective
2.1
Methodology
There will be
no formal software development approach used, instead we will be using
a mixture of techniques from various methodologies.
In terms of
design, intially we will be taking a top down approach, identifying all
the distinct modules in the system and the interfaces between them and
then moving down into each module to design the increasingly more detailed
aspects.
Periodically
we will be identifying common and reusable components in the various modules
and merging them. All of these modules and components will be represented
in a number of class diagrams of varying granularity. For example, a high
level class diagram may have a more detailed class diagram defining the
make up of one of its classes.
In terms of
the user interface, Use Cases will be created for all of the functionality
intended to be incorporated and from those define, initially on paper,
the user interfaces. This will be going on in parallel to the module design
process.
2.2
Software Process
Given the fact
that this will be an object oriented design to be implemented in an entirely
object oriented language, the classes identified will map 1:1 to the classes
we implement in Java.
2.3
Core Functionality
Of the functionality defined
in section 5 only the following will definitely be implemented, with the
rest to be implemented time permitting.
5.1 CRUD Project
5.1.1 Create New Project
5.1.1.1 Edit Properties of Project
5.1.2 Add Model to Project
5.1.3 Open Project
5.2 CRUD Workspace
5.2.1 Create New Workspace
5.2.2 Add Project to Workspace
5.3 CRUD Model
5.3.1 Create New Model
5.3.1.1 Edit Model
5.3.1.1.1 Select a tool from the palette
5.3.1.1.2 Place node on Model
5.3.1.1.3 Connect nodes with an arc
5.3.1.1.4 Select selectable item
5.3.1.1.5 Deselect selectable item
5.3.1.1.6 Move selection
5.3.1.1.11 Delete selected items
5.3.1.1.12 Evaluate rule
5.3.2 Assign Meta-Model to Model
5.3.3 Assign Package to Model
5.3.7 View Model
5.3.7.1 Display Visible Nodes in a viewport
5.3.7.2 Display Visible Arcs in a viewport
5.3.7.3 Transform local coords to viewport coords
5.3.7.4 Zoom view in/out
5.3.7.5 Pan view left/right/up/down
5.4 CRUD Meta-Model
5.4.1 Create New Meta-Model
5.4.2 CRUD Meta-Nodes
5.4.2.1 Specify Type
5.4.2.2 Specify Properties
5.4.3 CRUD Meta-Arcs
5.4.3.1 Specify Type
5.4.3.2 Specify Properties
5.4.4 CRUD Meta-Rules
5.4.4.1 Specify Type of Meta-Rule
5.4.4.2 Specify Components of Meta-Rule
5.4.4.3 Specify Meta-Condition |
5.5 CRUD Package
5.5.1 Create New Package
5.5.1.1 Select Meta-Model to Implement
5.5.2 CRUD Package Node
5.5.2.1 Specify package node shape
5.5.2.2 Specifiy display information for a meta-node's properties
5.5.3 CRUD Package Arc
5.5.3.1 Specify default line type (straight, curved, stepped)
5.5.3.2 Specify ard graphic and it's location
5.6 File I/O
5.6.1 Save Project/Model Locally
5.6.1.1 Save Locally
5.6.1.2 Check-In to Remote Server
5.6.1.3 Resolve Conflicts
5.6.2 Check-Out Project/Model
5.6.7 Import Model from JMetric
5.7 Communications
5.7.1 Logging in to Server
5.7.2 Logging out from Server
5.7.3 Send SMTP Message
5.7.3.1 Select Receiver from Address Book
5.7.5 Send Direct Internal Message
5.7.5.1 Select Logged on Users to Receive Direct Message
5.7.5.2 Select Message to Reply To
5.7.5.3 Reply To a Direct Message
5.7.8 Modify Address Book
5.7.9 Receive Direct Message
5.8 Administration
5.8.2 Create Users and Groups
5.8.2.1 Create/Edit/View User
5.8.2.1.1 Add User
5.8.2.1.2 Edit User
5.8.2.1.3 Remove User |
3.
Product Characteristics
3.1
Functions
The software
is based on a client server architecture, with one server capable of handling
up to 20 clients. The functionality supported by the software is described
in detail in [Section
5]. This functionality can be described in a number of major functional
areas. These areas include:
-
User management:
Create and maintain a list of users who can use the system.
-
Messaging:
e-mail messages can be sent and direct messages can be sent and received.
-
Address book:
Both a global and a local address book can be maintained.
-
Project management:
A project can be stored locally or remotely. A project can contain a number
of models.
-
Edit Models:
The models are the main functionality of the system. Each model represents
a semantic net which is drawn using a certain meta-model. This then allows
the generation of the following graphs:
| Diagram
Name |
Notation
Support |
| System Context
Diagrams |
OML |
| Software Context
Diagrams |
OML |
| Class Diagrams |
OML, UML |
| Package Diagrams |
OML, UML |
| Inheritance
Diagrams |
OML, UML |
| Deployment
Diagrams |
OML |
| Use Case Diagrams |
OML, UML |
Table
3.2.1 - 1: model.
-
Meta-model:
The meta-model architecture allows the above mentioned diagrams to be customised
to incorporate enhancements, or new meta-models can be created to allow
new diagrams to be created. Such diagrams might be entity-relation diagrams
or state transition diagrams.
-
File Management:
Both projects and models can be stored locally for individual use or stored
remotely so that a number of people can access them. If a more than one
person uses a remote file, then a Concurrent Versioning System is
used to maintain one master copy, and changes made are integrated into
this copy. This way, users do not need to use any locking and if a conflict
occurs, only one person needs to decide which parts of the conflicts to
use.
3.2 Performance
The performance
of this product is dependant on the underlying hardware. To ensure the
specified performance can be achieved, the following hardware is required.
Further details are listed in [Section
10].
Intel Pentium
II 333MHz
64 Megabytes
Primary Memory (RAM)
10 Megabytes
free Hard Disk space.
10 Megabit
per second Ethernet connection
The product
may still operate on hardware that does not meet this specification, but
on this specification, it can be guaranteed to meet the specified performance.
Increasing the specification may lead to better performance.
3.3
Interfaces
The client software
will make extensive use of Windows GUI features. In particular, the
point >click and click > drag features. To support the user interaction
with the software, the following interface devices have been identified
and will be supported:
3.3.1
Mouse
The mouse is
the major input device, allowing the models to be created and edited. Many
functions can be
done without a mouse, but a mouse is required for full functionality.
This does not strictly have to be a mouse, any two buttoned pointing device
should be sufficient.
3.3.2
Keyboard
The keyboard
is required for entering textual information. Most of the node properties
will be text based so require the keyboard for input. Some GUI based
functions can also be performed using the keyboard.
3.3.3
Screen
The screen is
the major output device. It supports the GUI interface by providing
the user with feedback relating to the mouse and keyboard, as well as the
content of the application, namely the models. The screen should
support 256 colours in 1024x768 resolution.
3.3.4
Printer
A printer allows
hard copies of the models to be printed. Either a local or networked
printer should be suitable. A printer capable of printing black and
white in 300 dpi should be sufficient.
4.
User Characteristics
We have identified five potential
classifications of users of our system:
-
Software Designers: These are
the most obvious users. They will use the system as a means of laying out
the design of an as yet unimplemented system.
-
Software Developers: These
are the people that take the model generated by the designers and implement
it in code. They may also use the system to identify the design of
an existing system in order to maintain it.
-
Quality Engineers: These
users are usually responsible for ensuring that a design is feasible and/or
reliable. They will therefore also need to be looking at the output from
our system.
-
System Administrator: Due to
the client/server/concurrent nature of the system, some one needs to be
responsible for security and maintenance of the system. This is the System
Administrators role. The Administrator of the system, project or
model need not be a member of the any of the other roles identified here.
-
The Client: More often
than not, software is designed for a client. The client may wish to see
the design as layed out by the system and be able to see what exactly they
are buying.
4.1
The General User
All users can
be assumed to have the following characteristics:
-
Ability to read
and understand English.
-
Familiarity with
the operation of the basic Graphical User Interface (GUI) components of
the Windows NT operating system.
-
Beyond the above,
no further facility with computer technology can be assumed.
4.2 The
Software Designer
The Software Designer users
can be assumed to have the following characteristics:
-
A thorough knowledge of object
oriented design notation.
-
Familiarity with common design
environments. For example, the concept of selecting a tool to draw with.
-
Software Developers User Characteristics.
4.3 The
Quality Engineer
The Quality Engineer users
can be assumed to have the following characteristics:
-
A throrough knowledge of object
oriented design notation.
4.4 The
Administrator
The Administrator users will
not be required to have any specific characteristics.
4.5
The Client
Rudimentary understanding
of modelling techniques. (Won't necessarily have to use the system, just
look at its output).
|
|
