Software Engineering for E-Commerce Website 'The Iconic'

This article discusses the software engineering process model, requirement verification method, context diagram, actors and use cases, fully developed use case description, activity diagram, sequence diagrams, class diagram, verification of user requirements, system specification, software testing and acceptance criteria, and proposed deployment strategy for an e-commerce website 'The Iconic'.

Running head: SOFTWARE ENGINEERING
Software Engineering: E-Commerce Website “The Iconic”
Student Name:
University Name:

1SOFTWARE ENGINEERING
Table of Contents
1. Assignment #1 Progression................................................................................................................2
2. Recommended software engineering process model........................................................................2
3. Requirement verification method.....................................................................................................3
4. Context Diagram for the complete overall system............................................................................4
5. Actors and use cases for the system..................................................................................................4
6. Fully developed use case description................................................................................................5
Use case 1.........................................................................................................................................5
Use case 2.........................................................................................................................................5
7. Activity diagram for 2 scenarios.........................................................................................................6
8. Sequence diagrams for 2 scenarios...................................................................................................8
9. Class diagram for the complete overall system...............................................................................10
10. Verification of user requirements..................................................................................................10
11. System Specification......................................................................................................................11
Technical feasibility.........................................................................................................................11
Economical feasibility......................................................................................................................11
Operational feasibility.....................................................................................................................11
12. Software testing and acceptance criteria......................................................................................12
13. Proposed deployment strategy.....................................................................................................12
14. Project Activity Journal..................................................................................................................12
Bibliography.........................................................................................................................................14

2SOFTWARE ENGINEERING
1. Assignment #1 Progression
Version Date Author(s) Change Description
1.1 14/05/2018 [Please Fill Your
Name]
Preparation of second draft of system requirements
specification document
1.1 17/05/2018 [Please Fill Your
Name]
Providing recommendation of process model for
software engineering
1.1 19/05/2018 [Please Fill Your
Name]
Selecting the method for requirement verification
along with verifying the requirements of user and
stakeholder
1.1 21/05/2018 [Please Fill Your
Name]
Preparation of various modelling diagrams for the
system
1.1 24/05/2018 [Please Fill Your
Name]
Verifying the requirements of user and documenting
the system specification
1.1 28/05/2018 [Please Fill Your
Name]
Defining the process for software testing along with
criteria for acceptance of the system
1.1 30/05/218 [Please Fill Your
Name]
Proposing the strategy for deployment of system
2. Recommended software engineering process model
The Waterfall Model was first model introduced for development of systems and it has been
chosen as the suitable method for the e-commerce website. It is likewise alluded to as a direct
consecutive life cycle display. It is extremely easy to comprehend and utilize. In a waterfall display,
each stage must be finished completely before the following stage can start. This sort of
programming improvement demonstrate is essentially utilized for the task which is little and there
are no indeterminate necessities. Toward the finish of each stage, a survey happens to decide
whether the venture is on the correct way and regardless of whether to proceed or dispose of the
task. In this model programming testing begins simply after the advancement is finished. In waterfall
demonstrate stages do not cover. The waterfall display underscores that an intelligent movement of
steps be taken all through the product advancement life cycle (SDLC), much like the falling strides
down an incremental waterfall. While the prevalence of the waterfall display has melted away

3SOFTWARE ENGINEERING
finished late years for more deft strategies, the intelligent idea of the successive procedure utilized
as a part of the waterfall strategy cannot be denied, and it remains a typical outline process in the
business.
The upside of waterfall improvement is that it takes into account departmentalization and
administrative control. A calendar can be set with due dates for each phase of advancement and an
item can continue through the improvement procedure like an auto in a carwash, and
hypothetically, be conveyed on time. Advancement moves from idea, through plan, usage, testing,
establishment, investigating, and winds up at task and upkeep. Each period of improvement
continues in strict request, with no covering or iterative advances.
The detriment of waterfall advancement is that it does not takes into consideration much
reflection or correction. Once an application is in the testing stage, it is extremely hard to return and
change something that was not well-thoroughly considered in the idea arrange. Other options to the
waterfall demonstrate incorporate joint application improvement (JAD), quick application
advancement (RAD), sync and balance out, form and settle, and spiral model.
3. Requirement verification method
The verification of requirements indicate the confirmation occasions expected to
demonstrate the fulfillment of the item prerequisites and help to characterize the check procedure
and condition. The four principal strategies for confirmation are Inspection, Demonstration, Test,
and Analysis. The four techniques are to some degree various leveled in nature, as each checks
prerequisites of an item or framework with expanding thoroughness. Test is the check of an item or
framework utilizing a controlled and predefined arrangement of sources of info, information, or jolts
to guarantee that the item or framework will deliver an unmistakable and predefined yield as
determined by the prerequisites.
Investigation is the check of an item or framework utilizing models, computations and
testing gear. Examination enables somebody to put forth prescient expressions about the normal
execution of an item or framework in light of the affirmed test aftereffects of an example set or by
consolidating the result of individual tests to close something new about the item or framework.
Usually used to anticipate the limit or disappointment of an item or framework by utilizing
nondestructive tests to extrapolate the disappointment point.

4SOFTWARE ENGINEERING
4. Context Diagram for the complete overall system
5. Actors and use cases for the system
The actors that are associated with the system are identified and listed as below:
 Customer
 Admin
 Vendor
 Bank
 Stock manager
The use cases of the entire system as identified in context to business of “The Iconic” are
presented as below:
 View product
 Add to shopping cart
 Manage inventory
 Making payments
 Creating user account
 Delivery of products

5SOFTWARE ENGINEERING
6. Fully developed use case description
Use case 1
Use Case Name: UC1 - View product
Scenario: Customers access the system to view products offered by the business
Triggering Event: User searches for particular product or visits the product catalogue
Brief Description: This use case illustrates upon the interaction between user and system when
a user searches for particular product or clicks on product section
Actors: Customer
Stakeholders: Customer, Company
Preconditions: User is able to locate the products section easily
Postconditions: The list of products is provided with description and option to add in cart
Flow of Activities: Actor System
 Search particular product
 Request to view product
catalogue
 View description and details of
product
 Displays particular product or
related items
 Displays list of products according
to category
 Displays product information
Exception Conditions: Unregistered users are not able to add product in the shopping cart
Use case 2
Use Case Name: UC2 - Making payment
Scenario: Depicts the process of making payment through online while shopping from
the website
Triggering Event: User selects to make payment for chosen products
Brief Description: This use case illustrates upon the process that is being followed as interaction
between user and system
Actors: Customer
Stakeholders: Customer, Company, Bank
Preconditions: User has selected suitable option for payment from displayed menu
Postconditions: User has authorized payment through online mode
Flow of Activities: Actor System
 User clicks on payment option
 Selects payment mode from
 Displays payment menu screen
 Displays payment screen with

6SOFTWARE ENGINEERING
displayed options
 Enters information for making
payment
mode as chosen by user
 Accepts payment and gives
confirmation
Exception Conditions: Billing amount is deducted from Bank account but payment has not been
confirmed by the system
7. Activity diagram for 2 scenarios
Display item

7SOFTWARE ENGINEERING
Make Payment

8SOFTWARE ENGINEERING
8. Sequence diagrams for 2 scenarios
Order product

9SOFTWARE ENGINEERING
Payment

10SOFTWARE ENGINEERING
9. Class diagram for the complete overall system
10. Verification of user requirements
Distinguishing proof of the proposed confirmation strategy is a fundamental property of an
elegantly composed prerequisite. Appraisal of confirmation as you build up your necessities
enhances prerequisite quality, guarantees your prerequisites bolster check, gives the premise to
assessing confirmation cost and plan, and can help diminish the cost of these exercises. Watchful
appraisal of the prerequisites that are most expensive to check can regularly bring about alteration
to the related confirmation exercises to decrease the confirmation cost while as yet addressing your
framework's Need, objectives and destinations. A compulsory normal for a prerequisite is that it is
required. On the off chance that a necessity is not required, why is it in the prerequisite set? By it’s
extremely presence, a prerequisite has a dollar esteem related with it. "Every prerequisite conveys a
cost. It is along these lines basic that a total yet least arrangement of necessities be set up from
characterized partner prerequisites ahead of schedule in the venture life cycle. Changes in
prerequisites later in the advancement cycle can have a noteworthy cost effect on the venture,
potentially bringing about cancelation."
All necessities should be kept up, overseen, and checked. Prerequisites that are a bit much
outcome in expanded administration cost of the necessities that, thus, builds general task expenses
and leaves less assets for required prerequisites. Un-required prerequisites result in work being

11SOFTWARE ENGINEERING
played out that is not important, removing assets from the usage of those necessities that are
required. Also, executing prerequisites that are redundant can bring about debased framework
execution and in addition presenting a potential source of disappointment as well as conflict.
11. System Specification
Technical feasibility
This feasibility study decides if the work for the venture should be possible with the current
gear, programming innovation and accessible faculty. Specialized practicality is worried about
indicating gear and programming that will fulfill the client necessity. This undertaking is doable on
specialized comments likewise, as the proposed framework is more recipient regarding having an
online business framework with new specialized segments introduced on the framework. The
proposed framework can keep running on any machines supporting Windows and Internet
administrations and takes a shot at the best programming and equipment that had been utilized
while planning the framework so it would be practical in every specialized term of feasibility.
Economical feasibility
This feasibility study decides if there are adequate advantages in making to make the cost
satisfactory, or is the cost of the framework too high. As this means money saving advantage
examination and reserve funds. For the sake of the money saving advantage investigation, the
proposed framework is practical and is efficient with respect to its pre-accepted cost for making a
framework. We characterized the expenses of web based business site as indicated by the stage in
which they happen. As we realize that the framework improvement costs are normally one-time
costs that will not repeat after the undertaking has been finished.
Operational feasibility
This feasibility study measures depth of the issue (study and study stages) or the worthiness
of an answer (determination, obtaining and configuration stages). How would you quantify
operational plausibility? There are two parts of operational plausibility to be considered:
UML (UNIFIED Modeling LANGUAGE): The Unified Modeling Language (UML) is a standard
dialect for indicating, imagining, developing, and recording the ancient rarities of programming
frameworks, and in addition for business displaying and other non-programming frameworks. The
UML speaks to an accumulation of best designing practices that have demonstrated effective in the
displaying of expansive and complex frameworks. The UML is an imperative piece of creating object
arranged programming and the product advancement process.

12SOFTWARE ENGINEERING
12. Software testing and acceptance criteria
The various types of testing (unit, framework, practical, black-box, and others) are very
much archived in the writing. Be that as it may, less very much enunciated (regardless of the great
general messages in programming building) is the test procedure that ties together all testing and
approval exercises used to convey a quality answer for the customer.
Program similarity: Customers will end up baffled on the off chance that they cannot get to
your web based business webpage effectively. In spite of the fact that generally easy to do, it pays to
invest enough energy testing around there. Absence of help for early programs. Not all programs are
equivalent. For instance, some early forms of Internet Explorer and Netscape Navigator do not
completely bolster JavaScript. The framework ought to be good with IE form 3.0 or more and
Netscape variant 2.0 or more. Testing the framework does in reality work without issue on the early
program renditions.
Page show: A page show may likewise include stacking assets, (for example, applets) in
advance, and you could experience issues when such assets are inaccessible. Test that your
framework handles such exemptions fittingly.
Error messages during runtime: Users get baffled when a program hurls startling mistake
messages. Such mistake messages are for the most part unpleasant and not significant to clients;
additionally, they leave a poor impact on the client.
13. Proposed deployment strategy
The test site technique is utilized to choose a test area or test gathering to pilot an
innovation, utilizing this strategy, an analysis is raced to check whether the new innovation is
genuinely relevant inside an association. This system powers innovation chiefs to settle on a test
area and to enroll a test bunch as dynamic members. Test locales can later progress toward
becoming features of the innovation. By implementing formal audit methods, important bits of
knowledge can be picked up into the value and issue regions of given innovation. The test site
methodology likewise devours time and in some cases the outcomes can be uncertain.
14. Project Activity Journal
Date Activity Duration Status
14/05/201
8
Preparation of second draft of system requirements
specification document
16 days Completed
17/05/201 Providing recommendation of process model for software 03 days Completed

13SOFTWARE ENGINEERING
8 engineering
19/05/201
8
Selecting the method for requirement verification along
with verifying the requirements of user and stakeholder
02 days Completed
21/05/201
8
Preparation of various modelling diagrams for the system 02 days Completed
24/05/201
8
Verifying the requirements of user and documenting the
system specification
03 days Completed
28/05/201
8
Defining the process for software testing along with
criteria for acceptance of the system
04 days Completed
30/05/218 Proposing the strategy for deployment of system 02 days Completed

14SOFTWARE ENGINEERING
Bibliography
[1.] Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J., 2017. Agile software development
methods: Review and analysis. arXiv preprint arXiv:1709.08439.
[2.] Asadi, M., Soltani, S., Gašević, D. and Hatala, M., 2016. The effects of visualization and
interaction techniques on feature model configuration. Empirical Software Engineering, 21(4),
pp.1706-1743.
[3.] Braude, E.J. and Bernstein, M.E., 2016. Software engineering: modern approaches.
Waveland Press.
[4.] Buede, D.M. and Miller, W.D., 2016. The engineering design of systems: models and
methods. John Wiley & Sons.
[5.] Fabijan, A., Olsson, H.H. and Bosch, J., 2015, June. Customer feedback and data collection
techniques in software R&D: a literature review. In International Conference of Software Business
(pp. 139-153). Springer, Cham.
[6.] Filieri, A., Maggio, M., Angelopoulos, K., D'Ippolito, N., Gerostathopoulos, I., Hempel, A.B.,
Hoffmann, H., Jamshidi, P., Kalyvianaki, E., Klein, C. and Krikava, F., 2015, May. Software engineering
meets control theory. In Proceedings of the 10th International Symposium on Software Engineering
for Adaptive and Self-Managing Systems (pp. 71-82). IEEE Press.
[7.] Fuggetta, A. and Di Nitto, E., 2014, May. Software process. In Proceedings of the on Future of
Software Engineering (pp. 1-12). ACM.
[8.] Gray, J. and Rumpe, B., 2018. Software engineering methods in other engineering
disciplines.
[9.] Laplante, P.A., 2017. Requirements engineering for software and systems. Auerbach
Publications.
[10.] Piattini, M. ed., 2016. Green in software engineering. Springer.
[11.] Robillard, M.P., Maalej, W., Walker, R.J. and Zimmermann, T. eds., 2014. Recommendation
systems in software engineering. Springer Science & Business.
[12.] Stanton, N.A., Salmon, P.M., Rafferty, L.A., Walker, G.H., Baber, C. and Jenkins, D.P., 2017.
Human factors methods: a practical guide for engineering and design. CRC Press.
[13.] Stol, K.J. and Fitzgerald, B., 2015, May. A holistic overview of software engineering research
strategies. In Conducting Empirical Studies in Industry (CESI), 2015 IEEE/ACM 3rd International
Workshop on (pp. 47-54). IEEE.
[14.] Tsui, F., Karam, O. and Bernal, B., 2016. Essentials of software engineering. Jones & Bartlett
Learning.

15SOFTWARE ENGINEERING
[15.] Whittle, J., Hutchinson, J. and Rouncefield, M., 2014. The state of practice in model-driven
engineering. IEEE software, 31(3), pp.79-85.
[16.] Wohlin, C. and Aurum, A., 2015. Towards a decision-making structure for selecting a
research design in empirical software engineering. Empirical Software Engineering, 20(6), pp.1427-
1455.