Software Requirements Specification (SRS)

Shopping E-Commerce Website (SECW)

Name: Mohit Gulathi

Roll. No. : 59
Registration no.: 12217497
Section: K22SW
Course Code: INT222

1 Introduction
The Software Requirements Specification is designed to document and describe the
agreement between the customer and the developer regarding the specification of the
software product requested . Its primary purpose is to provide a clear and descriptive
“statement of user requirements” that can be used as a reference in further development
of the software system. This document is broken into a number of sections used to
logically separate the software requirements into easily referenced parts.

This Software Requirements Specification aims to describe the Functionality, External

Interfaces, Attributes and Design Constraints imposed on Implementation of the
software system described throughout the rest of the document. Throughout the
description of the software system, the language and terminology used should
unambiguous and consistent throughout the document.

1. Purpose
An ecommerce website serves as an online platform where consumers can browse,
select, and purchase products or services from the comfort of their homes. It provides
a convenient and accessible shopping experience, allowing users to compare prices,
read reviews, and access a wide variety of products from different sellers all in one
place. Additionally, ecommerce platforms often offer secure payment options, fast
delivery, and easy returns, enhancing customer satisfaction and trust.

For businesses, these websites expand market reach, reduce operational costs, and
provide valuable insights through customer data analytics, ultimately driving sales and
fostering growth in the digital marketplace.
2. Scope

1.Convenience: Ecommerce platforms provide unparalleled convenience, allowing

consumers to shop anytime, anywhere, without the constraints of physical store hours or
locations.
2.Product Variety: Consumers have access to a vast array of products from various
sellers, brands, and categories, enabling them to compare prices, features, and reviews to
make informed purchasing decisions.
3.Personalized Shopping Experience: Advanced algorithms and data analytics enable
ecommerce websites to offer personalized product recommendations based on user
preferences and browsing history, enhancing the overall shopping experience.
4.Secure and Seamless Transactions: Ecommerce platforms employ robust security
measures to protect sensitive customer information, ensuring safe and hassle-free
payment transactions.
5.Flexible Payment Options: Consumers can choose from a variety of payment
methods, including credit/debit cards, digital wallets, and cash on delivery,
accommodating diverse preferences and needs.
6.Easy Returns and Exchanges: Many ecommerce websites offer straightforward
return and exchange policies, providing consumers with confidence and reassurance
when making online purchases.
7.Global Market Reach: Ecommerce websites enable businesses to reach a global
audience, expanding their market reach beyond geographical boundaries and traditional
brick-and-mortar limitations.
8.Cost-Efficient Operations: Operating an online store often incurs lower overhead
costs compared to physical retail establishments, resulting in increased profitability and
competitive pricing strategies.

3. Definitions, acronyms, and abbreviations

SECW Shopping E-Commerce Website

Barcode A unique identifier assigned to single items
Device An instance of an Item that has these additional attributes: Name,Price
Button A user interface element that allows a User to click and inform the
system to take an action
Checkbox A user interface element that allows a User to inform the system that
he/she selected a particular item
Checkout The process a Customer goes through to purchase an Item
CRUD Create, Retrieve, Update, Delete
Customer A person that is a user of the system but has created an account
Inventory An object that holds items available for purchase by the Customer
Item An individual entity in the inventory which has several descriptive
attributes:
 Barcode, Price, Reorder Threshold, Stock
Manager A single person that has the ability to create, retrieve, update and delete
items in the store. This person cannot simultaneously act as a Customer
and Manager.
Member A person that is a customer of the system and has requested to be sent
promotions
Promotion An item-wide percentage-off price discount applied to a Member's
shopping cart
Reorder The system process that automatically orders new stock of an item
Reorder The numeric value of an item's stock that must be reached before the
Threshold system will order additional quantities of the item
Session The time which a User is actively using the system
Shopping Cart An object that lists a Customer's selected Items, their applied
promotions and gives them an option to check out
SRS Software Requirements Specification
Stock The quantity of any particular item the inventory has on hand
Text Box A user interface element that allows a User to input text to the system
Transaction The information related to a customer's purchase that is logged
User The person who operate the software product.

1.4 Organization
This Software Requirements Specification document is divided in to multiple
subsections. The first section includes explanations of the Purpose, Scope and
Organization of the document. The first section also handles the description of project-
specific words, acronyms and abbreviations that will be used in the document. The
second section of the document is separated into the following five different sections,
each detailing specific details of system uses and their corresponding actions: Product
Perspective, Product Functions, User Characteristics, Constraints, Assumptions and
Dependencies, Apportioning of Requirements. The third section is an enumerated listing
of all of the requirements described for this system. The fourth section encompasses all of
the Use-case, Sequence, State and Class diagrams that model the system. In the fifth
section there exists a Prototype of the system along with a sample scenario that
graphically describes the use of the system. The sixth section contains a listing of all
related reference materials used in this document. The seventh and final subsection is
dedicated to providing a point of contact for any viewer of this document.

2 Overall Description
This section includes details about what is and is not expected of the SECW
system in addition to which cases are intentionally unsupported and assumptions that
will be used in the creation of the SECW system.
1. Product Perspective
SECW is an online Shopping website which supports a number of functions for both
the consumer and store's management.

The website must be available to anyone using the Computer Science Department’s
provided computer resources in the MSU Engineering Building and as such must work
correctly in both Internet Explorer and Mozilla Firefox. As stated by the customer, there
are no hardware or software requirements beyond these including, but not limited to,
memory or specific software packages that need to be utilized nor software packages that
need not be utilized.

2. Product Functions
SECW will provide a number of functions; each is listed below.
 Maintain data associated with the inventory
 A device has a name, company and price tag
 The inventory also keep track of the stock/quantity of each device
 Maintain records for many customers
 A customer can be either a member or non-member.
 A customer has a username (unique across all users), password (no restrictions), email
address (no restrictions), and postal address (unverified.)
 Anyone may sign up for a customer account.
 Allow any customer to become a member.
 Show a listing of available device
 Devices are to be displayed in ascending order by Price.
 Each device will list the following from left to right
 Name
 Company
 Price
 Allow customers and managers to log in and out of the system.
 Users (both customers and the manager) will be logged out if inactive for 30 minutes.
 Shopping cart
 Anyone is able to add one or more gadgets to the shopping cart.
 The shopping cart does not need to allow multiple copies of any device.
 Checkout
 Checkout is only available to logged-in customers. A user that is not logged in as a
customer is given a chance to log in.
 Member customers may enter a promotion code.
 Only one promotion code may be used per purchase
 The promotion is a fixed percentage discount that is to be applied to an entire
order.
 The discount is specified by the manager at the time of the promotion’s creation or
 Collect
mosta 16-digit
recent update/edit.
credit card number from the customer
 Log/record the transaction
 Allow manager to specify a stop-order for a device
 Each device has its own stop-order status – either on or off. Details of its use are
involved in the following feature.
 Notify manager when device need to be reordered
 When the quantity a book falls below a threshold, the manager is notified that the device
 needs to be reordered.
 One exception is if the manager has already specified a stop-order for this device.
 Every book must either have stop-order enabled or disabled
 Allow manager to update stock quantities
 Allow manager to change any device's price
 Allow manager to view transaction logs
 Allow manager to create promotions
 A promotion is a percentage discount that can be applied to an entire order
 Promotions may only be used by member customers
 A promotion has an expiration date specified by the manager
When a promotion is created, it is emailed to all member customers via the email address on
record

3. User Characteristics
The typical SECW user is simply anyone that has access to the Internet and a web
browser in the computer science department. It is assumed that the user is familiar
enough with a computer to operate the browser, keyboard and mouse and is capable of
browsing to, from and within simple websites .

4. Constraints
As stated by the customer, security is not a concern for this system. The database may
store passwords in plain text and there doesn't need to be a password recovery feature nor
lockout after numerous invalid login attempts. As such, the system may not work
correctly in cases when security is a concern. These cases include those listed above in
addition to lack of an encrypted connection when sending credit card information and
forcing users to use “strong” passwords. A strong password is a password that meets a
number of conditions that are set in place so that user's passwords cannot be easily
guessed by an attacker. Generally, these rules include ensuring that the password contains
a sufficient number of characters and contains not only lowercase letters but also capitals,
numbers, and in some cases, symbols.

The system may not behave correctly when used with Internet browsers other than
Firefox and Internet Explorer.

SCR "Software Cost Reduction (SCR) is a set of techniques for

designing software systems developed by David Parnas
and researchers from the U.S. Naval Research Laboratory
beginning in the late 1970s." [7]
Mode Class "A mode class is a finite state machine, with states called
system modes" [8]
System State The current state or mode that the system is in. The system
must be in exactly one state at any moment in time.
Event An event is any action that can trigger an action within the
software system. Examples include but are not limited to
changing values of variables or user-triggered events.
Event Notation We may need to refer to both the old and new value of a
 variable:
Used primed values to denote values after the event
@T(c) ≡ ¬c ^ c’ e.g. @T(y=1) ≡ y<>1 ^ y’=1
@F(c) ≡ c ^ ¬c’
A conditioned event is an event with a predicate
@T(c) WHEN d ≡ ¬c ^ c’ ^ d [8]
Controlled Variable A variable whose value can change throughout the lifetime
of the system and whose value is critical and must
be
maintained correctly.
Mode Transition When the mode (state) changes from one mode (described
as the old mode) to a new mode.
Mode Class Table Table consisting of a list of modes that the system can be
in, modes that can be transitioned to, and the
conditions
required for the transition to occur. The table if formatted
such that the first column lists the current mode (old
mode) and the last column lists the new mode. The
columns between the first and last columns each describe a
specific event.
Event Table An event table illustrates how an input event can affect a
controlled variable. The first column shows modes and the
last row shows the values that the controlled variable will
be set to. The remaining cells are conditions required for a
mode to affect the value of a controlled variable.
Condition Table A condition table shows the conditions (one of which must
be met) in order for a controlled variable to be set to
some
specified value. The first column lists modes and the last
row names the controlled variable and the values it is
set
to.

Condition Table
Mode Conditions
AddPromotion TRUE FALSE
PromotionAdded TRUE FALSE

Mode Class
Old Mode Login IsManager IsCustomer Logout New Mode
UserLoggedOut @T t - - ManagerLoggedIn
 @T - t - CustomerLoggedIn
ManagerLoggedIn - - - @T UserLoggedOut
CustomerLoggedIn - - - @T UserLoggedOut

Event Table
@T(User::Login() ==
UserLoggingIn TRUE) never
@T(Logout() ==
UserLoggingOut never TRUE)
User::LoggedIn TRUE FALSE

Condition Table
Mode Conditions
UserLoggedOut FALSE TRUE
ManagerLoggedIn TRUE FALSE
CustomerLoggedIn TRUE FALSE
UserLoggedIn TRUE FALSE
3 Specific Requirements
1. Restrictions
1. User Side
1.1.1.Software
1.1.1.1. Internet Explorer or Mozilla Firefox
1.1.2.Hardware
1.1.2.1. Computer Science Department
Laboratory Terminal
1.2. System Side
1.2.1.Software
1. Web-
based
applicat
ion
2. Databas
e
informa
tion
storage
system
2. Data Structure
1. Device has these
attributes
1. Unique ID (auto-increment starting at 1)
2. 2.1.2.Name
2.1.3.Company
2.1.4.Price
2.2. Customer has these attributes
2.2.1.Unique Username
2.2.2.Password
2.2.3.Name 2.2.4.Email Address
2.2.5.Postal Address
2.2.6.Member/Not Member
Boolean value
3. Manager has these attributes
2.3.1.Username 2.3.2.Password
2.3.3.Email address
4. Order log entries have these attributes:
2.4.1.Unique ID (auto generated)
 2.4.2.Time transaction took place
2.4.3.Date transaction took place
2.4.4.Username of customer
2.4.5.Listing of the contents in
customer’s shopping cart
3. System
1. Browse Inventory
3.1.1.Organization
1. It
e
3.1.1.3.1.m Name
3.1.1.3.2.s Company Name
3.1.1.3.3.Li Price
4. st
Listing sorted by Ascending item price
ed
3.1.2.Interaction
5. on
Each Item has checkbox to mark selection
6. si
Single button to add all selected items to Shopping Cart
2. Search Inventoryng
le
1. Search available only by Item name
pa
2. 3.2.2.Search is exact-match only
ge
3. Create, Update and Destroy (CRUD) Functionality
2. It
3.3.1.Only managers are allowed to modify inventory
e
2. Managers have an interface to:
m
1. Create a item entry
s
2. Update a item entry
sh
3. Update the stock/quantity of a particular
o
device
w
4. Create a new promotion
n
5. Review current inventory
in
1. Using the same interface to browse inventory as described in section 3.1, the
ta
manager has an additional “Edit Item” option for each device.
bu
1. Manager has full CRUD capabilities on each device.
la
3. Managers may delete items from the inventory
r
3.4. Shopping Cart
fo
3.4.1.Logged In
r
1. Can
m
add
at
items
3. E
to cart
ac
3.4.1.1.2.
1. If Item Customer can only
is not in stock, purchase
message one ofinforming
displayed each itemuser
(no to
quantities
try again later
h
associated with orders)
It
3.4.1.1.3.
e
3.4.1.2. If shopping cart not empty, a user may begin Checkout procedure
m
3.4.2.Not Logged In
lis
1. Can add items to cart
ti
2. User required to login before they may begin Checkout procedure
ng
5. Checkout procedure
co
1. User must successfully use shopping cart before beginning this procedure
nt
3.5.2.Checkout page consists of
ai
1. A text box for promotion entering
ns
2. An overview of the purchase
 3. A text box to hold the credit card number
4. A button to complete the order
3. Order details sent via email after the checkout has completed
4. On order completion the inventory is decremented based on items purchased by
user
3.6. Authentication System
3.6.1.User Levels
1. Mana
ger
(singl
e,
hardc
oded
user,
no
orders
)
2.Customer (unlimited, open creation, unlimited orders)
3.6.2.Account Creation
3. Everyone is allowed to create an account
4. Required Information
1. Listed in section 2.2
5. Account Modification
1. Users are not able to modify any aspect of their account after creation (“it
would be nice but not needed”)
6. Login and Logout
1. There is no lost-password recovery
2. Logging in allows one to logout
3. Logging in allows checkout
4. There is a 30-minute session time out after which a logged in user will be
logged out automatically.
3.7. Promotions
3.7.1.Specifications
5. Ap
pli
es
to
ent
ire
ord
er
6. Per
cen
3.8.1.2.1. If the item has a stop-order applied to it, it will not automatically
tag
reorder until the manager removes it.
e-
3.8.1.3. A manager may increase the stock of an item using the
off
manager’s account
typ
3.9. Order Logging
e
3.9.1.Specifications
pro
1. Re
mo
qui
tio
red
nInf
(x
or
%ma
off
tio
ent
n:
1. ire L
4 Modeling Requirements

Use Case Diagram

The purpose of this diagram is to demonstrate how objects will interact with SECW and
map out the basic functionality of the system. Below is a list of the elements that you
will see in the diagram on the next page as well what is included in the use case templates
that follow.

Actors Shown in the diagram as stick figures with a name

underneath. They represent elements that will be directly
interacting with the system.
Use Cases Oval shapes that have their names in the center. These
represent direct functionality within the system that must
be implemented.
Interactions Lines that connect the actors with the different Use Cases.
These show that there is some form of direct interaction
between the actor and that specific functionality.
Includes Dotted lines labeled “<<include>>” that connect two use
cases and have an arrow pointing towards one. This
means that the use case without the arrow calls on the
functionality of the use case with the arrow.
Extends Dotted lines labeled “<<extend>>” that connect two use
cases and have an arrow pointing towards one. This
means that the use case without the arrow takes all of the
functionality of the use case with the arrow and adds extra
functionality.
The System Boundary The large rectangle that contains the Use
Cases. Everything within the rectangle is what the system
is
responsible for implementing
Use Case Template Describes the basic functionality and features of each use
case and the can be found in the pages following the use
case diagram.
Type A field in the use case template that states whether or not
the use case is directly interacted with by an actor
(Primary) or not (Secondary) as well as whether or not it is
essential to having a functioning system.
Cross Ref A field in the use case templates that states which one of
the original requirements that particular use case satisfies.
Use-Cases A field in the use case templates that state which other use
cases must be executed prior to that particular use case.
Use Case: Login
Actors: Manager, Customer
Type: Primary and essential
Description: Initiated when a user
attempts
prompted to enter anusername
in their action and password in order to proceed.
Includes: that
None is restricted. The
Extends: user is then
Cross Ref: None
Use-Cases: Requ
ired
Use Case: for 2
Logout
Actors: None
Manager, Customer, System
Type: Primary and essential
Description: The customer or manager
will have
inactive for a given theof
amount option
time to
then that user should be logged out by the system
automatically. logout and if that user is
Includes: None
Extends:
Cross Ref: None
Use-Cases: Requ
ired
Use Case: for
Browse Inventory
Actors: 3.61
Manager, Customer
Type: User
Primary and Essential
Description: must
All the devices in the
have
inventory are listed
comp
on a single
including its Name, company,pageand
with
price. List should be sorted by name.
Includes: leted
each
None device,
the
Log
In
use
Extends: None
Cross Ref: Required for 4
Use-Cases: None

Use Case: Add Items to Cart

Actors: Customer
Type: Primary and Essential
Description: Allows the Customer to place items selected in the Browse Inventory
screen to their shopping cart for later purchase.
Includes: None
Extends:
Cross Ref: None
Use-Cases: Requ
ired
Use Case: for Item
Add
Actors: Elicit
Manager
Type: ation and Essential
Primary
Meet the Manager to add an additional device to the inventory that
Description: Allows
ing
should,
Custprice, name, number in stock, stop-order, and reordering
include the device
threshold. omer
must
Includes: None
have
Extends:
Cross Ref: comp
None
Use-Cases: Requ leted
Use Case: the Item
Edit
ired
Actors: Log
Manager
for 1
Type: In
Primary
Man
use the
Description: Lets
ager
inventory. case.
None
Manager
must
Includes: edit
haveall of
Extends: None
the
comp
Cross Ref: Requ
attributes
leted
Use-Cases: ired of
thea
Use Case: for
Add1 Promotion
particular
Log
Actors: and 5in
Manager
item
In
Type: Man
Primary
the
use
Description: ager
This allows the
case
must
manager
percentage off for to add
members. This will email all customers who are members to inform
them of the newhave
a promotion.
special
Includes: promotion such
comp
None
Extends: as a certain
leted
Cross Ref: the
None
Use-Cases: Requ Log
ired
In
Use Case: for
use 5
Checkout
Actors: Man
Customer
case
ager
must
have
comp
leted
Type: Primary and Essential
Description: This takes the items in the customers shopping cart and processes them for
a purchase.
Includes: Use Promotion
Extends: None
Cross Ref: Required for 3
Use-Cases: Customer must
have
Use Case: Use Promotion
completed the
Actors: Customer
Log In use
Type: Primary
case
Description: If the user is a
promotion codemember
that willthey
take off a percentage from the total.
Includes: are presented
None
Extends: with the option
Cross Ref: to enter in a
None
Use-Cases: Requ
ired
Use Case: Purchase
for 6 Item
Actors: Customer
Cust
Type: Secondary
omer
Description: must
Acted on when
the
decrements thehave user presses
inventory of all items within the order, email the user, create a log of the
the
transaction, andcomp finalize
check stock to see if a reorder needs to take place.
Includes: order Email,
Send
leted button Check
in Stock
Extends: checkout.
None
the This
Cross Ref: Required
Log for 3 and 7
Use-Cases: Customer
In must have
completed
and the Log In and
Use Case: Check
Chec Stock
Checkout use cases
Actors: System
kout
Type: Secondary
use
Description: Checks to
cases
seeinifstock
see if the amount stop- is below the reorder amount. If it is then it will reorder.
Includes: order is on Reorder
Send Email,
Extends: for a
None
Cross Ref: particular
Required for 5
Use-Cases: item Noneand if it
is checks to
Use Case: Reorder
Actors: System
Type: Secondary
Description: Reorders a particular item and emails the manager.
Includes: None
Extends: None
Cross Ref: Required for 5
Use-Cases: None
Use Case: Send Email
Actors: System
Type: Secondary
Description: This is
be sent. called by a
Includes: None
variety of
Extends: Add
otherPromotion
use
Cross Ref: cases
Required for 5, 6, and Elicitation Meeting
Use-Cases: whenever
None
an email
needs to
Class Diagram

The purpose of this diagram is to show how objects within the SECW system will
interact with each other in order to achieve the functionality required by the Use Case
diagram.
Below is a list of what you will see in the diagram itself as well as the class descriptions
that follow.
Classes Rectangles in the diagram that are split into three parts. The
top section is the name of the class, the middle section is the
list of variables that are stored in the class and the bottom
section is the list of functions in the class. These
rectangles
represent objects within the system.
Variables These have a name followed by a semicolon and then a type.
The type denotes what kind of data can be stored in the
variable.
Functions These have a name followed by a list of any variable that the
function receives in-between the parenthesis “()”. After that
there is a semicolon and any variables that the function may
return, if none it will be void.
Generalizations Shown using a line from one object to the other with an
unfilled triangle on one end. The object without the triangle
inherits the functionality and variables from the object that has
the triangle pointing towards it.
Aggregations Lines that have an unfilled diamond on one end. This means
the object with the diamond contains the object(s) without the
diamond. This may have numbers on the ends (multiplicities).
Associations Lines connecting two classes that can have a name beside it,
may point in one direction, and may have numbers at the
ends
(multiplicities). These designate some relationship
between the objects. Arrows are simply there to
assist you in
recognizing which direction the name of the association is
read.
Multiplicities Numbers that may be on the ends of Aggregations and
Associations. They state how many of the one object can be
 This is a base class in which manager and customer extend. This
class provides the login ability that is shared between the two as
well as some shared variables.
Public: Yes
User Associations: None
Relationships Aggregations: None
Generalization: None
Variables - Username:String, Password:String, Email:String,
LastActivity:Time, PostalAddress:String, Name:String,
LoggedIn:Boolean
Functions - Login(), Logout()

Class
There is only one instance of this class because there is only one
manager. This manager has the additional ability of adding items,
Manager creating promotions, and modifying books.
Public: No
Associations: Inventory, Book, Promotion
Relationships Aggregations: None
Generalization: User
Variables - None
Functions - None

Class
There are many customers in the system and they all have their
own shopping cart. A customer is a member if IsMember is set to
True.
Customer Public: No
Associations: Shopping Cart
Relationships Aggregations: None

Variables - IsMember:Boolean Generalization: User

Functions - None

Class
This class contains a list of items and all the functions that are
Inventory required to be acted on those items. The functions AddItem(),
SetPrice(), and SetReorder() are only accessible by the Manager.
PurchaseItem() only by a Shopping Cart. Browse() can be
accessed by any User.
Public: No
Associations: User, Manager, Shopping Cart
Relationships Aggregations: None

Variables - Items:Vector Generalization: None

 Functions - PurchaseItem(), AddItem, Reorder(), SetPrice(),
SetReorder, Browse(), Email()

Class
This is a single item in which there are many in the system and
they are all part of the inventory. They can also be a part of
shopping carts and a transaction.
Public: No
Item Associations: None
Relationships Aggregations: Inventory, Transaction, Shopping
Cart
Generalization: None
Variables - Barcode:Int, Price:Double, Reorder:Boolean,
ReorderAmount:Int, Stock:Int
Functions - CheckStock()

Class
This is a specific type of Item that has the additional values of
Public: NoAuthor and it can be modified by a manager.
Title and
Book
Associations: Manager
Relationships Aggregations: None
Generalization: Item
Variables - Title:String, Author:String
Functions - None

Class
The manager can create a promotion and when it is created an
email is sent to all customers who are members to inform them of
the new promotion. The promotion is for a percentage off of an
order and they have unique codes and expiration dates. The
Promotion promotion can be added to a customer’s shopping cart.
Public: No
Associations: Manager
Relationships Aggregations: Shopping Cart

Variables - Code:String, Percentage:Double, Experation:Date

Generalization: None
Functions - Email()

Class
Transaction This is created when an order is processed and it is the record of
the order which includes who placed the order, the time and date it
was placed, and the list of items that were purchased.
Public: No
 Associations: Shopping Cart
Relationships Aggregations: None

Variables - TimeDate:Time, Username:String, Items:Vector

Generalization: None
Functions - None

Class
Each customer has its own shopping cart and it stores items and is
responsible for processing the order for the customer.
Public: No
Shopping Cart Associations: Customer, Inventory
Relationships Aggregations: None

Variables - Items:Vector, PromotionAdded:Boolean

Generalization: None
Functions - AddPromotion(), Checkout(), AddItem(),
RemoveItem(), Email(), BrowseCart()

Sequence Diagrams

The sequence diagrams use the class diagram and demonstrate specific sequences of
actions in the system. The purpose is to ensure that the SECW system runs in an expected
way and that the class structure is sufficient to accomplish the tasks needed. Below is a
list of the items that you will see in the diagram and their definitions.

Axis’s The x-axis identifies movement between objects and the y-

axis identifies time.
Comments These are the boxes that are along the left side. These explain
the actions that are occurring in the sequence and
other helpful information.
Instances Solid boxes along the top that have dotted lines that stretch
vertically below them. These are
specific instances of an object. The first part of the title is the
name of that specific instance and the object it is
an instance of follows it. (Special Note: If there are multiple
instances that have the same title then they are actually the
same instance and are only there to diagram calls onto
themselves.)
Calls Lines that have filled triangles at the ends. These are
transitions from one instance to another and have a label
above them that is a function call, a variable being set, or both.
It can also have a guard statement that precedes it.
Variable being set Have a variable name followed by either a ‘:=’, ‘+=’, or ‘-=’
and then another variable name with the first being set to the
 later.
:= means that its being set directly to the variable that follows.
+= means that the variable that follows is being added to the
current value.
-= means that the variable that follows is being subtracted from
the current value.
Guard Statements These are located between brackets ([])and come before the
function in a call. This means that the condition must be true
in order to make that call.
Returns These are represented by dotted lines with an arrow at the end.
These simply represent a return from a function call.
Object Execution Time This is shown with the solid white boxes that run vertically
along the dotted lines. These simply represent the execution
time for the objects. (Special Note: the first object has a solid
box all the way down this is a special case and should not be
there and is due to the application used to create the diagram).
State Diagrams

The state diagrams take all of the functionality found in the previous diagrams and
combines them together to demonstrate the possible changes in the state within BECS.
These state diagrams contain all the possible scenarios shown in the sequence diagrams.

Starting Point This is where the system starts at and it is represented with a
filled circle that has an arrow that point towards the starting
state.
States These are represented in the diagram by the boxes that have
the rounded edges. They are separated into two half’s the
top
half is the title of the state and the bottom half can have
additional states encapsulated within but these state diagrams
do not contain any encapsulated states within states.
Transitions The arrows that connect the states to each other and have a
label of the event that occurs which triggers the transition.
These triggers are normally functions but they can also be a
new call that is the event of creating a new object; this is
represented simply with the word “new”. Some transitions do
not have a label, these are returns from the current state to the
previous state.
Objects The larger boxes that can contain several states and
transitions. They are classes within the state diagram. The
text at the top of the box is the name of the class.