Requirements engineering (SAM SAS 4.0)
November 2010
Requirements engineering at SAS Group IT and SAS EB Development: an overview Author(s): Jesper Holgersson
Date: November, 2010 Project: SamMET (SAM SAS 4.0)
Status: Public
Requirements engineering (SAM SAS 4.0)
November 2010
Table of Contents
Introduction Document scope Methodology
Actors of importance SAS Group IT: Responsible for the overall IT systems development at SAS. SAS Group IT is the actor that receives the Stakeholder Request, most often created initially by SAS EB Development SAS EB Development: Responsible for the overall development of SAS EuroBonus, including the creation of Stakeholder Requests which in many cases is based on needs identified from members of the bonus program. SAS EB Development often interacts directly with members of the bonus program regarding feedback and information of e‐ services related to SAS EuroBonus
Parts Part 1: Basic overview of actors at SAS Group IT and SAS EB Development regarding requirements engineering Part 2: User participation and requirements elicitation Part 3: User communication Part 4: How getting users to participate?
Requirements engineering (SAM SAS 4.0)
November 2010
Introduction Document scope This report presents an overview of how requirements regarding customer oriented e‐services at SAS Group IT are elicited and analyzed. The report is based on the book chapter “Using virtual communities in e‐service development: A case study” published in “Business organisations and the collaborative web”. Not included in this document is the elicitation of other requirements than the ones originating from customers and EuroBonus members. Obviously there are many basic internal requirements focusing on increased efficiency to take into account for SAS Group IT as well, such as reduced customer interaction via other media than the Internet, the reduction of manual work etc. The results are presented as follows: Part 1 presents a basic overview of how SAS Group IT and SAS EB Development work with requirements and how key actors are communicating. Part 2 presents in more detail how users are represented in requirements elicitation. Part 3 describes how SAS EB Development communicates with its end users. Finally, part 4 illustrates how SAS EB Development makes the end users to provide developers with correct information which serve as a base for requirements elicitation.
Methodology The report is based on interviews held with key actors from SAS Group IT and SAS EB Development with extensive knowledge about the e‐service development process at SAS Group IT. The key actors are represented in table 1. Table 1: Interview respondents Participants Role
Number of interviews
P1, P2 P3 P4 P5 P6 P7
4 x 2 hours 1 x 2 hours 1 x 2 hours 1 x 2 hours 1 x 2 hours 1 x 2 hours
Senior IT architects Project manager System specialist IT architect Test leader Senior marketing manager
Results from the interviews have been discussed with key actors from SAS Group IT to guarantee accuracy and quality of the material presented in this report. Furthermore, extensive studies of project documentation and previous project reports for SAS Group IT within the research project SamMET have been serving as a source of information.
Requirements engineering (SAM SAS 4.0)
November 2010
Parts Part 1: Basic overview of actors at SAS Group IT and SAS EB Development regarding requirements engineering As described in report “SAS EB Processöversikt” RUP (Rational Unified Process) is used as the general systems development process at SAS Group IT, meaning that more or less all development efforts starts with a Stakeholder Request. The SR is most often initiated by SAS EB Development and it is also this department that handles the outmost communications with end users of e‐services. We will not further describe how the Stakeholder Request is handled during the development process. For further details regarding this issue the project report “SAS EB Processöversikt” is recommended. The end users of the e‐services are most often members of the EuroBonus program resulting in a set of well defined users with a very specific interest, in this case flight travelling and how to earn and spend EuroBonus points. Many EuroBonus members travel a lot and are frequently contributors on Internet forums, such as Facebook and Flyertalk, regarding various aspects of the bonus program and the e‐services related to this. According to SAS EB Development, these members of the bonus program have a very high knowledge about the bonus program as well as its e‐services and are therefore considered to be of high importance for SAS EB Development and SAS Group IT when it comes to development and refinement of e‐services.
Part 2: User participation and requirements elicitation As stated previously, the users of the e‐services provided for the membership program are the members themselves. However, they are, with a few exceptions, only passive users and do not actively take part of the e‐services development. In many cases, requirements are not gathered from a requirements elicitation purpose, but rather as comments and feedback on existing services and needs for new services. These requirements are elicited by tapping into forum discussions, and from analysing customer behavior. Requirements from customer and EuroBonus members are elicited in a number of different ways, such as: ‐
‐
‐ ‐
Large member studies, focusing on appreciation and experience. These studies are made via email or online via the SAS EuroBonus web portal. One sample question is ”what do you think of the possibility to use the membership points for booking hotels?” Directed membership studies outside of the border of the more general ones. These studies are made towards smaller customer segments that use an already implemented service. For example, one upcoming study will concern whether or not the members/users like the new hotel booking service, what they do not like, and so on. Online inquiries directed at selected customer segments concerning different aspects of the membership program. Focus groups, which are only rarely used since SAS EB Development considers it difficult to gain new and useful knowledge this way.”The way you ask the question determines the answer you will get” (quote SAS EB Development). This quote emphasises the difficulties in arranging valuable focus group sessions.
Requirements engineering (SAM SAS 4.0)
November 2010
Studies can consist of tests, as highlighted by one respondent: “We do tests where we have both groups and control groups. These groups get different information, and then we monitor their behavior. These are all real, live tests”. The e‐services are provided via the Internet portal of SAS Group IT. In addition to the inquiries and studies for requirements elicitation, other issues, ideas and problems are identified by tracking member actions on the web pages. This consists of following a logged‐in user in terms of where clicks are made, where they run into problems, and in particular if the users fail in their tasks and log out. If a certain number of users terminate their actions on the same page, this will be subject to review and analysis in order to identify the problems and take corrective action. Because of this tracking, which is stored in the customer database, SAS EB Development knows its users well. Quoting one respondent: “We follow up behavior, for example via customer inquiries and the like. We know our customer segment and know approximately what they want and what they want to do”. It should be noted that the goal of using VCs is not to elicit primarily new requirements, but rather to provide a complementary way of finding requirements in an otherwise highly complex elicitation process.
Part 3: User communication As stated in part one, the EuroBonus program includes a well‐defined set of customers, with – seen from the membership program point of view – a well‐defined interest. Many of these customers travel a lot, and are active in various VCs (Virtual Communities) where the different aspects of the membership are discussed. Quoting one respondent: “With the Internet and the sites, we have access to customers and competitors directly. All information is there if you just look”. According to SAS EB Development, these customers are extremely knowledgeable about the membership program. The extensive and encompassing customer database enables SAS EB Development to easily identify suitable customers in defined spectra. There are, in other words, no problems in identifying the customer segments, since they only have one that is well‐defined, and since the database contains all the information necessary for this task. In cases where customers participate in some form of activity, there is rarely a problem to motivate participation, hence challenges of identifying target groups and users within these target groups as well as getting the users to willingly participate are no problems for SAS EB Development. The reason is that the customers, who generally are on the top levels in the membership program, are genuinely interested by the program and the services associated with it. In summary, SAS EB Development and SAS Group IT communicates with its users in the following ways
Online surveys Threads in virtual communities/discussion forums, such as Flyertalk Dedicated virtual communities/discussions forums, such as Facebook In rare cases SAS EB Development give some customers a phone call
Figure1 displays the various ways in which SAS EB Development communicates with its customers, and the entrance of Internet technology has certainly affected the ways in which communication takes place.
Requirements engineering (SAM SAS 4.0)
November 2010
Internet Commercial organisation
Communities Queries
User/ Customer
Customer Relations Customer service Other
Communicate
IT Development
Communicate
Maintenance
Store data in
Customer database
Communicate
Figure 1: Communication patterns after the introduction of Internet technology and e‐services
Part 4: How getting to users to participate? As mentioned in part 2, end users are with a few exceptions never actively involved in the e‐service development process. The customers seldom come up with new revolutionary ideas but they are very good at providing feedback. Still, there is a desire to include them more: “One would like to include the users more in the development projects, but the external ones are difficult to get to participate. Internal ones are a different matter” (Two of the respondents). However, the fact that the target group members themselves are genuinely interested in the membership program for their own personal reasons is one important point to make. The result is that the customers are more willing to answer questions and contribute with information, but SAS EB Development are nevertheless reluctant to contact these users too often given that they know of their busy schedules, rather than it being the customers who object against participation. Furthermore, SAS Group IT would like to involve the users more, but in specific parts of the development process. Quoting one respondent: “If we are to include users, it will concern usability testing to identify mistakes”. It is often SAS EB Development themselves that monitor different VCs and the like, which means that the customers often do not need to be enticed to participate. They already participate in the fora of their own free will and SAS EB Development only takes part of their opinions and the information they leave without them even noticing that they in fact participate in development. Based on the discussions and threads of interest brought up in the VCs, new features can be developed and improvements to existing e‐services can be made. Furthermore, the large customer database with its huge amount of information about the customers, their behavior, preferences, etc. coupled with tracking user behavior, is a valuable input to e‐services development and enhancement. Both communities and the customer database can be thought of as implicit inclusion of users in the development of e‐services. Users provide input, but not in direct contact. There is, however, one part of the development process where a selected user group participates, as quoted by one respondent: “The interaction designer has used small usability tests for adjustments”. Normally, such tests are only used when the development concerns great changes or large new features. There are also several ideas of how, and for what task, users could become more involved, as illustrated by the quote from one respondent: “…we have had two consultants without specific SAS Group IT knowledge. They thus know how people who work think, but perhaps we should have had more external dialogue tests. Pick out some selected membership program users in such tests would be
Requirements engineering (SAM SAS 4.0)
November 2010
great in an ideal world”. However, there are also ideas on including users earlier in the process, primarily during requirements elicitation as a complement to the VC monitoring and customer database. Quoting one respondent: “What the user needs to be part of is for all the functionality that is natural”.
