Page | 1

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 | 2

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 | 3

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 | 4

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 | 5

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 | 6

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 below-

Firstly 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 t ime

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 | 7

1.0 Introduction

1.1 Purpose

The main objective of this document is to illustrate the requirements of the project

merchandising system. The 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 | 8

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 software

because they operate and maintain a whole garments.

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 | 9

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 | 10

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 | 11

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 | 12

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 | 13

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 | 14

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 and prove to be very satisfying when present

Automated warning mail generation Enrich the web site with style and others

If anyone forget password ,can get them back form SMS

Normal Requirements

Expected Requirements

Wow factors

Page | 15

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 | 16

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 | 17

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 Support-

SQL 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 | 18

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 | 19

6.1.1 Use Case

Fig 6.1: Use Case Scenarios

Use case Name: Authentication

Use case No: 1 Primary Actor: User(Admin/Merchandiser)

Secondary Actor: N/A Description: User has to login to authenticate

himself/herself Precondition: Must be registered

Trigger: Clicking the sign-in/sing-up button Events: Checking the validity of users.

Fig 6.2: Authentication Use Case Scenarios Properties

1. Authentication

2. Insert Project

4. Supplier

Selection

6. Notice Generate

5. Sample Approval 3. Scheduling &

Re-scheduling

Page | 20

Use case Name: Insert Project

Use case No: 2 Primary Actor: User(Merchandiser)

Secondary Actor: Admin Description: Adding a new project in the system

Precondition: The order must be confirmed & PO must be received

Trigger: Clicking insert button Events: Give the user the privilege to insert a

new project

Fig 6.3: Insert Project Use Case Scenarios Properties

Use case Name: Scheduling & Re-scheduling

Use case No: 3 Primary Actor: User(Admin)

Secondary Actor: Merchandiser Description: Budgeting the total time from order

to inhouse Precondition: User must be logged as admin

Trigger: Pressing the scheduling or re-scheduling button

Events: Make a budget of the total time

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

Use case Name: Supplier Selection

Use case No: 4 Primary Actor: User(Merchandiser)

Secondary Actor: Admin Description: Select a supplier for every single

raw-material Precondition: PO must be received

Trigger: Changing the state of supplier in the running project

Events: Select the supplier

Fig 6.5: Supplier Selection Use Case Scenarios Properties

Page | 21

Use case Name: Sample Approval

Use case No: 5 Primary Actor: User(Merchandiser)

Secondary Actor: Admin Description: To approve the sample from buyer

Precondition: The sample should be ready Trigger: Changing the state of approval in the

running project Events: 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: Notice Generate Use case No: 6

Primary Actor: N/A

Secondary Actor: Admin/ Merchandiser Description: Generate notice from system and

show on users notice panel Precondition: 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 | 22

6.1.2 Use Case Diagram

Fig 6.8: Level 0 Use Case Diagram

Authentication

Insert Project

Admin

Merchandiser

DB

Scheduling &

Re-scheduling

Supplier Selection

Notice Generate

Sample Approval

Page | 23

Fig 6.9: Authentication Use Case Diagram

Sign up

Verify

Sign in

Retry

Sign out

Admin

Merchandiser

Block

Page | 24

Fig 6.10: Insert Project Use Case Diagram

Insert Details

File Upload

Adding

Category

Removing

Category

Update DB

Admin

Merchandiser

Page | 25

Back

Calculation

Generate Total

Time

Select Objective

Adjust Time for

the Objective

Update DB

Merchandiser

Admin

Fig 6.11: Scheduling & Re-Scheduling Use Case Diagram

Page | 26

Select Material

Select Supplier

Change

Supplier

Book Supplier

Update DB

Admin

Merchandiser

Fig 6.12: Supplier Selection Use Case Diagram

Page | 27

Select Materials

Create Sample

Send to Buyer

Get the

Approval

Update DB

Admin

Merchandiser

Fig 6.13: Sample Approval Use Case Diagram

Page | 28

Generate

Report from

Time Checker

Create Notice

Show it on

Notice Board

Update DB

Admin

Merchandiser

Fig 6.14: Notice Generation Use Case Diagram

Page | 29

6.1.3 Activity Diagram

Fig 6.15: Authentication Activity Diagram

User

Have

Account?

Correct

Username/

Password

Give Input

Logged in

System

Try>3 ?

Try=Try+1

Reset Password Sign Up

Check

Confirmation Mail

Yes

No

Yes

No

Yes

No

Page | 30

Login as

Merchandiser

Create

required item?

Exit

Delete required

Item?

Return Required

List

Insert Details

Delete Required List

Item

Update DB

Yes Yes

No No

Upload Files

Add Required Items

Add required list Item

Fig 6.16: Insert Po Activity Diagram

Page | 31

Fig 6.17: Scheduling and Re-scheduling Activity Diagram

User Logged as

Admin

Back calculation with

Production rate

Time Limit

Exceed?

Adjust Time for that

Objective

No No

Yes

Generate Total Time

Select an Objective

Running system on an

Objective

Select expended time

Change the

DB

Page | 32

Fig 6.18: Supplier Selection Activity Diagram

Select a Material

Select a Supplier

Cost?

Book the Supplier

Change the Supplier

Quantity? Time?

Update DB with

Submission date

No

Yes

No

Yes Yes

No

Page | 33

Fig 6.19: Sample Approval Activity Diagram

Select Material

Create a sample

Send sample to Buyer

Update DB

Get the approved mail,

date and approver

Approved?

No

Yes

Page | 34

Time Checker

Update Log Table in DB

Create A Notice

Critical?

No

Yes

Select Material

Alarm?

State Checker

Generated Report of Checker

Reverse? Done?

Positive State Negative State

Post the Notice

Yes

Yes

Yes

No

No No

Fig 6.20: Notice Generation Activity Diagram

Page | 35

6.1.4 Swim lane Diagram

User System UI

Merchandiser

Want

to

add?

Update Category

Remain unchanged

File upload

Insert Details

Want to

remove?

Update DB

Fig 6.21: Insert Project Swim Lane Diagram

Page | 36

User System UI

Merchandiser

Approve

or not?

Get the approved mail

Exit

Send it to buyer

Select a Merchandiser

Update DB

Yes

No

Fig 6.22: Sample Approval Swim Lane Diagram

Page | 37

User

System

UI

Admin Back calculation

Generate total

time

Select objective

Select extended

time

Adjust time for

the objective Update DB

Time

limit

exceed

Fig 6.23: Scheduling & Re-Scheduling Swim Lane Diagram

Page | 38

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 Attribute User Type, Name, Mail, Password, id,

DateofJoin PO Marchendiser, POid, id, PONumber,

Status, Quantity, Style, ShipmentDate, OrderDate, ProductionDate

Pic Id, PearentPOid, PicName

File Id, ParentPOId, filename Category categoryId, parentPOid, name,

approvalStatus, InhouseStatus, inhouseQuantity

Approvals ParentCategoryId, Id, SendingDate, ResultDate, Status

Date Id, parentCategoryId, daterange, dateName, datestatus

Buyer Id, Name, country, contact, mail

Supplier Id, name,country, contact, mail

Consignments sendingDate, id, quantity, parentCategoryId

LogTable LogId, UserId, Activity, DateTime,Status

Notification NotificationId, NotificationText, State, Time

Fig 6.24: Database Schema

Page | 39

PO_id

Quantity

Picture

Shipment Date

Type

Name

Parent POid Category_id

Inhouse

Status

Quantity

Buyer_id

Name

Parent

Category_id

Result Date

Status

Sending Date

Approval_id

Quantity

Consignment_id

P.Category_id

Sending Date

Supplier_id

Name

Date Status Parent

Category_id

Date_id

Date Name

PO User LogTable

User_id

Time

Buyer Supplier Category

Approval

Consignment

Categoryfixed

Date

Cactgoryfixed

name

Categoryfixed_id

Notification

Time

State

Text

Notification_

id

File

PO Number

Fig 6.25: E-R Diagram

Name

Password User_id

Logid

Status

Activity

Page | 40

6.3 Class Based Model

6.3.1 Identifying Analysis Class

Now we will analyze the main scenario or the story to get those classes-

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 | 41

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 Characteristics Number that Applies

User Accepted 1,2,3,4,5,6

Buyer Accepted 1,2,3,7

Authentication Accepted all Supplier Accepted 1,2,3,4,5,7

Time Accepted 1,2,3,4,5,7

PO Accepted 1,2,3,4,5,7

System Accepted 1,2,3,4,7

Interface Accepted 1,2,3 4,7 Database Accepted 1,2,3,5,6,7

Fig 6.26: Class Approval Diagram

Page | 42

6.3.2 Specifying Attributes and Defining operations

Class Cards

Fig 6.27: User Class Card

Fig 6.28: Buyer Class Card

Class Name: User

Methods:

ChangePassword(); String

Attributes:

ID :Bigint

Username: String

Password: String

Name: String

Type: String

Department: String

Class Name: Buyer

Methods:

Attributes:

ID :Bigint

Name: String

Type: String

Contact info: String

Page | 43

Fig 6.29: Authentication Class Card

Fig 6.30: PO Class Card

Fig 6.31: Time Class Card

Class Name: Authentication

Methods:

SignUp(); Void

SignIn(); void

SignOut( );void

Attributes:

AuthenticationNumber :Bigint

User(Object)

DB(Object)

Class Name: PO

Methods:

InsertProject(); User

addFiles(); void

addRequiredList( ); Void

Attributes:

DB(Object)

User(Object)

PODetails(Object)

Class Name: Time

Methods:

BudgetTime(); Date

ReBudgetTime(); Date

CreateDateRange( ); Void

Attributes:

DateName :String

StartDate:Date

EndDate:Date

Database(Object)

Page | 44

Fig 6.32: Supplier Class Card

Fig 6.33: Database Class Card

Fig 6.34: System Class Card

Class Name: Supplier

Methods:

SendConsignments(); User

Booking(); void

Attributes:

Name: String

Contact Info: String

Class Name: Database

Methods:

addProject( );void

Search( ); String

changeState( ); void

Attributes:

QueryString: String

Result: Resultset

Class Name: System

Methods:

GenerateNotice( );void

DB.AddProject(); User

DB.changeState(); void

Attributes:

User(Object)

DB(Object)

Time(Object)

Page | 45

Fig 6.35: Interface Class Card

Class Name: Interface

Methods:

ShowNotice( );void

showAlarm(); User

Attributes:

User(Object)

DB(Object)

Page | 46

6.3.3 CRC Model

Authentication User Interface

Buyer Supplier

Database System

Time

PO

Fig 6.36: CRC Model Diagram

Page | 47

6.4 Flow Oriented Model Data Flow Diagrams

Merchandiser 0.0

merchandiser

system

Admin

Notify

Notify

Update system

Works on

Merchandiser

1.0

Insert a

project

2.0

supplier

selection

3.0

sample

approval

4.0

Notice

generation

5.0

scheduling &

rescheduling

Admin

Create a new

project

Send sample to buyer

Create notification

Create notification

Schedule & reschedule

Create notice Enables

Fig 6.37: Context Level DFD Diagram

Fig 6.38: Level 0 DFD Diagram

Page | 48

1.1

Input project

details

1.2

Add

files

1.1

Add

requirement

list

PO

Files

2.1

Choose

supplier

2.1

Choose

supplier

2.1

Choose

supplier

2.2

Book

supplier

Supplier

Consignment

s

Update PO

Additional Input

Update files

Requirement List

Update list

Finalize the requirement

lists

Merchandiser took design

of chosen suppliers

Choice from supplier

Book the supplier

Update supplier

Adding consignments

Fig 6.40: Level 1 DFD Diagram (Supplier Selection)

Fig 6.39: Level 1 DFD Diagram (Insert Project)

Page | 49

3.1

Select

materials

3.2

Create a

sample

3.3

Send sample

to buyer

3.4

Approvals

Required list

Buyer

Approvals

Selected from list

Create sample

Select from buyer

Sample approvals

by merchandiser

Pack the sample

Receive approval

result

Add approvals time,

date approvers, mails

Fig 6.41: Level 1 DFD Diagram (Sample Approval)

Page | 50

4.4

Generate

notice

4.3

Generate

level

4.2

Time checker

4.1

State checker

Log task

Check if state

changed

Check if time is

crossing

Generate level

Select Generate level

Generate Notice

Update log table

Fig 6.40: Level 1 DFD Diagram (Supplier Selection)

Fig 6.42: Level 1 DFD Diagram (Notice Generation)

Page | 51

5.1

Back cal.

production

rate

5.2

Generate

total time

5.3

Objective

Selection

5.5

Exceed time

5.4

Adjust time

for objective

Objective

Date

Exceed time

Adjust time

Adjust time with

date

Select from

objective

Select

objective

Generate

time

From objective

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

Page | 52

6.5 Behavioral Model

6.5.1 State Transition Model

Fig 6.44: Authentication State Diagram

Get username,

password

Correct

Password?

Logged in

Successfully

Counter++

Yes

Counter>3

?

Sign Up Page

Give Confirmation

Mail

Update the DB

If Critical inputs are

filled

If Mail link is clicked

filled

Blocked

Send the reset

Password to

mail

No, Let

him try

again

Yes

If reset password

is given

No

Page | 53

Clicked add

Button?

Exit

Clicked delete

Button?

Return Required

List

Logged in

Press the ok Button

Update DB

Yes Yes

No No

Give Input

Add Required Items

Fill the Text field

Fig 6.45: Insert Project State Diagram

Login as

Merchandiser

Upload files and

Fill the Text fields

Fill the required

list Item Fields

If want to add an

item

If want to delete an

item

Press the Save

Button

Press the Save

Button

Page | 54

Fig 6.46: Scheduling & Re-Scheduling State Diagram

Logged in

Logged as

Admin

Running

System

Generate Time

Back calculation on system

with production rate

Choose an objective

Clicked on a

objective

button

Adjust the date

Clicked on calendar

buttons to fix the date

range

Select Expanded

time

Update DB

Click the

adjust/save

button to

save

Update the

Database

Time> time

limit?

Click on the calendar

button to expand

time

Page | 55

6.5.2 Sequence Model

Fig 6.47: Supplier Selection Sequence Diagram

Fig 6.48: Sample Approval Sequence Diagram

UI Control Panel

System DB

Reading System

Ready

Change

Supplier

Supplier

Selecting

Supplier

Booking

UI Control Panel

System DB

System

Ready

Reading

Create the

sample

Send it to buyer

Book

Supplier

Page | 56

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 like-

Every 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 | 57

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

Fig 7.1: Physical process of Notice Generation

DB

Business

Logic

Generate

Notice

Web Page

Notice Board

DB

Todays Date

Page | 58

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 | 59

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 | 60

9.0 User Interface

9.1 Home Page

Logo Company Name

Login Register

Footer

Picture

About Getting

Started Contact Us

Fig 9.1: User Interface Home

Page | 61

9.2 Admin Home Page

Logo Company Name

Logout

Footer

Insert PO

Notice Board

Merchandising

Calculator

Notification Manage

Merchandiser

Adjust Time

Search PO

Fig 9.2: Admin User Interface

Search

Page | 62

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 | 63

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 language-

specific 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 | 64

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 | 65

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 | 66

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 | 67

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 | 68

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 | 69

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 | 70

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 | 71

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 | 72

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-aspnet-

mvc4/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-first-

and-entity-framework-5-1/