Table of Contents

Our Credo ............................................................................................................................ iii

Letter of Transmittal ............................................................................................................ iv
Acknowledgement ................................................................................................................ v

1.0 Introduction ..................................................................................................................... 7

1.1 Purpose ........................................................................................................................ 7
1.2 Scope ........................................................................................................................... 7
1.3 Features ....................................................................................................................... 7
2.0 Inception ......................................................................................................................... 8
2.1 Stakeholders ................................................................................................................ 8
2.2 Stakeholders View Point: What They Want ................................................................. 9
2.3 Working towards Collaboration ................................................................................. 10
2.4 Common Requirements.............................................................................................. 10
2.5 Conflicting Requirements .......................................................................................... 10
2.6 Final Requirements .................................................................................................... 10
2.7 Questioners ................................................................................................................ 10
2.8 Group Meeting........................................................................................................... 12
3.0 Elicitation ...................................................................................................................... 13
3.1 Collaborative Requirements Gathering....................................................................... 13
3.2 Quality Function Deployment .................................................................................... 13
3.3 Usage Scenarios ......................................................................................................... 15
3.4 Elicitation work product............................................................................................. 15
4.0 Product Perspective ....................................................................................................... 16
5.0 Product Description ....................................................................................................... 16
5.1 Product Functionality ................................................................................................. 16
5.2 Users and Characteristics ........................................................................................... 16
5.3 Operating Environment .............................................................................................. 16
5.4 Design and Implementation Constraints ..................................................................... 17
6.0 Software Requirement Models ...................................................................................... 18
6.1 Scenario Based Model ............................................................................................... 18
6.1.1 Use Case ............................................................................................................. 19

Page | 1

6.1.2 Use Case Diagram ............................................................................................... 22

6.1.3 Activity Diagram ................................................................................................. 29
6.1.4

Swim lane Diagram........................................................................................ 35

6.2 Data Modeling ........................................................................................................... 38

6.3 Class Based Model .................................................................................................... 40
6.3.1 Identifying Analysis Class ................................................................................... 40
6.3.2 Specifying Attributes and Defining operations ..................................................... 42
6.3.3 CRC Model ......................................................................................................... 46
6.4 Flow Oriented Model ................................................................................................. 47
6.5 Behavioral Model ...................................................................................................... 52
6.5.1 State Transition Model ........................................................................................ 52
6.5.2 Sequence Model .................................................................................................. 55
7.0 System Design............................................................................................................... 56
7.1 Logical design ........................................................................................................... 56
7.2 Physical design .......................................................................................................... 56
8.0 System Requirements .................................................................................................... 58
8.1 Recommended Software Requirements ...................................................................... 58
8.2 Hardware Requirements ............................................................................................. 58
8.3 Software Requirements .............................................................................................. 59
8.4 Other Requirements ................................................................................................... 59
9.0 User Interface ................................................................................................................ 60
9.1 Home Page ................................................................................................................ 60
9.2 Admin Home Page ..................................................................................................... 61
10.0 Implementation & Testing ........................................................................................... 62
10.1 Implementation ........................................................................................................ 62
10.2 The Technology ....................................................................................................... 62
10.3 Web user Interface ................................................................................................... 62
10.3.1 ASP .NET MVC 4 Framework .......................................................................... 62
10.3.2 Cascading Style Sheet (CSS) ............................................................................. 62
10.3.3 Hyper Text Mark up Language (HTML)............................................................ 62
10.3.4 JavaScript .......................................................................................................... 62
10.3.5 JQuery............................................................................................................... 63
10.4 Internet Information Service (IIS) ............................................................................ 63

Page | 2

10.5 Implementation Tools .............................................................................................. 63

10.6 Microsoft Visual Studio 2012 .................................................................................. 63
10.7 SQL Server 2008 ..................................................................................................... 64
10.8 Testing ..................................................................................................................... 64
11.0 Implementation & Testing ........................................................................................... 65
11.1 Target User .............................................................................................................. 65
11.2 Design Concepts ...................................................................................................... 65
11.3 Home Panel ............................................................................................................. 65
11.4 Login Panel.............................................................................................................. 66
11.5 Register Panel .......................................................................................................... 67
11.6 User Home Panel ..................................................................................................... 68
11.7 Admin Panel ............................................................................................................ 69
11.8 Manage PO Panel .................................................................................................... 69
11.9 PO Submission Panel ............................................................................................... 70
11.10 Insert buyer Information panel ............................................................................... 71
12.0 Conclusion .................................................................................................................. 71

Page | 3

Figures
3.1: Phases of Requirements ................................................................................................ 14
6.1: Use Case Scenarios ...................................................................................................... 19
6.2: Authentication Use Case Scenarios Properties .............................................................. 19
6.3: Insert Project Use Case Scenarios Properties ................................................................ 20
6.4: Scheduling & Re-Scheduling Use Case Scenarios Properties ........................................ 20
6.5: Supplier Selection Use Case Scenarios Properties ........................................................ 20
6.6: Sample Approval Use Case Scenarios Properties .......................................................... 21
6.7: Notice Generation Use Case Scenarios Properties ........................................................ 21
6.8: Level 0 Use Case Diagram ........................................................................................... 22
6.9: Authentication Use Case Diagram ................................................................................ 23
6.10: Insert Project Use Case Diagram ................................................................................ 24
6.11: Scheduling & Re-Scheduling Use Case Diagram ........................................................ 25
6.12: Supplier Selection Use Case Diagram ......................................................................... 26
6.13: Sample Approval Use Case Diagram .......................................................................... 27
6.14: Notice Generation Use Case Diagram ......................................................................... 28
6.15: Authentication Activity Diagram ................................................................................ 29
6.16: Insert Po Activity Diagram ......................................................................................... 30
6.17: Scheduling and Re-scheduling Activity Diagram ........................................................ 31
6.18: Supplier Selection Activity Diagram .......................................................................... 32
6.19: Sample Approval Activity Diagram ............................................................................ 33
6.20: Notice Generation Activity Diagram .......................................................................... 34
6.21: Insert Project Swim Lane Diagram ............................................................................. 35
6.22: Sample Approval Swim Lane Diagram ....................................................................... 36
6.23: Scheduling & Re-Scheduling Swim Lane Diagram..................................................... 37
6.24: Database Schema ....................................................................................................... 38
6.25: E-R Diagram .............................................................................................................. 39
6.26: Class Approval Diagram ............................................................................................ 41
6.27: User Class Card .......................................................................................................... 42
6.28: Buyer Class Card........................................................................................................ 42
6.29: Authentication Class Card .......................................................................................... 43
6.30: PO Class Card ............................................................................................................ 43

Page | 4

6.31: Time Class Card ......................................................................................................... 43

6.32: Supplier Class Card .................................................................................................... 44
6.33: Database Class Card ................................................................................................... 44
6.34: System Class Card ...................................................................................................... 44
6.35: Interface Class Card ................................................................................................... 45
6.36: CRC Model Diagram.................................................................................................. 46
6.37: Context Level DFD Diagram ...................................................................................... 47
6.38: Level 0 DFD Diagram ................................................................................................ 47
6.39: Level 1 DFD Diagram (Insert Project) ........................................................................ 48
6.40: Level 1 DFD Diagram (Supplier Selection) ................................................................ 48
6.41: Level 1 DFD Diagram (Sample Approval) ................................................................. 49
6.42: Level 1 DFD Diagram (Notice Generation) ................................................................ 50
6.43: Level 1 DFD Diagram (Scheduling & Re-Scheduling) ............................................... 51
6.44: Authentication State Diagram ..................................................................................... 52
6.45: Insert Project State Diagram ....................................................................................... 53
6.46: Scheduling & Re-Scheduling State Diagram............................................................... 54
6.47: Supplier Selection Sequence Diagram ........................................................................ 55
6.48: Sample Approval Sequence Diagram.......................................................................... 55
7.1: Physical process of Notice Generation .......................................................................... 57
9.1: User Interface Home .................................................................................................... 60
9.2: Admin User Interface ................................................................................................... 61
11.1: Home panel ................................................................................................................ 65
11.2: Login panel ................................................................................................................ 66
11.3: Register Panel ............................................................................................................ 67
11.4: User Home panel ........................................................................................................ 68
11.5: PO Details Panel ........................................................................................................ 69
11.6: Insert PO Panel........................................................................................................... 70
11.7: Create Buyer Panel ..................................................................................................... 71

Page | 5

Executive Summary
Merchandising Management System is a web application where some information about
buyer, supplier, garments production and some notifications system is enclosed in a single
process. It handles some of features which is written belowFirstly merchandiser contacts with the buyer and settle down a deal on a right cost and right
time based on the capability of production unit. On that deal the merchandiser must have
emphasize on the time and the cost. After the deal is done then the buyer will send a PO
(Product Order) sheet to the merchandiser along with a file of required details which will be
needed for the production. If the deal is canceled then the total process is stopped. That is a
subsystem of the main merchandiser system named as Insert a PO.
Secondly, on dealing with supplier scenario the merchandiser will select which supplier will
be most favorable to deal with considering the previous state records. After selection the time
and cost budget must be fixed. If the time and cost budget isnt favorable then supplier must
be changed. If the budget deal is done then quality of the product must be seen and if quality
isnt right then upgrade the existed quality. When all of them are done then booking will be
given and a delivering date will be recorded in which all of the good will be delivered under
right condition. That system will be dealt on Mange the PO.
Thirdly, samples of all required materials must be collected before or after dealing with the
supplier and the materials must be send for approval from the buyer. If the samples arent
correct then send again and again till approved. After approving individual elements pre
production element on garments are prepared and send for approval. If approved than the
approved date must be left and go to the full production. That system is called the Approve
on the system.
Next is the dealing with supplier process. If approved, then the supplier will send the total
shipments to the factory with the command of the merchandiser. After receiving the product
the item will be in-house. That is called the In-house subsystem.

Page | 6

1.0 Introduction
1.1 Purpose
The main objective of this document is to illustrate the requirements of the project
merchandising system. T he document gives the detailed descript ion of the
both funct ional and non-funct ional requirements. The document is
developed after a number of consultations with the client and considering the
complete requirement specifications of the given Project. The final product of the
team will be meeting the requirements of this document.
The SRS typically contains the brief description of the project. The purpose of the
requirement document is to specify all the information required to design, develop
and test the software.
The purpose of this project is to provide a friendly environment to maintain the details

of orders and the merchandisers.

The main purpose of this project is to maintain easy alarming and notification system
using computers and to provide different log reports.

1.2 Scope
The project scope is the definition of what the project is supposed to accomplish and
the budget of both time and money that has been created to achieve these objectives.
We cant provide PC in the garments.
We cant provide internet.
Cant provide network connection.
Cant provide manpower.
We cant provide warranty service more than six months.

1.3 Features
Our project will provide the following features Authentication system
Creating and searching project orders in the system
Merchandiser can update info of categories
Each category will have a record which will be enclosed with it
Admin can verify the valid user to permit for creating orders or PO
Admin will give the time budget and create a good time schedule
If time is running out then show messages and give notifications
Also have the re-scheduling facility
Finally maintain and generate a log table.

Page | 7

2.0 Inception
In software industry requirement engineering is one of the most important parts of
software engineering process. Which one gives us the proper scenarios what the
customer wants, analyzing needs and feasibility, negotiating a reasonable solution etc.
Inception is the initial step of requirement engineering which make us understand how
does a software project get started? .In software industries, a software project begins
when a business need is identified. So the first step is we need to understand the
customer needs. Figure out a rough feasibility analysis, not only the customers need but
also with the people who are apparently involved with the introducing system. This stage
is called inception. Inception involves the following phases:
Identifying Stakeholders
Recognizing multiple viewpoints
Working towards collaboration
Asking the First Questions

The phase ends with identifying credibility and go/no go decision. Though we did
not have any interaction with the stakeholders, especially with the client Total
Solutions Enterprise, this paper is more on assumption. This paper will be more
easeful after communicating with our client. In this paper we will focus on
Accounting and Inventory management module. Again, this paper is a partial
submission; more details will be included as per communicating with all of the
stakeholders.

2.1 Stakeholders
The stakeholders of a software project are those people or positions, who are
directly or indirectly affected or effected by the project. The stakeholders and
users who are most immediately involved in a Garments Merchandising System
implementation can be divided into four groups.
Garments Authority: Garments authority is a major stakeholder of our
because they operate and maintain a whole garments.

software

Admin: Admin has the adminstrative power to handle the software.So he is also our
stakeholder.
Merchandisers: Merchandisers will directly interact with this software. So they are
also a major stakeholder of our system.
Others Department: Other departments are also stakeholders because they will use
the information if that system to analyze their production profit and others.

Page | 8

2.2 Stakeholders View Point: What They Want

Different stakeholders achieve different benefits. Consequently, each of them has a
different view of the system. So we have to recognize the requirements from multiple
points of view. Our assumption is given below:
Garments Authority view points: Garments Authority beholds the people who are
concerned with garments management. These people are merchandiser, operator and
other employees. Though these people are more of passive actors, we treated them as
important stakeholders because they will judge the credibility of the product and will
make go/no-go decision. Their view points may be the following

User friendly and efficient system

Minimum maintenance cost
Easy to operate
Guidelines for operators
Automated alarm system and log generation

Admin view points:

Maintain a system of all PO that has been ordered by buyer
Secured System
Easy to operate
The application is not needed to be installed in many computers.
Strong Authentication system
Merchandisers view points: Merchandisers behold the people who are concerned
with garments and buyer. These people are employees, buyer, and other employees
who are interacted directly or indirectly with the garments management.
Easy to use.
User friendly and efficient systems
Automated alarm system
Easy authentication system

Page | 9

2.3 Working towards Collaboration

Every stakeholder has their own requirement. In this step, we merged these
requirements. We followed following steps to complete the task:
Identify the common and conflicting requirements
Categorize the requirements
Take priority points for each requirements from stakeholders and on the basis of
this voting prioritize the requirements
Make final decision about the requirements.

2.4 Common Requirements

User friendly and efficient system
Easy to operate
The application can be accessed from any computer that has Internet access

2.5 Conflicting Requirements

Minimum maintenance cost

Availavility of all requriments within the budget
Easy access
Restrict access to functionality of the system based upon user roles
No ambiguous requirement

We finalized following requirements for the system by categorizing and priorotizing

the requirements.

2.6 Final Requirements

User friendly and efficient system

Easy to operate
The application can be accessed from any computer that has Internet access
Secured System
Restrict access to functionality of the system based upon user roles
No disruption of rules and regulation
Allows valid users to renew items online by logging into the system
Automatic generate reports on the items in the system
Availavility of all requriments within the budget

2.7 Questioners
We set our first set of context-free questions focuses on the customer and other
stakeholders, overall project goals and benefits. The questions are mentioned above.
These questions helped us to identify all stakeholders, measurable benefit of the
successful implementation and possible alternatives to custom software development.
Next set of question helped us to gain a better understanding of problem and allows
the customer to voice his or her perception about the solution. The final set of
question focused on the effectiveness of the communication activity itself. We can
follow the following steps to prepare a questioner.

Page | 10

Step 1: Confirm actors and goals.

Have all actors and their goals been identified?
Which actors can be generalized (combined)?
Which goals are potential use cases?

Step 2: Develop an outline of the use case(s).

For the goals identified as potential use cases, what are the key pieces?
For each outline level, what are key data?
Outline all use cases.
Prioritize the use-case flows.
Decide on a final use-case list (for initial pass).

Step 3: Write a brief description of the use case(s).

What two or three sentences describe all actors and the basic flow?
Generate content first, and worry about words meeting later.

Step 4: Detail the basic flow.

What event starts the use case?
How does the use case end?
How does the use case repeat some behavior?
What is the "happy" (best case) path?
There is one and only one basic flow.

Step 5: Detail the alternate flows.

Are there optional situations for the use case?
What might go wrong?
What might not happen?
Which resources might be blocked?
Which alternate flows are special -- perhaps nonfunctional -- requirements
(i.e., they apply to this use case only)?

Step 6: Review the use case(s).

Are there more use cases?
Should some use cases be redefined?
Which ones can be combined?

Step 7: Record pre- and post-conditions.

What was the previous state before this use case comes into play?
What happens once the use case is complete?

Step 8: Develop generalizations for all use cases.

Determine shared content and process for the use cases.
What items have been noted for the glossary or as global business rules?
Who has the most recent and accurate source document?
Where is it located?

Page | 11

2.8 Group Meeting

Date: 09.02.2013
Place: Versatile Garments
Subject: Discussion on introductory requirements and garments
merchandising process and management.
Members:
Dr. Mohammad Shoyaib

Associate Professor

Md. AsifImtiaz

BIT-0309

Upal Roy

BIT-0320

Sujit Ghosh

BIT-0329

Date: 23.02.2013
Place: Versatile Garments
Subject: Discussion on total requirements
Members:
Md. Asif Imtiaz

BIT-0309

Upal Roy

BIT-0320

Sujit Ghosh

BIT-0329

Mr. Arif

Merchandiser at Versatile

Md. Abadat Hossain

Merchandiser at Versatile

Page | 12

3.0 Elicitation
Elicitation refers on what process we should keep focus. To do a great an elicitation
for a SRS we need to conduct an error free focusing use case from different
viewpoints. In this process we need to think on what is basic unit of this project, what
is domain that we work for, for whom we make the software, who is going to be
benefitted by this system and a lot of correlated functions.
After ice breaking, in elicitation we need to understand the users need. We should
have to a make choice on that concern by which the Software can be much more
sophisticated. We should rapidly decrease the complexity in case of using the product
but have to convey our attention on how we develop this.
To elicit the total process anyone must need to gather information. To gather this
info we hold some meetings, did some team work, understood what requirements we
need.
Here is the info we got from some meetings-

3.1 Collaborative Requirements Gathering

We have been proposed in many different approaches to gather collaborative
requirements. They make use of various slightly different scenarios .We completed
following steps to do it.
Meeting with MD of Versatile Garments to understand the recent process
Meeting with the Merchandisers people to understand what is the task they
perform.

3.2 Quality Function Deployment

If we want to provide much attention on product requirements analysis we need
conduct the QFD(Quality function deployment) in this respect.QFD provides
three basic form of requirements .The are-

Page | 13

Normal
Requirements

Expected
Requirements

Wow factors

Fig 3.1: Phases of Requirements

Normal Requirements:
Normal requirements consist of objectives and goals that are stated during the
meeting with the customers. Normal requirements of our project are

User friendly system

Decrease the complexity of exiting system
Error free activity
Proper use of recourses

Expected Requirements:
These requirements are implicit to the system and may be so fundamental that
the
customer does not explicitly state them .Their absence will be a cause for
dissatisfaction.

Well security
Make it error less
Decrease the human work
Make it automated

Exciting requirements:
These requirements are for features that go beyond the customer's expectations
prove to be very satisfying when present

and

Automated warning mail generation

Enrich the web site with style and others
If anyone forget password ,can get them back form SMS

Page | 14

3.3 Usage Scenarios

At first a user authenticate in our system by creating an account .If a user already has
an account then he/she will log in the system with his/her own password and
username .Then our system will show the notification and alerts about the projects
and orders that has been added to the system.

In case of Inserting an order or PO:

If a deal is done than a PO is received and under that PO a project is created.
Various kinds of inputs are given along with the pictures and the files.
The system also generates a form where the scheduling will be done and the
fields where the total process will be done for a single item.

In case of Scheduling:
If a project is created than the admin will give the input to schedule the time
for each item that has been selected for the garments.
If the time limit is reached to at end than the system will auto generate some
reports or alarm or notifications which will be posted into the wall of the
users.
If the time is crossed than the time must be re-scheduled which will increase
the time limit for the particular item.

3.4 Elicitation work product

The output of the elicitation task can vary depending on size of the system or
product to be built. Our elicitation work product includes:
A statement of our requirements for automated merchandising system.
A bounded statement of scope for our system.
A list of customer, user and other stakeholder who participated i n
requirements elicitation.
View on the set of usage scenarios.
Total description of the systems technical environment.

Page | 15

4.0 Product Perspective

There are no existing merchandising software exist for that company Versatile
Garments. The company cannot track records of every single projects or orders
whatever they got to work and dont have the ability to see the rapid growth of a
particular order. The merchandiser only got that access to the order. So to ease his job
and to make a schedule for his work and to make an automated system we are
working.
Because if the merchandiser cannot finish his job timely then the whole production
will be delayed and for that reason the consignment will be sent to the destination by
air which is very costly and a loss project. To avoid that loss the garments need a
automated system which will indicate when to do the right job and if he fails to do it
then a alarm massage will be shown on his wall.

5.0 Product Description

5.1 Product Functionality
The main functionalities of the circulation system are

Inserting/Searching projects
Alarming System
Record the events of each item
Scheduling time
Generate alarming message or notification
Re-Scheduling time if needed

Proper description of this function will be described later in this SRS document.

5.2 Users and Characteristics

Admin
Merchandisers

5.3 Operating Environment

The proposed system will be a web based system along with various facilities.
Garments website can be visited from anywhere. But anyone can download the pdf &
documents if and update status of items.

Page | 16

5.4 Design and Implementation Constraints

Software Language used The application can be developed using Java/php/ .NET or any other web
programming language.

Development Tools Some Development tools like CSS3 can be used to make it much more user
friendly.

Database SupportSQL can be used for database support.

According to the schedule, our team will hand-over the complete SRS of Versatile
Garments Merchandising System. At the same time, the team will also provide a user
manual if it is required. The team is also responsible to conduct training sessions for
the Administrative task, where they will provide tutorials, notes along with the hands
on training. They will give feedback to the coder and future developer. The team will
be ready for solving any type of mistakes if occurred in this SRS.

Page | 17

6.0 Software Requirement Models

6.1 Scenario Based Model
Firstly Merchandiser contacts with the buyer and settle down a deal on a right cost
and right time based on the capability of the production unit. On that deal the
merchandiser must have emphasized on the time and the cost. After the deal the deal
is done then the buyer will send the PO sheet to the merchandiser along with a file of
required details which will be needed for the production. If the deal is cancelled then
the total process is stopped.
On dealing with the supplier scenario firstly the merchandiser will select which
supplier will be most favorable to deal with considering the previous state records.
After selection the time and the cost budget must be fixed. If the time and the cost
budget arent favorable then the supplier must be changed. If the budget deal is done
then the quality of the product must be seen and if quality isnt right then upgrade the
existed quality. When all of them are done then booking will be given and a delivery
date will be recorded in which all of the goods will be delivered under right condition.
Sample of all required materials must be collected before o after dealing with supplier
and the materials must be sent for the approvals from the buyer. If the samples arent
correct then send again and again till the approval. After approving individual
elements a size set sample and a pre production samples are prepared and sent to
buyer. If approved then the approval date, time, approver contact info must be kept
and go to full production.
Then comes the in housing process. If the approve is done then the supplier will send
the total shipments of raw materials to the factory with the command of the
merchandiser. After receiving the products the item will be in housed.

Page | 18

6.1.1 Use Case

1. Authentication

4. Supplier
Selection

2. Insert Project
3. Scheduling &
Re-scheduling

5. Sample Approval
6. Notice Generate

Fig 6.1: Use Case Scenarios

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Authentication
1
User(Admin/Merchandiser)
N/A
User has to login to authenticate
himself/herself
Must be registered
Clicking the sign-in/sing-up button
Checking the validity of users.

Fig 6.2: Authentication Use Case Scenarios Properties

Page | 19

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Insert Project
2
User(Merchandiser)
Admin
Adding a new project in the system
The order must be confirmed & PO
must be received
Clicking insert button
Give the user the privilege to insert a
new project
Fig 6.3: Insert Project Use Case Scenarios Properties

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Scheduling & Re-scheduling

3
User(Admin)
Merchandiser
Budgeting the total time from order
to inhouse
User must be logged as admin
Pressing the scheduling or rescheduling button
Make a budget of the total time

Fig 6.4: Scheduling & Re-Scheduling Use Case Scenarios Properties

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Supplier Selection
4
User(Merchandiser)
Admin
Select a supplier for every single
raw-material
PO must be received
Changing the state of supplier in the
running project
Select the supplier

Fig 6.5: Supplier Selection Use Case Scenarios Properties

Page | 20

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:
Trigger:
Events:

Sample Approval
5
User(Merchandiser)
Admin
To approve the sample from buyer
The sample should be ready
Changing the state of approval in the
running project
Creating a sample from the Sample
Department and approve it from the
buyer

Fig 6.6: Sample Approval Use Case Scenarios Properties

Use case Name:

Use case No:
Primary Actor:
Secondary Actor:
Description:
Precondition:

Notice Generate
6
N/A
Admin/ Merchandiser
Generate notice from system and
show on users notice panel
Scheduling must be done by admin

Trigger:

Auto generated by the system

Events:

Show notice for every changing state

and coming task
Fig 6.7: Notice Generation Use Case Scenarios Properties

Page | 21

6.1.2 Use Case Diagram

Authentication

Insert Project
Scheduling &
Re-scheduling
Supplier Selection

Admin

Merchandiser

Sample Approval
Notice Generate

DB

Fig 6.8: Level 0 Use Case Diagram

Page | 22

Sign up

Verify

Sign in
Admin
Merchandiser

Retry

Sign out
Block

Fig 6.9: Authentication Use Case Diagram

Page | 23

Insert Details

File Upload

Adding
Category
Admin
Merchandiser

Removing
Category
Update DB

Fig 6.10: Insert Project Use Case Diagram

Page | 24

Back
Calculation
Generate Total
Time
Select Objective
Merchandiser
Admin

Adjust Time for

the Objective
Update DB

Fig 6.11: Scheduling & Re-Scheduling Use Case Diagram

Page | 25

Select Material

Select Supplier

Change
Supplier
Admin
Merchandiser

Book Supplier

Update DB

Fig 6.12: Supplier Selection Use Case Diagram

Page | 26

Select Materials

Create Sample

Send to Buyer
Admin
Merchandiser

Get the
Approval
Update DB

Fig 6.13: Sample Approval Use Case Diagram

Page | 27

Generate
Report from
Time Checker
Create Notice

Admin

Show it on
Notice Board
Update DB

Merchandiser

Fig 6.14: Notice Generation Use Case Diagram

Page | 28

6.1.3 Activity Diagram

User

Reset Password

Have
Account?

Yes

Try>3 ?

Sign Up

Yes
No

Give Input

No

Try=Try+1

No

Check
Confirmation Mail

Correct
Username/
Password

Yes

Logged in
System

Fig 6.15: Authentication Activity Diagram

Page | 29

Login as
Merchandiser

Insert Details

Upload Files
Add Required Items

Create
required item?

Yes

No

No

Return Required
List

Add required list Item

Exit

Delete required
Item?

Yes

Delete Required List

Item

Update DB

Fig 6.16: Insert Po Activity Diagram

Page | 30

User Logged as
Admin

Running system on an
Objective

No

Back calculation with

Production rate

Generate TotalNoTime
Time Limit
Exceed?

Select an Objective

Yes

Select expended time

Adjust Time for that

Objective

Change the
DB

Fig 6.17: Scheduling and Re-scheduling Activity Diagram

Page | 31

Select a Material

Select a Supplier

Cost?

Quantity?

Time?

Yes

Yes

Yes
No

No

Book the Supplier

No

Change the Supplier

Update DB with
Submission date

Fig 6.18: Supplier Selection Activity Diagram

Page | 32

Select Material

Create a sample

Send sample to Buyer

No

Approved?
Yes

Get the approved mail,

date and approver

Update DB

Fig 6.19: Sample Approval Activity Diagram

Page | 33

Select Material

State Checker

Time Checker

Generated Report of Checker

Reverse?

Done?

Alarm?

Critical?

Yes
No

Yes

No

Yes

No

Positive State

Negative State
No

Yes

Create A Notice

Post the Notice

Update Log Table in DB

Fig 6.20: Notice Generation Activity Diagram

Page | 34

6.1.4 Swim lane Diagram

User

System

Merchandiser

UI

Insert Details

File upload

Want
to
add?

Want to
remove?

Remain unchanged

Update Category

Update DB

Fig 6.21: Insert Project Swim Lane Diagram

Page | 35

System

User

UI

Merchandiser

Select a Merchandiser

Send it to buyer

Approve
or not?

Exit

No

Yes

Get the approved mail

Update DB

Fig 6.22: Sample Approval Swim Lane Diagram

Page | 36

User

System

Admin

UI

Back calculation

Generate total
time

Time
limit
exceed

Select objective

Select extended
time

Update DB

Adjust time for

the objective

Fig 6.23: Scheduling & Re-Scheduling Swim Lane Diagram

Page | 37

6.2 Data Modeling

There are few tables with attributes which are used in that SRS. They are given below
with ER Diagram.

Database Table
User
PO

Pic
File
Category
Approvals
Date
Buyer
Supplier
Consignments
LogTable
Notification

Attribute
Type, Name, Mail, Password, id,
DateofJoin
Marchendiser, POid, id, PONumber,
Status, Quantity, Style,
ShipmentDate, OrderDate,
ProductionDate
Id, PearentPOid, PicName
Id, ParentPOId, filename
categoryId, parentPOid, name,
approvalStatus, InhouseStatus,
inhouseQuantity
ParentCategoryId, Id, SendingDate,
ResultDate, Status
Id, parentCategoryId, daterange,
dateName, datestatus
Id, Name, country, contact, mail
Id, name,country, contact, mail
sendingDate, id, quantity,
parentCategoryId
LogId, UserId, Activity,
DateTime,Status
NotificationId, NotificationText,
State, Time

Fig 6.24: Database Schema

Page | 38

Name
PO Number

Logid

User_id

PO_id

File

Password

Type

Activity
Status

Time

Quantity

Picture

PO

LogTable

User

Shipment Date

User_id

Supplier_id
Name

Name

Name
Category_id

Parent POid

Category

Supplier
Buyer
Quantity

Status
Buyer_id

Inhouse
Status

Approval
Result Date
Parent
Category_id

Approval_id
Cactgoryfixed
name

Sending Date

Categoryfixed_id

Sending Date

Categoryfixed
Consignment
Date_id
Quantity
Consignment_id

Date

P.Category_id
Text
Date Status

Parent
Category_id

Notification_
id

Notification

State
Date Name

Time

Fig 6.25: E-R Diagram

Page | 39

6.3 Class Based Model

6.3.1 Identifying Analysis Class
Now we will analyze the main scenario or the story to get those classesFirstly Merchandiser contacts with the buyer and settle down a deal on a right cost
and right time based on the capability of the production unit. On that deal the
merchandiser must have emphasized on the time and the cost. After the deal the deal
is done then the buyer will send the PO sheet to the merchandiser along with a file of
required details which will be needed for the production. If the deal is cancelled then
the total process is stopped.
On dealing with the supplier scenario firstly the merchandiser will select which
supplier will be most favorable to deal with considering the previous state records.
After selection the time and the cost budget must be fixed. If the time and the cost
budget arent favorable then the supplier must be changed. If the budget deal is done
then the quality of the product must be seen and if quality isnt right then upgrade the
existed quality. When all of them are done then booking will be given and a delivery
date will be recorded in which all of the goods will be delivered under right condition.
Sample of all required materials must be collected before o after dealing with supplier
and the materials must be sent for the approvals from the buyer. If the samples arent
correct then send again and again till the approval. After approving
individual
elements a size set sample and a pre production samples
are prepared and sent to
buyer. If approved then the approval date, time, approver contact info must be kept
and go to full production.
Then comes the in housing process. If the approve is done then the supplier will send
the total shipments of raw materials to the factory with the command of the
merchandiser. After receiving the products the item will be in housed.

Page | 40

Here we can see that probable classes are

Merchandiser
Buyer
Authentication
Supplier
Time
Approval
In house
PO
Database
Sample
Interface

Identifying analysis classes:

Analysis classes manifest themselves in one of the following ways.

External entities
Things
Occurrences Or Events
Roles
Organizational Units
Places
Structures

Potential Classes
User
Buyer
Authentication
Supplier
Time
PO
System
Interface
Database

Characteristics Number that Applies

Accepted 1,2,3,4,5,6
Accepted 1,2,3,7
Accepted all
Accepted 1,2,3,4,5,7
Accepted 1,2,3,4,5,7
Accepted 1,2,3,4,5,7
Accepted 1,2,3,4,7
Accepted 1,2,3 4,7
Accepted 1,2,3,5,6,7

Fig 6.26: Class Approval Diagram

Page | 41

6.3.2 Specifying Attributes and Defining operations

Class Cards

Class Name: User

Methods:

Attributes:

ChangePassword(); String

ID :Bigint
Username: String
Password: String
Name: String
Type: String
Department: String

Fig 6.27: User Class Card

Class Name: Buyer

Methods:

Attributes:
ID :Bigint
Name: String
Type: String
Contact info: String

Fig 6.28: Buyer Class Card

Page | 42

Class Name: Authentication

Methods:

Attributes:

SignUp(); Void

AuthenticationNumber :Bigint

SignIn(); void

User(Object)

SignOut( );void

DB(Object)

Fig 6.29: Authentication Class Card

Class Name: PO
Methods:

Attributes:

InsertProject(); User

DB(Object)

addFiles(); void

User(Object)

addRequiredList( ); Void

PODetails(Object)

Fig 6.30: PO Class Card

Class Name: Time

Methods:

Attributes:

BudgetTime(); Date

DateName :String

ReBudgetTime(); Date

StartDate:Date

CreateDateRange( ); Void

EndDate:Date
Database(Object)

Fig 6.31: Time Class Card

Page | 43

Class Name: Supplier

Methods:

Attributes:

SendConsignments(); User

Name: String

Booking(); void

Contact Info: String

Fig 6.32: Supplier Class Card

Class Name: Database

Methods:

Attributes:

addProject( );void

QueryString: String

Search( ); String

Result: Resultset

changeState( ); void

Fig 6.33: Database Class Card

Class Name: System

Methods:

Attributes:

GenerateNotice( );void

User(Object)

DB.AddProject(); User

DB(Object)

DB.changeState(); void

Time(Object)

Fig 6.34: System Class Card

Page | 44

Class Name: Interface

Methods:

Attributes:

ShowNotice( );void

User(Object)

showAlarm(); User

DB(Object)

Fig 6.35: Interface Class Card

Page | 45

6.3.3 CRC Model

Authentication

Interface

Database

System

Time

Supplier

User

PO

Buyer

Fig 6.36: CRC Model Diagram

Page | 46

6.4 Flow Oriented Model

Data Flow Diagrams
Notify

Works on

0.0
merchandiser
system

Merchandiser
Notify

Admin
Update system

Fig 6.37: Context Level DFD Diagram

1.0
Insert a
project
Create a new
project

2.0
supplier
selection
Create notification

Merchandiser
Send sample to buyer

3.0
sample
approval

Admin

Create notification

4.0
Notice
generation
Enables

Create notice

5.0
scheduling &
rescheduling

Fig 6.38: Level 0 DFD Diagram

Schedule & reschedule

Page | 47

Update PO

1.1
Input project
details

Additional Input

Update files

PO

Files
2.1
Choose
supplier

1.2
Add
files

1.1
Add
requirement
list

Update list

2.1
Choose
supplier

Requirement List

Finalize the requirement

lists
Fig 6.39: Level 1 DFD Diagram (Insert Project)

Merchandiser took design

of chosen suppliers
2.1
Choose
supplier

Choice from supplier

Book the supplier

Supplier
2.2
Book
supplier

Update supplier

Adding consignments

Consignment
s

Fig 6.40: Level 1 DFD Diagram (Supplier Selection)

Page | 48

Sample approvals
by merchandiser
Selected from list

3.1
Select
materials

Required list
Create sample

3.2
Create a
sample

Buyer
Select from buyer

3.3
Send sample
to buyer

Pack the sample

Approvals

Receive approval
result

3.4
Approvals

Add approvals time,

date approvers, mails

Fig 6.41: Level 1 DFD Diagram (Sample Approval)

Page | 49

Check if time is
crossing

Check if state
changed

4.1
State checker

4.2
Time checker

Generate level
Select Generate level

4.3
Generate
level

Generate Notice

4.4
Generate
notice

Log task

Update log table

Fig 6.40: Level 1 DFD Diagram (Supplier

Selection)
Fig 6.42: Level 1 DFD Diagram (Notice Generation)

Page | 50

Exceed time
5.1
Back cal.
production
rate

Generate
time

5.5
Exceed time

From objective
Adjust time

5.2
Generate
total time

Objective

Select from
objective
Select
objective

5.4
Adjust time
for objective

Adjust time with

date

5.3
Objective
Selection

Date

Fig 6.43: Level 1 DFD Diagram (Scheduling & Re-Scheduling)

Page | 51

6.5 Behavioral Model

6.5.1 State Transition Model

No

Get username,
password

Correct
Password?

Counter++

Yes

Logged in
Successfully

Sign Up Page

Counter>3
?
Yes

If Critical inputs are

filled
If reset password
is given

Give Confirmation
Mail

If Mail link is clicked

filled

Update the DB

Blocked

Send the reset

Password to
mail

No, Let
him try
again

Fig 6.44: Authentication State Diagram

Page | 52

Login as
Merchandiser

Upload files and

Fill the Text fields

Logged in
Fill the required
list Item Fields

Give Input

Add Required Items

If want to add an
item

If want to delete an
item

No

Clicked add
Button?

No

Clicked delete
Button?

Return Required
List

Yes

Yes

Fill the Text field

Press the ok Button

Exit
Press the Save
Button

Press the Save

Button

Update DB

Fig 6.45: Insert Project State Diagram

Page | 53

Running
System

Time> time
limit?

Click on the calendar

button to expand
time

Select Expanded
time

Logged as
Admin

Logged in
Back calculation on system
with production rate

Generate Time
Clicked on a
objective
button

Choose an objective
Click the
adjust/save
button to
save

Clicked on calendar
buttons to fix the date
range

Adjust the date

Update the
Database

Update DB

Fig 6.46: Scheduling & Re-Scheduling State Diagram

Page | 54

6.5.2 Sequence Model

UI

Control
Panel

System

DB

Reading

System
Ready

Change
Supplier
Book
Supplier

Supplier
Selecting

Supplier
Booking

Fig 6.47: Supplier Selection Sequence Diagram

UI

System
Ready

Control
Panel

System

DB

Reading

Create the
sample
Send it to buyer

Fig 6.48: Sample Approval Sequence Diagram

Page | 55

7.0 System Design

System Design is the process of defining the architecture, components, modules,
interfaces, and data for a system to satisfy specified requirements. Systems design
could be seen as the application of systems theory to product development. There is
some
overlap
with
the
disciplines
of systems
analysis, systems
architecture and systems engineering. We can define two part of design.
Logical design
Physical design

7.1 Logical design

The main logical part of our web application is the notification generation part. The
logical part of notice generation works likeEvery category has some attributes which has a data range, saved in the database. In
particular time space we collect the data range from the database and compare it with
the present date. Finally the system generates a notice. The notice can be positive,
negative or natural state. No matter what is the state is the system generate a notice
for every state and post it as notification in the Notice Board on the web browser for
all users.

7.2 Physical design

The physical design relates to the actual input and output processes of the system.
This is laid down in terms of how data is input into a system, how it is verified /
authenticated, how it is processed, and how it is displayed as output. In Physical
design, following requirements about the system are decided.

Input requirement,
Output requirements,
Storage requirements,
Processing Requirements,
System control and backup or recovery.

Put another way, the physical portion of systems design can generally be broken down
into three sub-tasks:
User Interface Design
Data Design
Process Design

Page | 56

The process design of notice generation process is look like this-

Todays Date

DB

Business
Logic

Generate
Notice

Web Page

DB

Notice Board

Fig 7.1: Physical process of Notice Generation

Page | 57

8.0 System Requirements

All web application needs certain hardware components or other software resources to
be present on a computer. These prerequisites are known as system requirements and
are often used as a guideline as opposed to an absolute rule. Most application defines
two sets of system requirements: minimum and recommended. With increasing
demand for higher processing power and resources in newer versions of application,
system requirements tend to increase over time.

8.1 Recommended Software Requirements

Oftentimes manufacturers of web applications will provide the consumer with a set of
requirements that are different than those that are needed to run the website. These
requirements are usually called the Recommended Requirements. These requirements
are almost always of a significantly higher level that the minimum requirements, and
represent the ideal situation in which to run the application. It has mainly two part Hardware requirements
Software requirements

8.2 Hardware Requirements

The most common set of requirements defined by any operating system or web
application is the physical computer resources, also known as hardware, A hardware
requirements list is often accompanied by a hardware compatibility list (HCL),
especially in case of operating systems. An HCL lists tested, compatible, and
sometimes incompatible hardware devices for a particular operating system or
application. The following sub-sections discuss the various aspects of hardware
requirements.

Computers or other operating system support devices

Memory
Secondary Storage
Live Server Support

Page | 58

8.3 Software Requirements

Software requirements deal with defining software resource requirements and
prerequisites that need to be installed on a computer to provide optimal functioning of
an application. These requirements or prerequisites are generally not included in the
software installation package and need to be installed separately before the software is
installed. For ours

Internet
HTML5 Supported Web browsers
Enabled script
Html5
CSS 3
Other plug-in on demand

8.4 Other Requirements

Some application also has other requirements for proper performance. Internet
connections considering type and speed and resolution of the display screen are
notable examples.

Page | 59

9.0 User Interface

9.1 Home Page

Company Name

Logo

Login

Register

Picture

Getting
About

Contact Us

Started

Footer

Fig 9.1: User Interface Home

Page | 60

9.2 Admin Home Page

Logo

Company Name
Logout

Search PO

Search

Merchandising

Insert PO

Calculator
Notice Board
Manage

Notification

Merchandiser

Adjust Time

Footer

Fig 9.2: Admin User Interface

Page | 61

10.0 Implementation & Testing

This chapter aims to explain the most technical part of this project. Here the
technologies that have been used to develop this application and the testing that have
been done during this application development will be described in brief-

10.1 Implementation
Implementation is the final and important phase. Implementation is the stage in the
project where the theoretical design is turned into a working system. The system can
be implemented only after thorough testing.

10.2 The Technology

The technologies that have been used to develop this application is the most recent
technologies and also very much appropriate to it.

10.3 Web user Interface

User interface is the working environment for the user. We used various language and
frameworks. Here they are:

10.3.1 ASP .NET MVC 4 Framework

ASP.NET MVC 4 is a framework for building scalable, standards-based web
applications using well-established design patterns and the power of ASP.NET and
the .NET Framework.

10.3.2 Cascading Style Sheet (CSS)

Cascading Style Sheets (CSS) is a style sheet language used for describing the
presentation semantics (the look and formatting) of a document written in a markup
language. There are several versions of CSS in web. We have used CSS3.0 version
which is latest version of it.

10.3.3 Hyper Text Mark up Language (HTML)

Hyper Text Markup Language (HTML) is the main markup language for web pages.
HTML elements are the basic building-blocks of a webpage. We have used the latest
HTML5 for developing this system.

10.3.4 JavaScript
JavaScript (JS) is an interpreted computer programming language. We implement
JavaScript as part of web browsers so that client-side scripts could interact with the
user, control the browser, communicate asynchronously, and alter the document
content that was displayed.

Page | 62

10.3.5 JQuery
JQuery is a fast, small, and feature-rich JavaScript library. We implement it so that it
makes things like HTML document traversal and manipulation, event handling,
animation, and Ajax much simpler with an easy-to-use API that works across a
multitude of browsers.

10.4 Internet Information Service (IIS)

IIS (Internet Information Server) is a group of Internet servers (including a Web or
Hypertext Transfer Protocol server and a File Transfer Protocol server) with
additional capabilities for Microsoft's Windows NT and Windows 2000 Server
operating systems. With IIS, Microsoft includes a set of programs for building and
administering Web sites, a search engine, and support for writing Web-based
applications that access databases. We have used IIS 7.5 express which comes by
default with Visual Studio 2010 Professional edition.

10.5 Implementation Tools

As types of software are increasing day by day, new implementation tools are also
needed for their implementation. Now-a-days, there are many implementation tools.
Developers have to choose right tools for each part of their application. If they can
utilize tools perfectly, their labor can be reduced.

10.6 Microsoft Visual Studio 2012

Microsoft Visual Studio is a suite of component-based development tools and other
technologies for building powerful, high-performance applications. In addition,
Visual Studio is optimized for team-based design, development, and deployment of
enterprise solutions. We have chosen
Microsoft visual studio because:

It is lightweight with respect to its ability.

Database development is very easy and efficient. It supports entity framework.
Its free and open source.
It supports various plug-in. We can add whatever plug-in is needed for our
application.
Its suggestions and auto complete features are excellent.
Have a user friendly interface.
Visual Studio includes a code editor supporting IntelliSense as well as code
refactoring.
Visual Studio supports different programming languages by means of
language services, which allow the code editor and debugger to support (to
varying degrees) nearly any programming language, provided a languagespecific service exists. Built-in languages include C/C++ (via Visual C++),
VB.NET (via Visual Basic .NET), C# (via Visual C#), and F# (as of Visual
Studio 2010). Support for other languages such as M, Python, and Ruby

Page | 63

among others is available via language services installed separately. It also

supports XML/XSLT, HTML/XHTML, JavaScript and CSS. Individual
language-specific versions of Visual Studio also exist which provide more
limited language services to the user: Microsoft Visual Basic, Visual J#,
Visual C#, and Visual C++.

10.7 SQL Server 2008

Microsoft SQL Server 2008 is a cloud-ready information platform that will help
organizations unlock breakthrough insights across the organizations and quickly build
solutions to extend data across on-premises and public cloud.

10.8 Testing
Software testing is an investigation conducted to provide stakeholders with
information about the quality of the product or service under test. We wanted to test
our application perfectly. But unfortunately, we do not have enough knowledge to test
such application.
With our limited knowledge of testing, we do some informal testing during
development period. As it was informal, we cannot submit any document.
This means that this current version is released without any formal testing.

Page | 64

11.0 Implementation & Testing

This is a step by step illustration of using this merchandising web application.

11.1 Target User

This merchandising software is aiming at sampling department, development and
sample room of buying office, sourcing company, trading company and factory.
Company in import and export of soft line product will find this software extremely
helpful for them to arrange their sampling development. Best for garment, clothing,
apparel, fashion Accessories, footwear, bags, luggage, plush toys, hats, travel goods,
sporting goods, sundries, household items, home textiles, giftware, premium,
promotional items and etc.

11.2 Design Concepts

The design concept of this merchandising application is combined with some
modules. One of the key features is the sample details and the next is the provide
notification to the merchandiser. By using the sample detail panel, it collects the
sampling order information. By receiving the notification the users will notified for
their job.

11.3 Home Panel

Fig 11.1: Home panel

Page | 65

In this panel the user will authenticate for using this application by pressing the login
button. If the user is not authenticate for this application then the user will press the
registration button and fill the registration from for being authenticated.

11.4 Login Panel

User fills the all required field for logged in and for use the application. If the user is
logged in as a merchandiser then the user will get merchandising panel and admin will
get admin panel for use the application.

Fig 11.2: Login panel

Page | 66

11.5 Register Panel

User fills the all required field for being authenticated and for use the application.
User has to fill the entire required field.

Fig 11.3: Register Panel

Page | 67

11.6 User Home Panel

Merchandiser panel is only for the user who logged is as a merchandiser. In this panel
merchandiser get an insert PO (product order) button. By clicking the button
merchandiser fill in all the sampling request detail. There merchandiser find a
merchandising calculator. By using the calculator one can calculate the cost. In the
right side of the panel there is a notice board where merchandiser can show the short
notifications from system. For show the notification in details merchandiser have to
click the Notification button or press the see more link in the notice board. For
searching the desire PO (product order) the merchandiser will search in the search bar.

Fig 11.4: User Home panel

Page | 68

11.7 Admin Panel

If the user logged in as an admin then admin panel will open. Admin panel is almost
similar to merchandiser panel. But Admin have two additional fitches one is mange
merchandiser and other one is adjust time. Using the manage merchandiser button
admin can block, unblock and delete user. By pressing the adjust time button admin
can set the time rage for supplier selection, approval status, lab dip, in-house process,
bucking status.

11.8 Manage PO Panel

Manage PO is for both admin and merchandiser. In that panel merchandiser can
change the status and admin can verify the date range of each category.

Fig 11.5: PO Details Panel

Page | 69

11.9 PO Submission Panel

In the first step of PO submission panel we select buyer. If we don't find the buyer in
the drop down then press the insert new buyer button. Here user also inserts PO
number, Style number, order date, Shipment date and quantity. Upload PO file which
contain the full information of the order. Add some image of the product in the PO
submission.

Fig 11.6: Insert PO Panel

Page | 70

11.10 Insert buyer Information panel

In this panel we insert new buyer in the system. Here we insert full name, company
name, e-mail, contact, country of the buyer. That buyer we can select in the PO
submission panel.

Fig 11.7: Create Buyer Panel

12.0 Conclusion
In our project, we have established a basic understanding of the problem, the nature of
the solution that is desired and the effectiveness of preliminary communication and
collaboration between the stake-holders and the software team. More studies and
communication will help both side (developer and client) to understand the future
prospect of the project. Our team believes that the full functioning document will help
us to define that future prospect.

Page | 71

Appendix
1. IEEE STD 830-1998 IEEE Recommended Practice or Software
Requirement Specifications. IEEE Computer Society, 1998.
2. Software Engineering, A Practitioners Approach-6th edition, Roger
S. Pressman
3. Professional ASP.NET 3.5 in C# and VB, Bill Evjen , Scott
Hanselman , Devin Rader
4. Programming ASP.NET MVC 4, Jess Chandwick, Todd Snyder,
Hrusikesh Panda
5. http://www.asp.net/mvc/tutorials/mvc-4/getting-started-with-aspnetmvc4/intro-to-aspnet-mvc-4
6. http://pluralsight.com/training/Courses/TableOfContents/mvc4
7. http://www.microsoft.com/en-us/sqlserver/get-sql-server/try-it.aspx
8. http://en.wikipedia.org/wiki/Software_requirements_specification
9. http://en.wikipedia.org/wiki/.NET_Framework
10. http://www.codecademy.com/tracks/jquery
11. http://www.jotform.com/
12. http://www.ibuyer.hk/Services.html
13. http://en.wikipedia.org/wiki/Merchandising
14. http://en.wikipedia.org/wiki/Software_requirements_specification
15. http://msdn.microsoft.com/en-us/library/aa479011.aspx
16. http://hectorea.com/blog/building-a-mvc-4-app-with-database-firstand-entity-framework-5-1/

Page | 72