The differences between a scenario and a use case

Posted on April 28, 2015 by Jingyuan Li

Use cases are a technique for capturing the functional requirements of system.
Use cases work by describing the typical interactions between the users of
a system and the system itself, providing a narrative of how a system is used.

Rather than describe use cases head-on, I find it easier to sneak up on them
from behind and start by describing scenarios. A scenario is a sequence
of steps describing an interaction between a system and a user. So if
we have a Web-based on-line store, we might have a Buy and Product scenario that
would say like this:

The customer browses the catalog and adds desired items to the shopping basket.
When the customer wishes to pay, the customer describes the shipping and credit
card information and confirms the sale. The system checks the authorization on
the credit card and confirms the sale both immediately and with a follow-up email.

This scenario is one thing that can happen. However, the credit card authorization
might fail, and this would be a separate scenario. In another case, you may have
a regular customer for whom you don’t need capture the shipping and credit card
information, and this is a third scenario.

All these scenario are different yet similar. The essence of their similarity is that
in all these three scenarios. the user has the same goal: to buy a product. The user
doesn’t always succeed, but the goal remains. This user goal is the key to user cases:
A use case is a set of scenarios tied together by a common user goal (Fowler, 2004).

scenario diagram

http://www.inf.unibz.it/~ryzhikov/HCI/hci_02.pdf

References:

Fowler, M 2004, UML Distilled : A Brief Guide To The Standard Object Modeling Language / Martin Fowler ; [Forewords By Cris Kobryn … [Et Al.]], n.p.: Boston : Addison-Wesley, c2004., University of Southampton Library Catalogue, EBSCOhost, viewed 28 April 2015.

It’s more than Facebook – Online Social Networks with Interesting Features

Posted on April 28, 2015 by Miroslaw Jaroszak

Over the last few years the online world has been dominated by few large social networks whereas there are many more – some targeted at specific communities or completely niche but with unique features. Here, we picked 8 Online Social Networks, both those commonly known and those less popular, but all with some interesting functionalities that could be incorporated into our Small.World project:

About.me – an online identities platform features:

One-page user profiles with short biographies, linked to all other social networks associated with the member.

While About.me works more like a personal website, Small.World takes an advantage of using Facebook & Google+ accounts but it’s a fully operating social network itself.

AsmallWorld – an exclusive travel and social club network, based on small worlds concept. A slight coincidence with our project’s name…

Personalised travel advice.
Members-exclusive events.
Membership on recommendation only, capped at 250,000 users.

Our service also uses travel advice but it will always be given by your trustees. And the membership is not exclusive at all.

Couchsurfing – a hospitality exchange social network.

Private hosts met travellers.
Strongly based on recommendation.
More than trust – in the past there was a credit card and address verification.

A question of trust is taken very seriously by Small.World. Our members recommend places but more importantly they recommend people.

Diaspora – a general purpose, distributed social networking service.

Decentralised (data stored on local servers).
Members can add different aspects of their lives and share certain posts/events/etc. only with people associated with certain aspect (e.g.. job-related posts/events with colleagues

Just like in Diaspora, in Small.World posts are contextual. The main difference is that the context is always geographical, i.e. related to the particular location.

Fotki – a large media sharing social networking website.

Highly customisable layout (skins and manually changed colours).
RSS feeds.

Small.World does use feeds but they are only feeds from your friends or mutual friends of yours. Small.World aims for simplicity and consistency. Users can choose from several colour themes but nothing more as cross-compatibility is the priority.

Foursquare – a search and discovery service for mobile devices.

Short tips on locations.
Search locations in surrounding area by tastes. ‘Tastes’ serve as attributes e.g. for restaurants this would display the ones that are good for karaoke, ice cream, steaks or so. Time of the day would trigger different results, e.g. restaurants serving breakfast in the morning.

Using the similar concept, both tips and “tastes” in Small.World are fuelled by your friends only. We believe that the community can provide you with the best tips, recommendations and other information you need.

Glympse – a mobile platform for tracking people to meet up with.

Real time friends tracking with detailed information.

Glympse is technically not a full-blown social network. Small.World has similar friend tracking built-in as a part of a comprehensive service. Our tracking gives you only the information you need. And it’s more secure – you can track groups of users but they will always be people you really know.

LinkedIn – popular professional, business-oriented network.

Members can see the degree to which they are connected to each other, with common characteristics such as location, skills or school.
Members can see who viewed their profile.

LinkedIn shows interrelations in the sidebar panel. Small.World goes beyond that and displays them right in your friend’s profile and points to everything you have in common.

All the web services described above have some great interesting features but it’s only Small.World that combines some of those ideas using fine-tuned solutions and provides a great integrated user experience.

Welcome and Project Brief

Posted on April 27, 2015 by Neil Amos

Small.World

We are more connected than ever, Social Media has revolutionised how we interact online, Small.World aims to make these connections real.

Imagine you have moved to a new city, the Small.World app will allow you to connect with friends of your friends both online and offline. Making new friends through a virtual introduction, you will share a common interest and crucially already have a friend in common. Our offline networks will become based upon our online connections.

We envision an app which allows you to see which of your friend’s friends are in the same

geographical area and likely to be at the same events or locations. A core function of the Small.World app is the ability to make choices based on the recommendations of your extended network. Reviews and tips left by friends and friends of friends will help you make the best decisions and make the most of your environment.

There will be invitations to offline events based on your interests, friends of friends will also be invited to these events. Our aim is to help connect people by providing the opportunity to meet those people who already share a mutual connection.

Quite simply, we want to make those “small world!” moments happen.

System Requirements

Posted on April 27, 2015 by Miroslaw Jaroszak

In order to determine what is needed from our online social network, we conducted requirements gathering and elicitation which are the vital parts of every software analysis process. The requirements usually refer to what software does (functional) and what are its qualities (non-functional). They usually have their unique IDs, are prioritised and in more detailed approach – have appropriate metrics.

Two tables below present some of the functional and non-functional requirements for Small World. Each one is assigned a priority level indicated by colour scheme.

For full and detailed requirements list, refer to the Full Requirements Document.

Background reading

Pressman, R. (2010). Software engineering. Boston, Mass.: McGraw-Hill.

Sommerville, l. (2011). Software Engineering. 9th ed. London: Pearson Education.

Mockups

Posted on April 27, 2015 by Edmund Baird

These mockups show how Small.World would look on a smartphone, with the Nexus 5 used as an example.

After logging in, the user is taken to the ‘Friends’ tab, where they can see the friends that they are connected to (solid black line), as well as the friends of a friend (dotted black line). By tapping on a profile picture, a user can see the public profile of another user (e.g. interests, location)

The menu is accessed by tapping the button in the top left of the screen. From there a user can edit their profile, giving as much information as they want to, as well as being able to edit the display of the app. Users are also able to filter their friends by location or interest which would be useful for users with large numbers of friends.

The map view shows the location of a user and the location of their friends and friends of a friend within a certain radius. In the settings, the radius can be changed and the user can choose whether to see people or events. Again tapping on a user’s dot will bring up the public profile of another user.

Making Small.World Pay

Posted on April 26, 2015 by Neil Amos

Making Small.World pay

The successful development of Small.World will rely on careful design of the revenue stream. The app is hinges on the content and access to data from as wide a user-base as possible. The efficacy of the application is significantly improved by the quantity of suggestions and level of detail offered about a particular area.

It is crucial that this application is as easy to use and open as possible with minimal barriers to user uptake. The more users, the greater the product and the potential for increased market penetration. As the success of this application relies upon having a wide range of users in as many locations as possible, the subscription approach is considered inappropriate and potentially harmful to the growth of our user-base.

Research suggests that users concerns about targeted advertising rank far behind fears about cyber-bullying, identity theft and government surveillance, indeed only 4% of respondents in a survey cited behavioural advertising as a concern. Effective and appropriate targeting of adverts has been shown to significantly decrease consumer’s irritability with online advertising.

Popular Social Media platforms tend to attract a broad demographic and as such can be attractive to advertisers. The value of Social Media platforms which require a login and sign-up process is in the potential for adverts to be targeted at specific audiences and demographics.

Small.World will be in a position to offer the potential to offer a rich mine of customer preferences and interests to advertisers, as well as location and demographic details about our users.

Small.World’s main selling point to advertisers may be broken down as follows:

-Demographic information (age, gender etc.)

-Location

-Interests

-Interests of Social Group

-Access to contacts and social groupings

-Activity and behavioural data

-Internet usage data (e.g. device preference)

The USP of Small.World to advertisers is that we offer an easy and effective way of targeting real social groups. We may be able to offer an opportunity of targeting people who are known to each other offline with the same online ad experience. This may create interesting opportunities for marketing strategies to harness the potential of the social group and the reinforcing of advertising with a peer group.

Our users will be constantly providing a rich source of data, refining their own interests and social groups creating a powerful tool for very specific advertising opportunities. Users should be empowered to give feedback on ads in an attempt to remove inappropriate advertising. This function will also allow us to feedback to advertisers on the effectiveness of their targeting strategy.

References:
Bachman, K. (2015). Poll: Targeted Advertising Is Not the Bogeyman. AdWeek. [online] Available at: http://www.adweek.com/news/technology/poll-targeted-advertising-not-bogeyman-updated-148649 [Accessed 15 Apr. 2015].

Pan, S. and Yang, H. (2014). Targeted Advertising on Competing Platforms. 1st ed. [ebook] Ohio: Ohio State University, pp.1-36. Available at: http://econ.ohio-state.edu/hyang/Tageted-Ads-Jan14.pdf [Accessed 15 Apr. 2015].

Who Likes What: Social Media By Demographic. (2011). [Blog] KISSmetrics. Available at: https://blog.kissmetrics.com/social-media-by-demographic/ [Accessed 15 Apr. 2015].

REST API

Posted on April 26, 2015 by Jingyuan Li

As Small.World was designed to be relatively simple to integrate into other systems,
a method of communicating with the coordinator was required. A REST API was chosen for this as REST makes use of standard HTTP protocol for sending commands (via the message body)
and requesting information (Masse, 2011), allowing developers to work with a widely used and familiar protocol rather than one tailor made for Small.World. It was decided that commands themselves would be formatted as JavaScript Object Notation (JSON),chosen because it is lightweight and used in many other web services.

Jobs Functionality

The REST API can request a single job (specied by its ID). It can also request a collection of all jobs (or all job IDs) currently in the system (Maximilien et al, 2007). The REST API can request a timestamp indicating the last time that any job was added or deleted(but not modified). There is also a method that returns a collection of all jobs which have been modified since a specified time.The REST API can also call a method to delete a single job, specified by its ID.

Agents Functionality

The REST API can request a single Agent by specifying its ID. It can also request a collection of all Agents currently in the database (not just the currently connected Agents). There is a method which returns a collection of all jobs currently assigned a specified Agent (on any of its cores). There is also a method which allows the REST API to manually delete an Agent from the system. This will force the Agent to disconnect(if it is currently connected), will unassign all of its currently allocated jobs, and will remove the Agent (and all of its cores) from the database. For a specific Agent, the REST API is able to request the number of jobs which are currently allocated to that Agent’s cores, and is able to request a collection including those jobs. It can also request a boolean indicating whether or not the Agent is currently online.

Languages Functionality

The REST API can request a collection of all languages currently supported by Small.World and its Agents. An assumption is made that all Agents support the same languages, since language support is determined by Small.World.

References:

Masse, M. (2011). REST API design rulebook. ” O’Reilly Media, Inc.”.

Maximilien, E. M., Wilkinson, H., Desai, N., & Tai, S. (2007). A domain-specific language for web apis and services mashups (pp. 13-26). Springer Berlin Heidelberg.

Cashing in on success: Advertising or Subscription?

Posted on April 26, 2015 by Neil Amos

Cashing in on success: Advertising or Subscription?

The web has provided many companies with new and lucrative ways of accessing markets and consumers. The history of the web is also littered with examples of failed or over-inflated companies unable to realise the potential of commerce in the internet age.

Perhaps the most obvious evolution in online business models is the move in recent years from subscription models (such as Friends Reunited) towards advertising based revenue models (such as Facebook). The developments in online business models are far from complete, with constant readjustments and innovation in what is still a very nascent market. Youtube has been identified as a service which may in the near future move towards a mixed-model approach, introducing a subscription stream to its business model in part as a response to user objections to advertising.

There are five commonly accepted approaches to monetising web-applications, Paid Apps, In-app Purchase, Virtual Currency, Advertising and subscription models . Each model has its benefits, and of course its weaknesses, the appropriateness of each strategy depends very much on the type of application in question.

Paid Apps are apps that require the user to purchase a version of the application on their device. This may be appropriate for an application or service that is very confident of its product, to the extent that they can place a value on the app and promote it sufficiently to generate an income. In App Purchase is most commonly associated with ‘free’ applications known as ‘freemium apps’ where the is no initial cost, but there are incentives to buy extra features or access to further content within the app. Virtual Currency approaches allow users to buy currency within the app or game that can be used to enhance the user experience. Advertising within applications allows companies to access their consumers within the app. The potential for targeted and specific advertising is appealing to brands and the app is usually free to use. Advertising can be negatively received by users, particularly if it is intrusive or bandwidth hungry. Subscription models incur significant overheads for the developer and can be unpopular with users, however this approach may be appropriate for apps with content that is in high demand (such as popular news or magazine content).

The choice of revenue stream for an application is incredibly important to get right. The type of audience, amount of traffic and and the overheads associated with an application or service all have an impact on which model is appropriate.

References:

Perez, S. (2015). YouTube Confirms Plans For An Ad-Free, Subscription-Based Service. [Blog] techcrunch. Available at: http://techcrunch.com/2015/04/08/youtube-confirms-plans-for-an-ad-free-subscription-based-service/ [Accessed 12 Apr. 2015].

Kanada, P. (2013). Which Can Be Best Mobile App Revenue Models?. [Blog] The App Entrepreneur. Available at: http://theappentrepreneur.com/mobile-app-revenue-models [Accessed 12 Apr. 2015].