This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The proposed system is a web based E-Commerce system. E-commerce is the wide range of online business for selling products and services through the internet.Â It is using electronic communications and digital processing technology in Business. These processing includes transaction to create, transform, and redefine relationships for value creation between organizations and individuals. This is a E-commerce website for an organization that would allow for online transaction and processing of software and computer hardware.
The document here presents the various aspects of User modeling and states the expectations of the user and the organization.
One of the most fundamental aim of HCI research is in making more user- friendly and usable and to provide users with the experiences that are tailored according to their particular background knowledge and objectives.
User modeling is a process where the designers or the developers define a user model, i.e. they define the type of users who are going to use this system. The user model normally takes into account the factors such as the cognitive style of the user, the personality of the user and the amount of reistance that the user puts when he wants to adapt to the change.
User modeling is normally done so that when a system is being tested for its interface in the absence of actual user evaluators the desigers can normally get a generic idea about how the system should react to a specific action by a particular user.
For our system we will take into account the following type of users:
The frequent buyer
The frequent visitor
The Frequent buyer
This user is a frequent buyer, he may or may not be a frequent visitor.
He is normally a more focused person.
He is experienced in online trading.
The Frequent Visitor
He is not a person who is always interested in buying a product.
He may know about the online trading system but not necessarily about the website.
He may or may not be computer and internet savvy.
He is not accustomed to an E-Commerce website.
The frequent buyer
Notes on characteristic
Feature in application
He is a buyer
Customization in search.
Frequency of use
Better options for system.
He is well versed with the system
focused on navigation
Could help in direct link based on his previous purchase.
Very particular and Focused
Detailed specifics of the product required.
Detailed documentation is needed.
Have good communication skills.
Use of short sentences could help.
Technical writing is required.
The frequent visitor
Notes on characteristic
Feature in application
Ease of use
Frequency of use
May or may not purchase.
Must be made to make a purchase
He may or may not be internet savvy
Some advanced features possible
Could use direct links.
He is not a very specific buyer
He would require a lot of information on products
Comprehensive documentation of products would help.
Good reading and writing skills assumed incl. preliminary knowledge of technical jargons.
Use of short sentences could help.
Test interface language level and style by a technical person could help.
The above two user models have been considered by taking into account various aspects like, for example,
The Frequent Buyer was considered by taking into account how many times/frequency of purchase that he does, whereas the Frequent Visitor was classified by taking into to account the number of times the user visits for various reasons, but does not necessarily make any purchases.
Requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or an modified project, taking account of all the possibly conflicting or parallel requirements of the various parties that are involved, such as the end users of the system.
Loucopoulos and Karakostas,1995 have stated this process of Requirement Capture as:
Requirements engineering deals with the activities which attempt to understand the exact needs of the users of a software intensive system and to translate the needs into precise and unambiguous statements which will subsequently be used in the development of the system.
Britton and Doake, have stated that, it has been seen that errors in requirements capture account to around approx. 50% of the complete cost of debugging the developed system. The problem that has always had an profound influence in this section is that there is no particular template that can be followed.
In general the essence of requirement capture is something of the sort , requirements are somewhere out there in the wild, waiting to be captured. It has also had a lot of divisions of the term, in the following references.
1)Requirement Elicitation : states that requirements should be chalked out by talking to the users.
2)Requirement Specification : states on the importance of emphasizing the requirements themselves.
3)Requirement Engineering : this is a more tricky one, it states that requirements are developed or engineered during the development process.
Systematic Requirement analysis is many a times also known as Requirements Engineering. It can be considered as a tool to deciding the goals, functions and constraints that are liable on the hardware.
When doing requirement capture the following three points are considered, viz.
Business Requirements - More abstract objectives of the project
User Requirements - Tasks available to the end user
Functional Requirements - Behavior that the software must exhibit.
While developing and designing an E-Commerce systems, a lot of minor details are needed to be considered and have to be addressed. They actually affect the popularity of system and are the deciding factor in the success or the failure of the system.
When doing a requirement capture for any system it is not a trivial job. While designing a E-comm. Website a lot emphasis needs to be given to the audience to which the system is going to cater for. Since a web application/site is used by a number of user types it is necessary that these things be considered and the system be developed for the users.
Requirement capturing is the process of understanding the clients' needs and the user needs. It will be done by using the documents that are gathered from the client and from the user. These documents are mostly useful while developing the system.
Requirement capturing for an E-commerce website plays a vital role in the development. The developer should gather information from the client site clearly to give a possible solution to them.
By Frank Maddix(1990), this method assists in defining the semantics and the syntactic functionalities of the system. Task analysis is commonly used so that an existing system is evaluated. This helps in better understanding of the purpose of what the users are doing and the methods in which they are going about doing it? (Preece et al, 2002: 231). So a task analysis is done before the system is developed with users considering an existing system. This makes it possible to avoid any drawbacks of the existing system to be carried forward to the newer system.
There are various models that are used to do task analysis. The two most widely accepted models are:
HTA (Hierarchical Task Analysis)
GOMS (Goals, Operations, Methods and Selection rules)
Requirement capturing are done in two ways
Functional requirement capturing
Non Functional requirement capturing
Functional requirement capturing:
It considers the functions that are implemented in the webpage that is going to develop. These requirements should be document by the developer. The functional requirements let the system developers decide and draw a thin line between the Essential Features of the system and the Luxuries of the system that are "good to have, but not necessary". They allow in the deciding of the functions that the website is expected to perform
In an E-commerce website we should consider the following functions
New user registration and logging into our system
Twitter should be implemented to get track about the news from the company
Shopping cart system
Using secure system for safety money transactions
Help option to help the user in any manner.
Signup for special & promotion offers
Maintain purchase history
Give an option to compare different items.
Non-Functional requirement capturing:
It considers the basic requirements to run the developed application system. It will not affect the internal functions in the website but without the basic requirements the application cannot able to run in a computer machine. As a rule these requirements should be defined as precisely and to the point as much as possible. Often, this is done by quantifying them. Where ever possible, these should provide specific quantities of measurements that the software must meet.
The followings are some non -functional requirements
A computer system must need to use the website
Minimum of 512MB RAM with any windows operation system or MAC or linux are must
The user's computer can able to connect to internet to reach our website.
The user must have surfing software to view the website
The user should have the basic product knowledge that he going to buy in the wesite.
On the organizations perspective it should have the following
Integration with financial software.
Selecting of products.
Ease of maintenance.
Why do you need this website?
Will help the org to enter unknown markets without taking too much risk
Will help in cut on costs of SCM.
Will give a higher customer base.
Will be able to generate higher revenue.
What does the website do?
The website will help in selling of Computer peripherals and Software.
Will maintain a customer data base.
Will help in future customer(User) modelling.
Will allow for a prediction of trends of purchase.
Who are the stakeholders (i.e. who has an interest in the website)
The organization and its partners
Usage and Task Analysis
Any Activity or piece of work that has to be done and which in turn is a part of a larger job at hand, is known as a Task.
Generally speaking all the systems that need to be developed are done so by, First, drawing models of the proposed system. These models then help in developing of the working prototype of the system.
Task analysis helps in designing the syntactic and the semantics aspects of the way the system is going to function. On the whole, task analysis is generally used so that an existing situation is investigated. Task analysis is basically used to better understand the underlying purpose of what activity is the audience doing and how are they doing it. While developing a new system a task analysis is done while considering an existing system with users. The results given by these analyses are used as an basis for development of the new system. This makes it possible to create a new system while avoiding the drawbacks of the existing system. There are various models that are used to do task analysis
We will be using the HTA method for doing the Task analysis.
Working of HTA
(Preece et al, 2002: 231)
This method involves breaking a main task into smaller tasks and keep on dividing it till an atomic task is encountered.
Once that is done they are then grouped together to form a cumulative task that can be executed in a more efficient manner.
The method depends more on physical and observable actions that are to be performed.
The task analysis that was done for one of the functions in the system:
Purchase a Product
User wants to search for a product.
The user will try and do a manual search for a Product.
User has two options, 1) Manually locate the product, or 2) Use the search box.
Once the product is found he will pay for it.
Sub Task 1:
Searching fo a product
User would use the "Search box".
The user will be given a list of all the possible products that he has searched for.
User will then select the product.
Sub Task 2:
Deciding the Payment method.
Product is found.
User wishes to buy it
He checks the options that are available for him to make the payment.
if it is possible for him to make a payment using the options he will buy the product.
The following story board is done in accordance to one of the many functionalities that will be provided by the system.
The scenario describes an instance of Searching for a product and purchasing it.
Home Page of the Proposed System
Search for a product
Selection and Justification of Heuristic Evaluation
Evaluation is a systematic determination of merit. HCI is not a technology, rather a science that enables a more friendly interaction with technology. Evaluation is one of the main pillars that supports HCI. One of the most popular techniques of the usability inspection methods is Heuristic evaluation. It is a step-by-step inspection of the designed user interface for its usability. Its goal is to detect the problems in usability of the design. This is done because then it can be looked as to be a part of an iterative design process. The process involves examining the interface and then verifies its conformity with recognized usability values.
Nielsen (1995)states that, generally thinking it is difficult for a single person to do this process. So it is seen as a practice that this activity is carried out by a group of people who are sitting together with a set of heuristics, and the system with them.
They are not restricted or guided by any other mean, than by the system itself. It is then taken into account all the flaws that they have been able to find out. These flaws are then rated according to their severity. On the basis of their severity, they are treated for a solution. It is very important that the system be evaluated by a variety of users. The more variety of users that are testing the system, the more variety of errors will be produced.
The diagram above states the relation between the evaluators and their evaluation.
Using the Heuristics On the website/project:
Plan Your Evaluation
Develop a set of tasks and ask your evaluators to carry them out.
Provide evaluators with the goals of the system, and allow them to develop their own tasks
Ask evaluators to assess your dialogue elements.
Choose your Evaluators
Those with experience - if you can find 5 evaluators who are experts in software ergonomics, and in the field in which the software is applied, a well-planned evaluation program will typically find 81%-90% of usability problems with your interface
Those without experience - if you don't have 5 free experts at your fingertips, don't worry. A student with no knowledge of software ergonomics will find 22% to 29% of usability problems.
If we follow the diagram that has been mentioned above we will see that the more number of Evaluators does not necessarily mean the better evaluation. It has been seen that beyond a certain number of evaluators the the law of diminishing returns holds true.
Evaluation can be carried out using 2 different techniques.
1) Analytic evaluation: The pen and paper method, of evaluation of tasks and goals.
2) Empirical Method: This method does a analysis of the user performance in relation to the proposed system.
For this documentation we will consider the Empirical Method of Heuristics Evalutaion.
The following heuristics are the ones that I thought would be sufficient for analysis of the website.
Aesthetic and minimalist design
The system should have a minimalist design approach as the user should not be overwhelmed by the contents of the system. It is also necessary for the system to have Aesthetic design standards as this happens to be a site where the user must spen a lot of time so that it becomes profitable for the org. so the site has to be designed keeping in mind the two factors.
Recognition rather than recall
The user should not be considered to remember the steps that he has just performed. He should be given the ability by the system that allows him to recognize where he is and where he should go in case of backtracking.
Efficiency of the User:
This is the part that makes sure that the utility and the productivity of the user does not go down.
The user should be visibly able to navigate through the system, and if need be he should be allowed to do an "Emergency Exit".
Trust and Credibility
This will check if the system is trust worthy and credible.
It is better to prevent a failure than to try and recover off it.
Help and documentation:
The user should be provided with all the information in the using of the system.
0 No usability problem
1 Cosmetic problem; fix only if extra time is available
2 Minor usability problem; give a low priority to fixing problem
3 Major usability problem; give a high priority to fixing problem
4 Catastrophic; fix before product is released
If you would consider the above heuristics and compare it with the system in development then it would ensure that the system will be a "User Expected" system.
The above mentioned rules are more than sufficient to actually define the usability of the system. If need be the other rules from Nielson can also be considered.
The document above shows the various aspects that need to be coverd and have an influence in the designing process of any system.
All the aspects coverd in this system go hand in hand and are important in developing a system that is tailor made to suite the customer's needs.
These steps show that Designing makes a large impact and plays a fair bit of role in making a system successful.