URD

User Requirements Document
Results include:
What happens if the consumer wage remains constant and if it increases by a
small random value (<5%) every 100 cycles?
Does the number of factories owned by each producer reach a stable number?
consumers>=several hundred
10 producers
5 products
each producer has one factory at the start, which can only produce one product at a
time.
Up to me to decide what the price will be for each product.
Contents
No.
Page
1. Introduction...............................................................................................................1
1.1
Purpose...............................................................................................................
1.2
DocumentConventions........................................................................................1
1.3
Intended Audience and Reading Suggestions.................................................... 1
1.4
Project Scope .....................................................................................................
1.5
References..........................................................................................................
2. Overall
Description..........................................................................................................4
2.1 Product Perspective............................................................................................. 4
2.2 Product Features..................................................................................................4
2.3 User Classes and Characteristics ..................................................
2.4 Operating Environment ..................................................
2.5 Design and Implementation Constraints..................................................
2.6
User Documentation ..................................................
2.7
Assumptions and Dependencies ..................................................
3. System Features
3.1 Customer
3.1 System Feature 1 - WageIncrease..................................................
3.2 System Feature 2 - - cashRunOut ..................................................
3.3 System Feature 3 - - updateCus ..................................................
3.4 System Feature 4 - priceOfProduct..................................................
3.5 System Feature 5 - buildFactory..................................................
3.6 System Feature 6 placeOrder ..................................................
3.7 System Feature 7 updateAll ..................................................
3.8 System Feature 8 updateProd ..................................................
3.9 System Feature 9 update ..................................................
3.9 System Feature 10 putOrder ..................................................
3.9 System Feature 11 - - cycle1..................................................
3.9 System Feature 12 - genRanInt..................................................
3.9 System Feature 13 - genRanNum..................................................
3.9 System Feature 14 cashCus..................................................
3.9 System Feature 15 newcycle..................................................
4. External Interface Requirements

4.1
User Interfaces - GUI ..................................................
4.2 Hardware Interfaces ..................................................
4.3 Software Interfaces ..................................................
4.4 Communications Interfaces ..................................................
5. Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements.............................................................................................
5.3
Security Requirements...................................................................................... 29
5.4 Software Quality Attributes.....................................................................................
5.5
Other Requirements GNU GPL License ............................................................
6. Appendix
6.1
Appendix A: Glossary
6.2 Appendix B: Analysis Models Use Case diagrams
6.2.1 Use case 1 - Splitting a pdf document:
1. Introduction
This section introduces software requirement specification. It explains to us the
purpose scope of the software we are developing and also explains definitions and
references.
1.1 Purpose
Thi requirements specification document for the - Economic Modeling of Supply Chain
Logistics project. The aim of this document is to cover all areas require by this SRS
including description, system features, interface requirements and other components.
1.2 Scope
The Economic Modeling of Supply Chain Logistics project describes the functions and
requirements specified for a model illustrating the multitude of economic relationships
between producers and consumers, through studying the interactions between them
over a series of different cycles.
Cycle 1 - Focuses on the wage of the consumer remaining the same.
Cycle 2 - Wage of consumer rises randomly 5% every 100 cycles.

In particular we will be focusing on these main issues over the period of the cycles.
If the number of factories owned by each producer reached a stable number?
What happened if the consumer wage remained the same?
What happened if the consumer wage increased by a small random value less
than every 100 cycles?
It will then be used as a modeling tool to help businesses future
1.3 Definitions
Listed below are all of the definitions, abbreviations and acronyms used in this
document
Term Definition
SRS - Software Requirement Specification
IDE - Integrated Development Environment
1.4 Syste Overview

This document is intended for client and technical designers of this software.
The Introduction - Part 1 deals with the general info about the project including whats
its about, references, and definitions; and presents us with a given name for the
product.
Part 2-
1.5 References
Stuart Barnes notes - Advance Software Engineering
2. Overall Description
This section provides a background for the product requirements making them easier
to understand
2. Product Perspective

This product is going to be developed by a company, which develops similar products
for market, or economic research for a company whom desires research done based
on specifications sent to them. It is a smaller part of an existing software company.
The structure for how the project will be executed and results fed back to the client is a
method, which has been tried and tested. This leaves us being able to focus on the
creation specific to the clients brief.
2.2 Product Features
This diagram shows what the model functions the model should be able to carry out
1.1:
Alongside the features described on this diagram, the model should also be able to
provide outcomes for different forecasting estimations of economic growth for clients in
terms of:
Calculating no of orders per product
Calculating no of orders completed per factory
Calculating no of factories per producer
Calculating no of completed orders per factory per producer
Calculating no of cash reserves per producer

Calculating average cash reserves for all customers
under given scenarios per cycle.
Each of these product features will be described in greater detail in the 3:System
Features.
2.3 User Classes and Characteristics
This project is to be used by two major user classes: Software Developer and Admin
Staff; and Client.
Software developer / IT Support - The group of people/person responsible for
developing the product whom work at the company. Those that work at the company
whom are responsible for uploading the data results, responding to clients emails and
other general I.T support or problems.
Frequency of Use
Software Developer: The most frequent user of the program due to the amount
of hours spent developing the program.
IT Support: Responsible for the maintaining communication between clients
and the company. The frequency of use delivered here is midway between the
client and developer.
Product Functions Used

Software Developer: The developer is responsible for testing and developing
all product functions. They need access to all components of the functions
used.
IT Support: Does not need as much access to the product functions as the
developer as they just need to be able to carry out administrative tasks on the
system.
Technical Expertise

Software Developer: The developer needed to have a high level of knowledge
in order to be able to deliver a working brief in an appropriate programming
language.
IT Support: No technical expertise is needed. basic admin skills email clients,
distributing data.
Education Level
Software Developer: Although there is no need for a certain level of education,
there is a need for a certain understanding of skills in programming to be able
to develop what is asked for. See Technical Expertise.
IT Support: The member of this team needs to be able to understand the
basics of reading data for statistical purposes in order to be able to resolve an
queries the client has with their results.
Privilege Level
Software Developer: There are no restrictions on the privilege level given to
the developer. This is because he is responsible for all actions carried out on
the system.
IT Support: Does not need full access as the developers do. Instead, they
Need access to the interface which acts as a buffer between client and
software developer.
2: Client User of the product

Frequency of Use - The client is the least frequent user of the program. This
is because they just need to post the brief, collect data and pay the company
for the project. They are not responsible for any maintenance work on the
system unlike the other user case, which takes a considerable amount of time.
Product Functions Used The client does not get to see that the developer
or IT Support sees. They view the product at an interface level, which is
made user friendly and easy for a non-technical person to understand.
The product functions they see are completely different and consist of: User
Interface: log in password protected, store data about project, message
facility, collect results.
Technical Expertise The client does not need to have any amount of
technical expertise in order to be able to use this program, however the client
needs to know how to use the Internet.
Education Level The client does not need to have a certain education. IT is
available to all users regardless of their level of education.
Privilege Level The restrictions on the privilege level given to the

Client restricts users to a User interface. Reasons for this are listed in
Frequency of Use (see above)
2.4 Operating Environment

This program has been devised by developers so that it can run on any platform and
version of platforms possible where an IDE is installed.
It has been tested on two of the three main operating systems Mac OS and
Windows.
There are no other requirements in terms of hard disk space needed or memory
required.
2.5 Design and Implementation Constraints
Anyone who wishes to partake in the development of the project needs to know and
understand the programming language used C++ and STL features; and have
access to the brief.
Users need to have a password in order to login to the system as all data is particular
to the user in question and protected.
Internet connection is need for clients to access the system.
2.6 User Documentation
Once the client has logged in and registered to use the service, the client will have
access to the User Documentation. It will be accessible to users via the following
ways:
-Instructions will be sent out via email.
-It can be viewed on the companys website
-It can be downloaded as a pdf file.
3. System Features
Customer Class
3.1 System Feature 1 WageIncrease
This function addresses the statements:
A consumer receives extra cash at the end of each cycle (salary)
What happens if the consumer wage remains constant and if it increases by a small
random
value (<5%) every 100 cycles.
3.1.1 Description
This function adds the customers wage every cycle. It also allows customers
wage to be updated every cycle by a random amount ranging from 0 to 5%
every 100 cycles
3.1.2 Stimulus/Response Sequence
Each time this function is called the customers wage increases by 150 units
(the constant amount).
The second condition involves altering the program to address the questions the client
wishes to model namely: What happens if the consumer wage remains constant and if it
increases by a small random value (<5%) every 100 cycles.
By setting up a counter inside of the function, we can add one each time to this until it
reaches 100 - the cycle amount desired before increasing by the random value. At this 100
mark, we can reset the counter to 0 and use the random generator to produce a new
random number between 0 and 5% each cycle, which can be used as the new wage value
for the customers.
3.1.3 Functional Requirements
No functional requirements needed by this function
3.2 System Feature - cashRunOut

This function addresses the statement:
A consumer can only order as many products as it has cash to pay for them
3.2.1 Description
10

This function displays a message if the customers cash is below or equal to
zero.
3.2.2 Stimulus/Response Sequence
The message displayed states:
This customer has run out of cash. Please wait until the next cycle to reorder
for each customer whom has zero cash, before carrying on.
3.3 System Feature - updateCus

3.3.1 Description
Calls and updates all of the functions under customer and is responsible for
placing orders for each customer.
3.3.2- Stimulus/Response Sequence

Calls the previous two functions wageIncrease and cashRunOut. When an
order is placed the price of the product is minus from the customers cash, if
the other customer has sufficient cash to do so.
Producer Class
3.4 System Feature - priceOfProduct
3.4.1 Description
11

3.5 System Feature - buildFactory
Each factory has a cost per cycle..as well as a one-off construction cost.
3.5.1 Description
Used to build factories for each producer
Create a condition that adds 1 to the number of factories built per producer if
the condition is fulfilled. The function also minuses the cost of construction
every time a factory is built
3.6 System Feature - outOfCash

If the producer runs out of cash, it cannot manufacture any more products and must be
declared bankrupt. At this point the simulation must end
3.5.1 Description
3.7 System Feature - placeOrder

3.7.1 Description
3.8 System Feature - updateAll
3.8.1 Description
12

Updates all the functions in the producer class.
Loops through all the factories calling functions which
1: Minus the cost for running the factory each cycle -50 units
2: calls the function for outOfCash
3: Calls the idle function which is set up as a counter in factory update.
4: calls the update function.
Product Class
3.9 System Feature - updateProd
3.9.1 Description
Updates the product cost by a small random value -5% every 10 cycles.
Like in function , we set s counter which when looped 10 cycles, resets
itself and uses the generate random number function to alter the cost by +/10 of the product price.
Factory Class
3.10 System Feature - update
3.10 Description
Responsible for ensuring the products are completed and added so that they
are available to order.
13

3.11 System Feature - putOrder

3.11.1 Description
Cycle Class
3.11 System Feature - newCycle
This function updates functions for product, customer and factory,
3.11.1 Description
Updates functions for product, customer and factory,
This function calls the update function for each of the classes product,
customer and producer inside each of the update function other functions
relative to the called function are called.
It has been designed this way to keep everything centralised,
3.12 System Feature - genRanInt

This function addresses issue of generating random values for certain features
3.12.1 Description
Used to generate random integer
Generates random integer which can be used in the functions: updateCus
and placeOrder.
14

3.13 System Feature - genRanNum

This function addresses issue of generating random values for certain features
3.13.1 Description
Used to generate random number
Generates a random number which can be used in the functions:
Customer constructor, WageIncrease, cycle1, producer and updateProd
function.
3.14 System Feature - cashCus

Average cash reserves for all the customers
3.14.1 Description
Calculates the cash average for all customers
.
Each of the values for customer are pushed back into a vector and then
added together using the std::accumulate function.
We then divide the figure by the total number of customers, to get each
cycles average.
3.15 System Feature - cycle1

This function is the constructor for the project.
3.15.1 Description
This is the constructor which deals with initialing default values for product,
producer and customer.
15

For each of these three main classes we are shown, the constructor is going
to be made up of a number of different parts.
The customer constructor will consist of: amount of cash per customer. The
producer constructor consists of: producer name, amount of cash per
producer, whilst the product constructor consist of product name, cost of each
product and length of time needed to construct each product.
By construct it this way it will remain easier to represent data for the vast
volumes of data of each class producer, product and factory, we have to
deal with.
User view of product use

The user screens that the user would finally be seeing could only be displayed at the end of the whole
project. Once the project is implemented the samples of data used and the dramatic sceneries can be
depicted.
4. External Interface Requirements

4.1 User interface-GUI
This is the login screen that the client will see at login.
16
When the User login in this is what they are presented with:
17
At the top of the page, is the name of the company: Modelling Constancy with a Welcome
message directly below with the customers name.
Brief: This shows the brief that has been submitted by the client.
Results: This section is for displaying the results gathered by the Company from the
instructions on the brief.
We offer specialist services for those interested in developing solutions to modelling

problems.
For further information please send an email us at : Bar
Buttons
Logout: When this button is selected, the user is able to logout of the system.
Messages: The client is able to send messages to the company about various matters
changes to the brief, payment, how long the process will take and so forth.
18

Payment: The User is able to use this facility to pay the company for providing this service
**Results will not be posted until payment is made.****
Upload Brief: The user is able to upload the brief here from their laptop or so forth. Word
and PDF files and various text files are the only accepted format
User Login: (Client Side): The user has to enter a username and password in order to gain
access to system.
User Login: (Developer Side/ IT support Side): This User Case has a different login screen
to the Client Side. The User case is able to have access to the software. This makes it
easier to manage in terms of database storage.
Both user cases require a user name and password.
User Account: This enables the user to view the account status of their account
4.2 Hardware Interfaces
N/A
4.3 Software Interfaces

This program is compatible with every system which holds an integrated
development environment (IDE). It can be installed and runs on any operating
system - GNU/Linux, Microsoft Windows and Mac OS X distributions and thus it is
independent from the operating system of the computer system on which it runs and
version of the operating system.
It has been tested on various versions of Microsoft Windows XP, 7; and Mac OS X
Lion.
4.4 Communications Interfaces
Network communication is not needed to run this program to run as the calculations
are carried out on a computer. and not an internet platform.
Software Requirements Specification for PDF Split and Merge
19
5. Other Nonfunctional Requirements

5.1 Performance Requirements
5.2 Safety Requirements

The application must ensure that it leaves untouched the input pdf files. No
modification is allowed
to these files.
Moreover, the application should function even in cases of wrong data insertion or
wrong settings.
In case of error it should provide users with appropriate help messages.
5.3 Security Requirements
5.4 Software Quality Attributes
5.5 Other Requirements GNU GPL License
20
Assumptions
Assumptions
Constraints, Assumptions and Dependencies
cash of each customer and each producer.
Efficiency Value
How is the efficiency value increase and decrease triggered?
How much of an increase and decrease are we looking at?
Does it remain the same, throughout a cycle or does it resort to original values of %
per production?
Pricing Threshold
How do we decide (based on price) the guidelines for consumers purchasing
products- where is the threshold?
Orders Threshold
How do we decide what the threshold is for the number of orders placed per factory?
Product Cost
Should we take into consideration:
manufacturing costs and length of time to manufacture each product.
Factories Threshold
At what point do we start building more factories as we have to consider the amount
of money in the budget as we dont want to be left with no cash.
21
Diagrams
Producer
IDLE_CYCLES : enum = 10
UNUSED_CYCLES : enum = 5
std::string name_;
cash_ : double
margin_ : std::vector<double>
factories_ : std::vector<factory>
*cycle1_ : cycle1
maxNumberOfOrders_ : unsigned int
destoryFactory_ : unsigned int
orderThreshold_ : unsigned int
orders_ : std::list<order>
completeOrders_ : std::list<order>
waitingOrders_ : std::list<order>
idlefactory_ : unsigned int
factoryBuilt_ : unsigned int
maxFactoryPerCycle_ : unsigned int
producer(const std::string &name, double cash, cycle1
*cycle1)
updateAll()
buildFactory()
getNumFacOwn()
setName(const std::string &name)
printPd()
priceOfProduct(int product) const
placeOrder(int product)
outOfCash()
Order
cyclesLeft : double
product : int
order(int prd, double total)
Customer
cash_: double
salary_: double
isSalaryConstant_ : bool
countCycles_ : int
*cycle1_ : cycle1
name_:std::string
customer(cycle* cycle, double salary,bool isSalaryConstant)
cash()
updateCus()
wageIncrease()
cashRunOut()
Cycle
NUMBER_OF_CYC : enum = 10
producers_ : std::vector<producer>
customers_ : std::vector<customer>
products_ : std::vector<product>
cycle1()
run()
newcycle()
genRanNum(double fMin, double
fMax)
genRanInt(int iMin, int iMax)
list<double> &::cashCus()
std::list<double> cusCash_
Product
COST_CHANGE_CYCLES : enum = 10
name_ : std::string
cost_ : double
cycles1_ : double
lastChanged_ : unsigned int
product(const std::string name, double cost, double cycles1);
updateProd();
string name();
cost();
cycles();
print ();
22
Factory
currentOrder_ : order
ordersCompeted_ : unsigned int
currentRunningCost_ : double
idleCost_ : double
idle_ : double
capacityLeft_ : double
currentProduct_ : int
*producer_ : producer
efficiency_ : double
constructionCost_ : double
runningCost_ : double
idlefactoryCost_ : double
factory(producer *producer)
constructionCost()
runningCost()
idlefactoryCost()
update()
Diagrams
00
23
Diagrams
Order _1: Order

product : 2
cyclesLeft : 3.00
Product 2 :Product
COST_CHANGE_CYCLES : 10
lastChanged_ : 2
orders name_ : " Product 2"
cost_ : 5.00
cycles1_ : 2.00
from
factory 1:Factory
ordersCompeted_ : 0
currentRunningCost_ : 50
idleCost_ : 15.00
idle_ : 2
capacityLeft_ : 1 .00
currentOrder: 2, 3.00
*producer_ : "producer A"
efficiency_ : 1.00
constructionCost_ : 1500.0
runningCost_ : 50.0
idlefactoryCost_ : 15.0
24
Diagrams
Order _5: Order

product : 4 cyclesLeft : 3.00
Product4 :Product
COST_CHANGE_CYCLES : 10
lastChanged_ : 2
name_ : " Product 4"
cost_ : 7.00
cycles1_ : 4.00
factory 1:Factory
ordersCompeted_ : 4
currentRunningCost_ : 50
idleCost_ : 15.00
idle_ : 2
capacityLeft_ : 1 .00
currentOrder: 4, 4.00
*producer_ : "producer A"
efficiency_ : 1.00
constructionCost_ : 1500.0
runningCost_ : 50.0
idlefactoryCost_ : 15.0
25
Diagrams
26
SSD- Software Design Document
SDDocument
Software Design Description

Version <number>
<date>
<Project Title>
<Author>
27
CONTENTS
PAGE
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii
1 Introduction
1.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 System Design
2.1 Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Design Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 System Architecture
3.1 Architecture Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 CakePHP Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Use Case Realizations
6.0
6.0
7.0
Real-Time Design
User Interface Design
Help System Design
Note:
For the remaining sections of this document, it is conceivable (and perhaps even
desirable) that one or more of the section topics are discussed in a separate design
document within the project. For each section where such a document exists, a reference
to the appropriate design document is all that is necessary. All such external (or
28

fragmented) design documents should probably be provided with this document at any
design reviews.
29
1 System Overview
1.1 Purpose
The purpose of this document is to provide us with the design details of the Economic
Modelling of Supply Chain Logistics Project described in the Software Requirement
Specification Document.
The expected audience are: developers whom will update or alter this program,
economists or business heads who are interested in using this to forecast budgeting and
business expansion and anyone whom is interested in doing any type of research into
financial modelling within supply chain sector.
1.2 Scope
< State the dominant design methodology. Overview the architecture of the product
briefly. Describe the external systems with which this system must interface. >
1.3 Glossary
EMSCLP - Economic Modelling of Supply Chain Logistics Project
SRS - Software Requirement Specification Document
1.4. References
Appleton, B, D (1997) A Software Design Specification Template.URL:

http://csis.pace.edu/~marchese/cs615sp/WebDocs/soft-des-spec-tmp.htm [15 May
2012]
< List here any references to other documents cited anywhere in this document including
references to related project documents, especially the SRS. Add references here when
other project documents are created. This is usually the only Bibliography in the document.
>
1.5. Overview of Document
The remaining part of this document, will be divided between 6 chapters, which
each concentrate on a particular aspect of the design process. These being: the
30

deployment -, architectural, data structure, real-time, user interface and help system
design. and will also include a Use Case Realizations section < Describe the contents and
organization of the rest of this document. Since there is already a Table of Contents, this
overview will be less formal but more informative. Describe the remaining sections. >
2.
Design Method
The design methodology chosen here is Object orientated Methodology.

Its easier to produce and understand designs.
The objects in the system are immune to requirement changes because of data hiding.
Reduces the development cost & time and increases quality.
< The deployment diagram provides a physical look at the system with each processor and
device indicated. This provides a background for the rest of the document as no software
component can straddle two physical locations. Each physical location will have its own
software unit and units in different physical locations will collaborate to provide the services
that logically seem to be straddling the units. >
3.0. Architectural Design

In doer to fulfil the requirements specified in the SRS, I have decided to implement a client
server model. It will take the form of client: user server: company.
Interaction
Protocol
Server
Client
31
< A software system is a set of communicating entities that collaborate to perform a task.
The Architectural Design shows these entities, their relationships and the relationship to
the actors in the system. This top level is a diagram where each entity has a name, a
(proto-) type, an abstract specification and an interface design. The abstract specification
is a description of its purpose, its functionality, its attributes (including dependency on other
entities) and the constraints under which it must operate. It also describes resources, that
is, any elements used by the entity which are external to the design such as physical
devices (e.g., printers), software services (e.g., math libraries) and processing resources
(e.g., buffers). The interface design is the list of the services that it provides to clients.
32

These services are methods (procedures and functions), each carefully documented using
a pre-condition/post-condition formalism.
Each entity in turn may provide its services by having an internal architectural design with
its own set of subordinate entities. These entities may be called sub-systems, components,
modules or classes. The decomposition of a higher-level entity into subordinate entities
must be explicit. The algorithm that shows how each method of the larger entity is
performed by these components must be explicit. Any data stored in an entity must be
explicitly described (see Data Structure Design below).
Note that while the abstract specification (architecture) and the interface (detailed) design
are usually developed separately in an iterative approach, they are combined for
documentation. >
4.0. Data Structure Design

< If not already covered above, design in detail and specify the data structures to be used
in the implementation. If these include databases, define the table structure of all
databases including full field descriptions and all relations. Graphical languages are
appropriate. Note that a database is an object and may have been fully described in the
previous section. If the material is covered under Architectural Design, this section is
omitted. >
5.0 Use Case Realizations

< For each use case in the Requirements Specification there must be a use case
realization here. That is, there must be a sequence of events using the design objects that
will perform all of the operations promised in the SRS. It is possible that there will be
several use case realizations here to show all the alternative and exception paths required.
The relationship between use case specifications (full descriptions in the SRS) and use
case realizations must be bi-directional (referenced from SRS to here and from here to
SRS) and explicit. Each use case realization must also be cross-referenced to the use
case test in the test design. This relationship between use case specifications and use
case test must be bi-directional and explicit. >
6.0. Real-Time Design

33

< If relevant, tell how your design that will ensure that the real-time timing constraints will
be met. If not relevant, omit this section. >
6.0 User Interface Design

< Refer to User Interface material in the SRS and supplement with any design
considerations not mentioned there. You should discuss the expected effectiveness of your
design. >
7.0 Help System Design

< Describe the structure of the help system and how it is to be accessed. Will it be context
sensitive? Will there be a system reference capability? >
Index
< generate here >
34
Test Plan
Test Plan
I have designed tests for each of the main five classes: cycle1, factory, customer,
producer and product. Each of these tests will ensure the validity of each of the
functions.
I will list the type of tests I will carry out for each function.
If statement, condition is a value or an expression that is used to determine which code
block is executed
Explain in detail what needs to be tested and how you will implement the tests. Ensure you
have adequately considered lower level unit/integration testing, and explain your choice of
test values.
Cycle1
cashCus()
Check that each customer is being push_back and the total amount of
customers
push_back.
Total amount of customers
Calculation for mean.
Factory
update() the no of cycles left to be completed of the current order
For each product, there are a number of cycles need to be carried out in order for the
product to be completed.
Based on the if condition - (currentOrder_.cyclesLeft <= 0.0) , if the number of cycles
left to be completed of the currentOrders cycle turns out to be greater than 0.0 then:
The idleCost becomes equal to the currentRunningCost_
1 is added to the idle_ variable.
For the second if condition - (capacityLeft_ < currentOrder_.cyclesLeft), if the
capacity left to be completed is greater than the number of cycles left to complete the
currentOrders cycle.
35
Test Plan
capacityLeft is subtract from currentOrder_.cyclesLeft resulting in
currentOrder_.cyclesLeft having less to complete hence freeing up the
capacityLeft becomes equal to zero.
For the other half of the if statement - the else condition, if the capacity left to be
completed is not greater than the number of cycles left to complete the currentOrders
cycle.
1 is added to the number of ordersCompeted variable
currentOrder_.cyclesLeft becomes equal to zero.
currentOrder_.cyclesLeft is subtracted from capacityLeft resulting in
capacityLeft
putOrder()
(currentOrder_.cyclesLeft <= 0.0) {
currentOrder_ = order;
if (capacityLeft_ >= currentOrder_.cyclesLeft)
{
capacityLeft_ -= currentOrder_.cyclesLeft;
currentOrder_.cyclesLeft = 0.0;
}
Producer
buildFactory()
Check that if statement is working
outOfCash()
Check that if condition is working by seeing
If cash is less then 0, does the program exit and print out the statement : "has
run out of cash. The simulation has ended"
If cash is greater than 0, the program carries on.
placeOrder()
Check that if statement is working
updateAll ()
36
Test Plan
Check that if statement is

working
Product
updateProd()
Check that if statement is working properly.
Customer()
wageIncrease()
cashRunOut()
Check that if condition is working by testing:
If cash is less then or equal to 0, does the program print out the statement: "
This customer has run out of cash. Please wait until the next cycle to reorder ".
If cash is greater than 0, the program carries on without printing out a
statement.
updateCus()
Results
Cycle1 - cashCus()
Condition
Expected
output
37
Actual
Outpu
t
Reasonfordifference
Test Plan
Check that each customer is
being push_back.
Calculation for mean.
push_back.
Condition
Expected
output
The idleCost becomes equal to

the currentRunningCost_
If 1 is added to the idle_
variable.
capacityLeft is subtract from
currentOrder_.cyclesLeft
resulting in
having less to complete
capacityLeft becomes equal to
zero.
1 is added to the number of
ordersCompeted variable
becomes equal to zero.
currentOrder_.cyclesLeft is
subtracted from capacityLeft
38
Actual
Output
Reasonfor
difference
Test Plan
resulting in capacityLeft
Factoryupdate()
putOrder()
Condition
Expected
output
Actual
Outpu
t
Expected
output
Actual
Outpu
t
Reasonfordifference
Producer - buildFactory()
Condition
39
Reasonfordifference
Test Plan
Producer - outOfCash()
Condition
Expected
output
Actual
Outpu
t
Expected
output
Actual
Outpu
t
Reasonfordifference
If cash is less then 0, does

the program exit and print out
the statement : "has run out
of cash. The simulation has
ended"
If cash is greater than 0, the
program carries on.
placeOrder()
Condition
updateProd()
40
Reasonfordifference
Test Plan
Condition
Expected
output
Actual
Outpu
t
Expected
output
Actual
Outpu
t
Reasonfordifference
updateAll ()
Condition
Customer -wageIncrease()
41
Reasonfordifference
Test Plan
Condition
Expected
output
Actual
Outpu
t
Expected
output
Actual
Outpu
t
Reasonfordifference
updateCus()
Condition
cashRunOut()
42
Reasonfordifference
Test Plan
Condition
Expected
output
If cash is less then or equal to

0, does the program print out
the statement: " This
customer has run out of cash.
Please wait until the next
cycle to reorder ".
If cash is greater than 0, the
program carries on without
printing out a statement.
43
Actual
Outpu
t
Reasonfordifference

URD

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

URD

Загружено:

Авторское право:

Доступные форматы

User Requirements Document

User Requirements Document

User Requirements Document

4. External Interface Requirements

User Requirements Document

User Requirements Document

1.4 Syste Overview

User Requirements Document

User Requirements Document

Product Functions Used

User Requirements Document

2: Client User of the product

User Requirements Document

Privilege Level The restrictions on the privilege level given to the

2.4 Operating Environment

User Requirements Document

3.2 System Feature - cashRunOut

User Requirements Document

3.3 System Feature - updateCus

3.3.2- Stimulus/Response Sequence

User Requirements Document

3.6 System Feature - outOfCash

3.7 System Feature - placeOrder

User Requirements Document

User Requirements Document

3.11 System Feature - putOrder

3.12 System Feature - genRanInt

User Requirements Document

3.13 System Feature - genRanNum

3.14 System Feature - cashCus

3.15 System Feature - cycle1

User Requirements Document

User view of product use

4. External Interface Requirements

User Requirements Document

User Requirements Document

We offer specialist services for those interested in developing solutions to modelling

User Requirements Document

4.3 Software Interfaces

User Requirements Document

5. Other Nonfunctional Requirements

5.2 Safety Requirements

5.3 Security Requirements

5.4 Software Quality Attributes

5.5 Other Requirements GNU GPL License

Order _1: Order

Order _5: Order

SSD- Software Design Document

Software Design Description

SSD- Software Design Document

SSD- Software Design Document

SSD- Software Design Document

Appleton, B, D (1997) A Software Design Specification Template.URL:

SSD- Software Design Document

The design methodology chosen here is Object orientated Methodology.

3.0. Architectural Design

SSD- Software Design Document

SSD- Software Design Document

4.0. Data Structure Design

5.0 Use Case Realizations

6.0. Real-Time Design

SSD- Software Design Document

6.0 User Interface Design

7.0 Help System Design