final report body
DESCRIPTION
A final report on web base garmanets management project.TRANSCRIPT
-
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/