A Methodology for User Requirement Assessment

In document Software define radio CRN.pdf (Page 167-177)

Kate Cook

5.3 A Methodology for User Requirement Assessment

A traditional user-centered approach (e.g. ISO 13407 [16]) focuses upon the tasks that the user needs to perform. However, to identify user requirements for software radio systems, a

‘non-existent’ technology intended for use in both business and mass market applications, requires a different approach. These systems are not being developed for one single well-defined user group, carrying out specific tasks, but instead will be used for multiple purposes.

As stated above, these factors provide a number of challenges for the investigation of user requirements for software radio. The overall approach adopted is depicted in Figure 5.2. The first phase of this process encompassed the first three stages (Define the User Group; Scope the Technology; Lead Users), and is described in this section of the chapter. The second phase (Develop Core User Scenarios; Iterate with Operators, System Concepts and End Users) is described in the next section.

Given the problems in eliciting user requirements for future technologies outlined above, a pragmatic approach to requirements capture is required. The user interface design literature addresses requirements at three levels, as shown in Table 5.2:

Figure 5.2 User requirements methodology

† high (the user’s activity)

† medium (what the user is willing to do with the system)

† low (representational and interactive needs of the user interface)

5.3.1 The ‘Lead User’ Concept

As a means of overcoming the difficulties of describing such a complex and ubiquitous tech-nology as SDR to potential end users, the first stage of the user research was based on the Lead User approach [17]. This approach is a marketing technique used for developing concepts for novel products or services. It is based upon the premise that a small group of advanced users (more advanced even than ‘early adopters’) already have needs for new products or technol-ogies that will eventually become more widespread, but it will be months or even years before the bulk of the marketplace encounters these needs. Lead Users may meet these needs with today’s products or technologies by perhaps using them in different ways to that for which they were originally intended. Thus, by identifying Lead Users, much can be learned about the requirements for these new technologies. A Lead User group of advanced cellular and Internet users, who would have some experience, albeit analogously, with the advantages that SDR is purported to offer, is described in Box 1. (A Lead User description was also produced for the network operator.) Initial end user requirements were then elicited directly from groups of users who met these Lead User descriptions, as is described next.

Table 5.2 Levels of end user requirements [2]

Requirement level Capture method Example qualitative


‘‘I want to control how much a call costs’’

Medium: defines what the user is willing to do with the system

Interview, focus groups,

Box 1: Lead SDR end user description

End user description: the multimedia consumer at work and at home: Roams between countries. Relies on the Internet and is used to downloading software to PC or other device. Uses device in buildings, in cars, on public transport, and while walking.

Services of interest would be a mixture of audio, text, and multimedia and are mostly asymmetrical. Interested in high-level personalization of the handset and services.

Already owns a high-tier GSM phone with WAP capability.

5.3.2 Requirements of Lead Users

From this Lead User definition, a number of user (and operator) interest areas were defined to represent the key technical areas that would affect the end user, and key end user-related questions were identified:

† How willing will users be to be involved in the various levels of terminal reconfiguration?

† How will users control the quality of service offered by a network?

† What levels of certification will be offered?

† What levels of security should be offered?

† How long should a mode switch take?

† What quality/cost relationships exist?

† How big should the terminal be?

† How frequently will software be downloaded?

† What control do users want over multimedia quality in a multimode situation?

These questions acted as a guide for the subsequent requirements analysis.

In order to elucidate relevant requirements from users, example activities and mobile communication tasks using future software radio systems needed to be identified. A key

Table 5.3 Initial SDR situation descriptions presented to Lead Users

Situation (i) [mode switch]

‘‘You have traveled to another country for a client meeting. You have just got off the aeroplane and switched on your phone …’’

Situation (ii) [mode switch]

‘‘You return to the UK after your meeting and are walking from a taxi to the train. Whilst still being involved in a call you have the option to move into the coverage of another network …’’

Situation (iii) [intramode adaptation scalable multimedia – broadcast]

‘‘You have to watch some live broadcast video whilst you are on the train. As you move the quality of the video is adjusted as other networks and operators are available in this area.’’

Situation (iv) [scalable multimedia – video call]

‘‘As a result of the video broadcast you need to place a video call to your friend who is supervising work on a building site.’’

Situation (v) [software authentication and secure download]

‘‘Imagine that the person you had a video call with wants you to run a new application. You want to download this information from the Internet …’’

Situation (vi) [personalization through software download – includes bug fixes]

‘‘A few days later you have some free time. You decide to play around with your device. You know that different aspects of the unit can be personalized …’’

Situation (vii) [billing]

‘‘It’s the end of the month and you need to review your costs. You are using your mobile on a variety of different networks and a variety of services and obviously have to pay for your calls …’’

Situation (viii) [battery life]

‘‘You notice that your battery is low. You need to preserve battery life since there is no easy place to charge up.’’

assumption was that current Lead Users will do with SDR to a large extent what they currently do with their advanced technologies now. Thus, by questioning exemplar users from the Lead User group about their current activities, an indication of critical issues for SDR could be gained. Initial, high-level descriptions of typical situations in which SDR might be used (see Table 5.3) were presented to participants during the in-depth interviews and focus groups, and discussion was held about the current and future technical solutions for each one.

5.3.3 Scenario Development and Use Cases

Based on discussions with these Lead Users, these initial descriptions evolved into a much broader range of scenarios that are described below. A number of data collection techniques (questionnaires, interviews, and focus groups) were used to explore the scenarios with exemplar Lead Users, in order to identify high-level requirements. The resulting scenarios and use cases were wide ranging, although constrained to the likely activities of these ‘Lead Users’. The Lead Users discussed their current usage of those technologies the function of which is analogous to what SDR may offer (i.e. Internet, software download, mobile tele-phony, GSM network roaming, and device personalization). A view of how current mobile communications and IT would be enhanced by software radio was presented to the users, who then gave feedback with respect to the use of software radio within this future world. In the focus groups and interviews, examples of the varying multimedia quality that could be enabled by air interface and mode reconfigurability were presented, using scalable video sequences. The sequences were used to represent a broadcast call and a multimedia call, and to facilitate the Lead Users’ understanding of the future capabilities of SDR. Three exem-plar users were defined: a traveling salesman (Peter), a digital film director (Sarah), and a musician (Alex). These three user profiles (see Table 5.4) were drawn from real people within the Lead User group, and gave rise to a number of scenarios and use cases for software radio.

These exemplar lead users are sufficiently different as to generate a range of scenarios and requirements, and were also selected to avoid focusing solely upon the stereotypical business user. These three exemplar users were used as the basis for scenario analysis. Since it is important that scenarios can map onto system level descriptions, each scenario was subse-quently broken down into sub-scenarios (called use cases). Use cases capture particular examples within a scenario and address the most important facets of future SDR, namely:

mobility requirements, download behaviors, communication behaviors, environments, and technical areas. The resulting user scenarios and use cases for each of the three exemplar Lead Users are shown in Table 5.5.

Analysis of all data collected from the questionnaires and during the in-depth interviews and focus groups enabled the identification of a number of initial end user requirements for future software radio. A summary of these requirements is provided in Table 5.6. The detailed analysis, breakdown by user type and business/personal requirements, and individual data sources are provided in Ref. [2].

SoftwareDefinedRadio:Origins,DriversandInternationalPerspectives Table 5.4 Lead User exemplars

Peter Sarah Alex

Profession Sales Director Film Director Musician

Work information

Demos, video/audio players Video player, schedulers, contact list

Table 5.5 SDR user scenarios and use cases [2]

Peter: Work Scenarios

Scenario 1.Providing client confidential product information (brochures, text descriptions, video sequences) to clients from wherever I am.

Use Case P1: High-speed access, whilst mobile, to personal storage on corporate Intranet to get product information.

Use Case P2: Access to information near/on client site.

Use Case P3: Have to leave company office to go to client but download started by wire at desk. Need to continue download in car on way to client.

Scenario 2.Link to client at all times (in home building or in car/home/abroad).

Use Case P4: Waiting for an important client call but driving through area of patchy coverage, must receive call.

Use Case P5: Arrive in foreign airport, must make a voice call to client immediately.

Scenario 3.Accessing contacts and schedule when mobile.

Use Case P6: Need access to central contacts and schedule database when in foreign country (with unknown network).

Use Case P7: Need to download new contacts management application.

Scenario 4.Watching streamed Internet presentation.

Use Case P8: Have to leave desktop machine to travel to meeting by train but must keep watching streamed video presentation at highest quality.

Use Case P9: Have to leave desktop machine to walk around building – must keep watching streamed video. Do not mind if quality degrades.

Peter: Personal Scenario Scenario 5.Organizing family.

Use Case P10: Contact family when car has broken down in the middle of the countryside where there is little/no coverage.

Use Case P11: Send video of where you are to relatives when on holiday.

Sarah: Work Scenarios

Scenario 6.Scheduling appointments.

Use Case S1: Download of new diary application from web site when on train.

Use Case S2: Allow remote clients access to the schedule on Sarah’s device.

Scenario 7.Being contactable wherever she is.

Use Case S3: Must receive streamed video clips at home and quickly.

Use Case S4: Move to new country and have immediate e-mail, fax, and video service.

Scenario 8.Traveling to film locations in other countries.

Use Case S5: Need to view footage filmed so far whilst traveling to location. Highest video quality imperative.

Use Case S6: Need to review scripts and storyboards.

Scenario 9.Attending film premieres.

Use Case S7: Meet with collaborators and exchange clips.

Use Case S8: Load clips of latest films in development and send to remote studio.

Scenario 10.Assessing video clips from different filming locations.

Use Case S9: Clips must be received as soon as possible and viewed.

Use Case S10: Latest version of editing tool is required. The application is professional and therefore very large.

Sarah: Personal Scenario

Scenario 11.Contacting individual friends from anywhere in the world.

Use Case S11: Need to have a video conference with three friends whilst mobile. Want to see faces on device display. Quality is not important.

Alex: Work Scenarios

Scenario 12.Accessing Internet music when mobile anywhere in the world.

Use Case A1: A pop video has to be downloaded and an audio track must be mixed from Internet samples and added. The final product must be sent to a client. All done whilst on tour bus in another country.

Use Case A2: Working on a new theme tune. Need to download a drum line from a server whilst traveling to studio.

Alex: Personal Scenarios

Scenario 13.Contacting individual friends from anywhere in the world (see Scenario 11) Use Case A3: Need to set up a multimedia call. Quality is not important.

Use Case A4: Need to send application to friend. Application is large. Quite important that it is received quickly.

Scenario 14.Listening to real-audio radio stations.

Use Case A5: Listen to radio station whilst mobile.

Use Case A6: Record radio for later use in a track. Highest quality is imperative.

Table 5.6 Initial user requirements, derived from Ref. [2]

High Level Requirements: User Needs

XNeed to work effectively when mobile

XLike to show off the things I own (status)

XLike to reconfigure and personalize devices, e.g. PC, Palm

XLike to have control over devices and add what I want

XOperators can only differentiate on customer support

XSDR must offer more than the Internet

XMay only use the phone for short-term needs

XWant freedom (to move between networks) and flexibility (to choose services)

XNeed communications when traveling

XTechnology must work at all times

XAlways need to be contactable

XNeed to talk to groups

XWant to be able to use mobile device for everything, as with the Internet

XWant to change devices but keep data

XWill choose a network with a good brand image Table 5.5 (continued)

XWant a device that is ‘confidently multifunctional’

XDo not want to be bombarded with information from all the different networks being used

XDo not trust big corporations to send me anything

XDo not have time to be playing with phone

XMay be cynical about new technologies as ‘all marketing’

Medium Level Requirements: System Needs Download XDownload needs to be secure

XShould be protected against viruses

XDevice should not download anything without user’s permission

XWant some control over what information and applications are downloaded

XDevice must be fully operational whilst downloading

XIf special software is required to view downloaded information, this should be downloaded as well

XFixes for bugs should only be downloaded if user has found the bug

XWant to download anything used at work or on PC

XNew software must inter-operate and be compatible with software already on the device

XInstallation of new software must be very quick (no slower than Palm or PC)

XDownload should be as easy as the Palm

XWould want to download and use software on long journeys in car, train, plane

XWould like to share software between colleagues

XDownload of data may be more likely than applications

Air interface XOften want to just switch on and make a call, and then won’t care about the network

XThere must at least be a good signal everywhere and access to the network for all calls

XMust be able to roam in home country

XWant to be able to go to another country and just switch the phone on and use it

XWhen abroad there should be no need to dial an international code to another person who is roaming in the same country

XSet cost constraints as a preference for networks (bearers)

XWant to see cost and service parameters (coverage, functions) of available networks before making a change to a new network

XWant some generic measure of network quality (e.g. coverage or capacity restrictions) to help select networks

XChanges between networks (including LAN to WAN) should be seamless

XWant to change network settings regularly to satisfy current value constraints

XDon’t mind automatic roaming, but the device should be more intelligent and roam on more parameters than signal strength, e.g. cost

XDon’t expect to pay for intra-standard changes (e.g. one GSM network to another)

XWilling to let the device search for the best network in terms of cost and data capacity, user constraints or available incentives

XCould be like an auction where user says they want a service at a certain cost and network operators bid for their business

XUser expects to gain something by playing around with network settings Battery XNeed more detailed information to help make call charging/call decisions

XWant very efficient use of the battery for video

User interface, XWant access to a familiar virtual desktop from wherever user is services, application XUser interface needs to be easy to use, setting parameters must be quick download XCost constraints need to be set as a preference for services

XHappy to let the device shop around for the best services

XWould like the network to send location-specific information e.g. traffic information in the car

XDon’t want to receive lots of ‘spam’ advertising

XWant more than glorified SMS

XMust be a human customer support mechanism since the device will be so complicated

XWant somewhere where user can take device to get help, like a car service center

XWant preferences for e-mail and fax for use abroad

XBusiness calls need a solid reliable line

XAdvertising of services needs to be simple since users make quick decisions to purchase

XInterested in downloading games to pass the time

XPersonal software should be free because it’s just for fun

XWant a quick messaging service to contact friends; should be able to use this anywhere

XThird party should handle the complicated billing: a provider of network providers

Multimedia XWould alter video quality in real time

XIf user knew there was better quality available, they would want it

XFor business video calls the user needs to see subtleties; especially in business, you need to tell when people are lying

XWilling to pay more to make call (business)

XShould be a way to trade quality against services

XUser doesn’t want to play with video quality parameters

XNot concerned about poor quality when talking to family/friends

XWould rather download video and watch later

XWould like to ‘e-mail’ voice and pictures Low Level Requirements: Specific Device Needs

Download XHave different work profiles which can be changed

XIcons for different applications

XDownload applications like applets on the web Table 5.6 (continued)

5.3.4 User Categories

Clear user characteristics relating to possible use of a SDR device emerged during this data collection exercise and two distinct user categories (‘Gadget Crazy’ and ‘Don’t Touch It’) could be defined. These characteristics cut across work and business situations, as well as across gender.

‘Gadget Crazy’:

† interested in technology for its own sake;

† willing to reconfigure devices to match personal needs; particularly network and service selection;

† sees the SDR world as a challenge and a way to demonstrate technology awareness;

† embraces new technologies;

† wants to know why the system has done a certain thing.

‘Don’t Touch It’:

† sees technology as an enabling tool and is therefore interested in using it effectively;

† would like the device to take care of most decisions about services but wants overall control;

Air interface XWarning (e.g. beep) before network transition

XIndication of network range so user is aware of imminent changeover Battery XIndication of how much time left on the battery

XHow much time available for a particular type of call or download User interface and XTerminal display should be high resolution

services XWant to set up preferences for different parts of the world, e.g. fax numbers, e-mail

XWant to access language translation services when abroad

XOn business trip in new city, users want to be presented with information and applications relevant to that place

XPhysical size of device should not be restrictive for entering text

XPhysical size of device should not be restrictive for entering text

In document Software define radio CRN.pdf (Page 167-177)