Creating Valuable Products

(1)

Lund 2008-12-01

Master Thesis

Creating Valuable Products

- A Case Study in Market-Driven Requirements Engineering

and Release Planning

Lund University

Faculty of Engineering, LTH

Department of Computer Science

Authors: Rickard Nilsson Gustav Olsson

Supervisors: Björn Regnell Lund University,

Faculty of engineering, LTH Department of Computer Science Andreas Pettersson Case company contact

(2)

(3)

Preface

This master thesis was conducted at a case company in collaboration with the Department of Computer Science at the Faculty of Engineering, LTH, at Lunds University during a period of seven months in 2008.

Even though it some times was a challenging period, our memories from this time will always reflect the response and encouragement given from personnel at the case company. Together with the support we have gotten from our supervisors, friends, and families. This has made it to a constructive time.

We would there for like to extend our gratitude to the following: Björn Regnell and Andreas Pettersson for being our supervisors; Rickard Berntsson Svensson for evaluating our model; Ola Nilsson, Cajsa Moberg, and Jenny Nilsson for help with proof-reading and valuable comments; the people at the case company for providing input; and last but not least, our families for the never ending support and encouragement.

(4)

(5)

Abstract

It is increasingly common that software development is aimed at a market rather than at a specific customer. When a company adapts their development process to the new situation it is often challenging to turn the requirements engineering and release planning market-driven. The case company has identified this challenge, and this thesis is a part of the conversion process; moving from a strong technology-driven process towards a more market-driven one. The thesis goal is to find the most challenging activities that the case company faces and to provide a guide for how to make the transformation as smooth as possible; gaining efficiency and solving issues in the existing requirements engineering process.

The case company develops a unique state of the art technology, both software and hardware. The focus lies on producing enterprise solutions, and licensing core technology to other developers.

This thesis uses a mapping approach with interviews and document studies to identify how the current requirement engineering process works. The identified issues in the current process are addressed using the knowledge gained from a thorough literature study.

The result of the thesis is a process model, describing the requirement engineering activities and the inputs that are needed. Much attention is given to creating a complete requirements documentation with high traceability and customer focus. The prioritisation activity is improved and given more valuable decision support by analysing dependencies, stakeholders, and market segments. Validation is improved with more market-driven aspects by giving the end user value more attention. Along with the process model a step-by-step implementation guide is provided.

Evaluation of the process model was done both internally in the case company, and externally by a requirements engineering researcher. The purpose was to ensure that the process model fits the case company, and holds high standard from an academic viewpoint.

As the thesis was finished, positive results could already be observed in the process at the case company, indicating that the process model indeed is successful.

(6)

(7)

Table of figures

Fig 1: Requirement types and their effects on customer satisfaction ... 14

Fig 2: Areas of effectiveness for different elicitation methods ... 15

Fig 3: Result of AHP visualised ... 19

Fig 4: A binary search three ... 19

Fig 5: The McCall and Matsumoto validation list ... 20

Fig 6: Visualisation of market segment analysis ... 24

Fig 7: Visualisation of gap analysis ... 26

Fig 8: Communication flow ... 31

Fig 9: Requirement specification ... 32

Fig 10: Improved product process flow ... 37

Fig 11: Normal and special case of dependency flow in the steering documents ... 38

Fig 12: Improved RE-process flow ... 41

Fig 13: Requirement chains in work-up using RAM ... 44

Fig 14: Requirement attributes ... 45

Fig 15: State-machine for requirement status ... 46

Fig 16: Description of abstraction levels ... 47

Fig 17: Summation of the improved process model ... 50

Fig 18: Summation of challenges, addressing, and expected effects ... 54

(10)

(11)

1 Introduction

This chapter gives an overview of the subject and the issues this thesis consider. It starts out with a short introduction to the importance of requirements engineering (RE) and release planning (RP) in the context of market-driven product development. This is followed by a description of the topical problems and a statement of the scope for this thesis. Finally, a presentation of the case company is made before the chapter is completed with an outline of the thesis.

1.1 Theoretical background

–

Setting the scene

The classic product development situation in the software- and hardware industry begins with an analysis phase where a requirements specification document is elaborated. The document acts as a starting-point and base for the development. It is during this phase RE is used to elaborate good requirements. Once the requirements are accepted, requirements management (RM), a part of RE, is used for handling them and keeping them up to date and organised.

When the product is developed for one specific customer, referred to as a bespoke situation or a developer-to-customer relationship, the requirements specification document is often part of a contract between the two parties. In this type of development the RE process is assumed to generate well specified requirements that do not change much throughout the development process. It also assumes that a customer is available throughout the development process and takes active part in the RE process. This ensures that the right product is developed [1]. For this development situation there are plenty of defined methods and practices that are relatively easy to introduce [1]. These handle the problem of generating a requirement specification that is unambiguous, testable, traceable and easy to understand, and ultimately to develop a successful product that solves the problems that it is meant to.

The current trend among companies is to shift focus from bespoke product development to a market-driven requirements engineering (MDRE) process with a developer-to-market relationship [4]. An implication of this is that there is no single customer to communicate and validate requirements with. Instead there is a steady stream of requirements from the market and the need to find the right requirements for each product release is thus more important. The number of customers also implies that the product development costs, as well as product revenues, can not be linked to one specific customer but a market comprised of any number of potential buyers. This makes analysis of the market and product portfolio more complex and more important [7].

The market-driven situation demands different activities and processes compared to the bespoke model. Even though the two approaches need to solve many similar issues, they act on different arenas with different complications. In the market-driven approach the decision of when to release the product is more important, as it will affect its success in the competition with other products. The release date in combination with available development recourses dictates how many features that can be included in the release. This leads to a situation where it has to be to decided which features that should be included in the next release and which that would fit better in late ones. This process is called RP and is a complex task to solve [12]. To make a product as profitable as possible or even profitable at all, the outcome of RP has to be a choice of the right product, with the right features, for the right release date, and focused on the right market segment. Many factors affect this process, e.g. available resources, market expectations, competitors’ actions, which make it complex [7]. Furthermore the business concept needs to be considered. A successful solution is more than just the product; it includes e.g. support and maintenance, which needs to be included throughout the development process.

Due to the different conditions the market-driven perspective demands an adaptation of the requirements engineering from the bespoke context, as well as a well-functioning RP process. This also implies that different and new analyses and key documents might be needed as input to these processes.

1.2 Problem Description

RE is a young science, and an overall understanding throughout a company cannot be assumed in the general case. This is especially true when it comes to market-driven requirements

(12)

engineering [7]. Many companies today act in a market-driven environment, but uses bespoke methods for RE, which is not suited for the situation at hand, and creates an apprehension that RE is a not well-functioning and cumbersome process.

As companies change their requirement process from the bespoke to the market-driven approach and create or refine their RP process they face a great challenge. To succeed in a market-driven environment, they need to find out which product the market wants and then develop exactly that product. To be able to do so, many new ways of thinking needs to be introduced, along with different kinds of market analyses. This is a difficult but vital undertaking [12]. The collaboration between different sections of the company is an important aspect, as well as how this is to support the activities for a RE and RP [2].

The process of changing the process within the company is in itself important for the success of a shift to the market-driven approach. It needs to be a gradual implementation that allows for new routines to be created and employees to learn and find confidence in the new methods and processes.

At the case company, see 1.5, a gradual change from a bespoke to a market-driven development process has begun, focused on a few products, but without a defined goal or way to include the RE and RP processes. A goal for how to work with these questions has to be stated, along with an implementation strategy to get there. This thesis discusses these problems and concludes a step by step guide to a fully developed requirements process with RP for the market-driven case, focused at the case company.

As part of the problem description, the case company posed a couple of questions, acknowledging their view of the problem:

• How and where should the requirements be documented so that they are kept alive throughout the product lifecycle?

• Who should be responsible for keeping the requirements alive and what does that responsibility imply?

• Who should be responsible for keeping the RM process alive and what does that responsibility imply?

• Which RP activities should the company engage in for a successful RP, and who should be involved in them?

• Do all stakeholders need to be represented during the RP activities?

• How and on which level is it desirable for the requirements to be defined for company to be able to utilize them in RP?

1.3 Aims and Objectives

The purpose of this thesis is to design a process model for RE and RP that can be used as a goal for improvements of these processes at the case company, presented both as full-fledged process and an implementation strategy. The process model is intended to be useful also in a general case, since literature studies [2, 4, 12, 16] show that many other companies are in similar situations, i.e. small software focused companies shifting from bespoke to market-driven development.

The purpose is to push the process to be more market-driven, but not all the way to a completely market-driven situation. The products which are to be developed using the process are foremost enterprise solutions, larger systems with a market-driven core technology and partly customised layers. There are still products in the Company that will stay in bespoke development.

(13)

1.3.1 Research Questions

In order to operationalise the goal formulated above, four more precise research questions have been pinned down.

• How are RM and RP conducted today at the case company? [Q1, Current situation]

• Which areas of the current RM and RP process should be considered for change in the case company case? [Q2, Improvement areas]

• How should RM and RP be conducted for maximum efficiency at the case company in the shift from bespoke to market-driven development? [Q3, Solution design]

• Which effects could be expected with an improved RM and RP process at the case company? [Q4, Solution evaluation]

1.4 Limitations of scope

Since different projects in the case company are aimed at different market segments in varying size and areas of business, it is not a good idea to apply the exact same RE and RP procedures to all projects. Hence, a consideration of which methods that would be most suitable needs to be done for each specific project. Nevertheless, a main process that all projects can use and modify creates structure and efficiency by being familiar and strong. This work focuses on product management in a department that develops both end-user products and platforms used in partners’ products. The process model recommended is designed to fit as many projects as possible within that department, but is not necessarily applicable to any random project in the company without modifications.

Another limitation is that this process does not include how the implementation process or test should be conducted. Also, how business strategies are analysed and selected will not be included. Despite of this, many suggestions given in the final result affects these areas both in order to create better input to RE and RP, and as a result of changes in those processes.

In product development it is important to consider the entire business offer, especially in a market-driven situation producing enterprise solutions. This thesis touches a few of these issues, however, the focus lies on preparations for development, ergo functional and non-functional requirement on the product.

1.5 Case company background

–

“

The Company

”

The work covered in this report was conducted at a case company, from here on referred to as “the Company”, that in its size and business area well reflects the situation of many other high-tech focused companies today.

The Company is technology focused and has historically produced platforms used by partners and customers to develop their own end-user products, both in the software and in the hardware domain. Lately the Company has started to develop their own end-user products, or packaged products, which are to be more market-driven than the earlier development. The Company’s classic products have since some time been partly directed to a marketplace, rather than to singled out specific customers, but the technological push has been stronger than the market-driven aspects. This orientation is the early consequence of a decision to gradually change focus from bespoke to market-driven development, especially for certain products. The Company’s product portfolio places the Company in a situation of mixed market-driven requirements engineering, i.e. products are aimed to a market with a lucid number of distinct costumers [3]. This is an important aspect since it dictates which RE methods that is applicable.

The product portfolio consists of development-tools, enterprise solutions, and a few customer products. In this report the end user refers to the last user in the development chain of a certain product, i.e. a enterprise is end user for some products; the person holding the handset is end user for other products, but should also be considered in the enterprise case. When a product is to be developed further in another company, that company are users of the technology and recognised for that, but they are not the end user.

(14)

The Company was founded in the mid 1990’s, has about 130 staff members and an annual turnover of about 170 million SEK. The head office is located in Lund (Sweden) but branch offices exist in both Japan and USA.

1.5.1 Outline of the Thesis

This thesis is divided into 9 chapters covering everything from background and methodology to analyses and results. For further information, there are also several appendixes attached to the thesis.

The chapters and appendixes are:

1. Introduction - Contains the problem description, aims and objectives and limitation. This chapter also includes the case company background.

2. Methodology - Discusses how information gathering, and evaluation of results were conducted.

3. Theoretical studies - Explains the academic background of RE and RP. Also discusses different methods within the areas and other market-driven approaches.

4. Analyses and results - Describes the present situation at the Company and summarises the challenges found.

5. Challenges addressed - The main part of our contribution. Describes the improved requirement and RP process and how it is relevant to the findings described in chapter 4.

6. Evaluation – Covers how the thesis was evaluated. Describes the feedback received and which impact it had.

7. Conclusions - The results are summarised together with the evaluations and compared to the objectives of the thesis. Suggestions for further work are listed.

8. References.

9. Appendix – Templates and guidelines for the improved model.

1.6 Abbreviations and concept words

Beneath is a list of abbreviations used in the thesis, together with a list of subject area specific words and expressions.

AHP - Analytic Hierarchy Process API - Application Program Interface

BESMART - BESpoke to MARkeT-driven Requirements Engineering

CR - Change Request

CRUD - Create, Read, Update and Delete

DPRS - Detailed Product Requirement Specification IEEE - Institute of Electrical and Electronics Engineers IRS - Implementation Requirement Specification MDRE - Market-Driven Requirements Engineering

MDREPM - Market-Driven Requirements Engineering Process Model MRS - Market Requirement Specification

PR - Problem Reports

PRS - Product Requirement Specification RAM - Requirement Abstraction Model R&D - Research and development

(15)

RE - Requirements Engineering

RM - Requirement Management

RP - Release Planning

SDK - Software Development Kit

XP - Extreme Programming

Baseline - When all documents are synchronised to a current valid version. Bespoke - Custom made or contract driven. Referring to development for one

or just a few specific customer.

Elicitation - To bring or draw out requirements into the light. Used in RE to accentuate that it is more work to it than just gathering them. Market Segment - A subgroup of people or organizations sharing one or more

characteristics that cause them to have similar product needs. Stakeholders - A person, group, organization, or system who affects or can be

affected by an organization's actions. Validation - Ensuring that you built the right product. Verification - Ensuring that you built the product right.

Return of investment - A measurement of the returned value gained from a certain investment, e.g. investing resources in development and gaining a product of some value.

(16)

(17)

2 Methodology

The thesis consists of three major parts. First a literature study was conducted to elaborate a view of the current findings in academia and research on the subject. This was followed by an investigation of how the Company operates, and a comparison with good practices found in the literature study. The final step was to formulate an improvement of the RE and RP process and then evaluate the improved process.

For the investigative part of the thesis a mapping approach combined with a case study was chosen, motivated by the fact that the thesis suggests improvements to an existing process and workflow. Methods used were document study, semi structured interviews with qualitative analysis, and a quantitative study using questionnaires [9]. Company representatives validated the findings.

In line with the action research approach [9] findings from the investigation was compared with the results from the literature study, which produced suggestions for process improvement. Feasibility and possible penetrating power of the suggestions was evaluated through meetings with RE and RP personnel. Evaluation by pilot project was not possible, mainly due to time constraints.

2.1 Literature study

Initially, a few sources provided by the thesis supervisors were used. These made out a starting point for the literature study, which were expanded by a thorough search for articles and publication concerning the topic. Authors of articles perceived as useful in the sense of discussing the subject were pursued, tracing references backwards through the publications. This rendered a large amount of articles, books, and papers. These were kept sorted in two categories: useful, and maybe useful later. From this stack of references, the theoretical data was extracted.

2.2 Current situation at the case company

To be able to give suggestions of improvements tailored for the Company and for these to be well received, a good understanding of how the Company works today is crucial. Therefore the Company and its current workflow were studied. The result of this is covered in chapter 4.

2.2.1 Document studies (archive analysis)

To se how requirements presently are documented, requirements from nine different projects were studied. The starting point was to find reappearing phenomenon divergent from, or in line with good RE practices according to Lauesen [1] and Karlsson [7]. As more knowledge were gained on the current RE process, as a result of interviews, other documents became interesting as well. Other documents studied were Project Directives, Road Maps, Work Flows and Organisational Charts. These were studied to gain knowledge about work and requirements flow, organisational structure and how requirements are elicited, planned and released in a product.

2.2.2 Semi structured interviews (case study)

Eleven interviews where conducted with key personnel to create an understanding of the organization and a common ground for all involved in the process. The interviews where held as semi-structured interviews [9] to allow the interviewee freedom in his or her presentation and explanation of the organization. The key personnel where selected in the area of where the results of this thesis are to be implemented. The intension was to create a diversification in knowledge and approach among the interviewees, covering the flow from customer to sales, marketing, product management and project management.

The selected personnel are positioned as Director of Software Development Program, Product Manager, Project Manager, Project Manager for large projects, Sales, Marketing, Support, Software Architect and Key Account Manager.

(18)

The stated goals with the interviews were to:

• Realise a description of the company structure.

• Realise a description of the decision flow that leads to a finished product.

• See how requirement documents are used and managed in the process.

• See how road maps and RP are used and managed in the process.

• Find the main problems employees see in the RE and RP process today.

• Find the employees context in the process.

The interviews were more and more guided towards the actual RE and RP as more knowledge about the organisational structure was gained. Together, the interviews gave us a good understanding of the RE and RP process used today and what challenges that the involved personsface.

2.2.3 Qualitative analysis

In the first part of the interviews, focused on RE and organisational structure, records were taken in the form of handwritten notes. The notes were complemented with conclusions made after each interview.

In the second part of interviews, focusing on RP and market-driven aspects, interviews was audio recorded. The recordings were semi-transcribed and discussed to extract the essence of the data.

After each interview part was completed the notes and conclusions from that part were summarised into a list of challenging tasks and ideas for process changes and activities identified as missing or subject to change. These lists were the benchmark for much of the results described in chapter 4 and 5, and used to prioritise which areas the thesis was to focus on during the development of process suggestions.

2.2.4 Quantitative study using questionnaires

Using the findings and conclusions from the document study and the qualitative analysis as basis, a questionnaire were created to collect quantitative data regarding the overall apprehension about the RE process. Since the respondents have different knowledge of RE and are likely to have strong opinions on different parts of the process, the results were expected to be biased to a small amount. With this in mind, the results were interpreted as an image of how the RE process is perceived by different roles in the company.

To ensure that the questionnaire would be interpreted correctly by the participants in the survey, it was developed in 4 steps. Each step included a review and a test person giving feedback on how the questions were interpreted. A total of 36 questionnaires were handed out to employees that are in contact with requirements in some way, hence, personal working with administration, salaries, HR, and legal issues were not addressed.

The questionnaire data was put into an excel document and summarized to a few different views: development, sales, product management, project management and an over all view of the company. These views were a source used as input to the description of the current situation and challenges at hand, described in chapter 4.

2.2.5 Observations

During the work with this thesis, our workstations were placed in the middle of both sales and marketing. Because of this, many tasks and discussions in those departments where continually observed [9]. We also attended meetings regarding process improvements. Both of these gave knowledge and know-how on the current process, as well as how different departments want the process to work. Much information was also gathered informally, e.g. during coffee breaks, leading to unfiltered information including more personal thoughts and suggestions.

(19)

2.3 Evaluation

To ensure that the improved process model is usable for the Company, the model was validated and refined before finalization. The evaluation was conducted both internally and externally, which is described beneath. Chapter 6 covers the outcome of the evaluation.

2.3.1 Internal Evaluation

The internal evaluation was conducted in three stages, each aimed at different areas. The first was conducted informally at a process improvement meeting. There the first suggestions concerning RE and RAM where discussed. The purpose was both to validate the findings and to find ways for improvements. As a result of this meeting, it was decided to plan and conduct a workshop covering these areas of problems, se section 2.3.2.

The second internal evaluation was conducted in connection to the workshop. The attendees were both before and after the workshop session asked to answer a few questions. These focused on their knowledge in RE, how they worked with it today, and if they found the process used in the workshop useful and usable for the Company.

The third and most thorough internal evaluation was conducted when the first version of the improved process model was finished. Representatives from product management and sales were given the model together with the identified challenges facing the Company. Their task was to validate the report regarding the following statements:

• The identified challenges cover the actual challenges at hand without missing any significant areas.

• The organizational structure and workflows are described correctly.

• The suggested improvements fit the organization and address the most important challenges.

The evaluators synchronised their comments, and the feedback was then communicated to us trough a meeting with the Company contact.

2.3.2 Workshop

A workshop [9] was conducted with the purpose to evaluate how well some of our suggestions would fit the organization. It was also an opportunity to educate key personnel within RE, and to let the ideas for the improved process grow on the organisation, so that when applied it would be more easily accepted.

The personnel present at the workshop were all involved in process improvements within the Company and had received a draft of the workshop setup ahead of time. This was sent out in order to let the attendees prepare for the workshop to maximise the outcome.

The workshop was divided into two parts, the first consisted of an introduction on the methods used later on, and also a discussion on RE in general. The second part consisted of practical use of the methods, where all attendees contributed. The main focus of the workshop was elicitation, RAM [6] and prioritisation, and to evaluate whether these methods would be a suitable model to fit into the improved process.

2.3.3 External Evaluation

External evaluation was done to get an academic viewpoint. It was conducted by Rickard Berntsson Svensson, a PhD student in RE at the Department of Computer Science at Lund University Faculty of Engineering. Berntsson was given the first version of the model, together with all research findings, methodology and analyses described in this thesis. Feedback was received via e-mail.

2.3.4 Response to validation

In order to improve the report in line with the feedback, but without blindly following any comment, an internal discussion was held to reflect over the comments before changes were made. The changes were then discussed with the thesis supervisor to assure that the improvements in fact were improvements. The result of the evaluation is described in chapter 6.

(20)

(21)

3 Theoretical studies

This chapter contains an overview of research findings on the subject, good practices in RE and RP, and is the result of a substantial literature study. These findings are used to draw conclusions from current procedures in the Company and to find a model that really pushes the Company’s RE and RP processes forward.

3.1 Requirements engineering

The purpose of a requirement process is to define and specify the product or service desired by a customer or market [1]. To be able to do so, information about who the customer is, what the customer wants, needs, and when the customer requests it is essential. A requirement process specifies how this should be done, in what order, and with which methods. The following sections provide a description of the two approaches to RE, contract-driven or bespoke, and market-driven. As this thesis focuses on MDRE, the purpose of the bespoke section is to provide a basic understanding of activities performed in classic RE and that are of importance also in MDRE. The MDRE section continues into section 3.2 and discusses activities and challenges more thoroughly.

3.1.1 Bespoke

The requirement processes used today often springs from a bespoke development where there are one or a few well known and defined customers. The product or service developed is custom made for the customers, who has taken part of the development process from the start [1]. A product developed with the bespoke process often has a single release followed by maintenance, and is defined by a contract situation. The contract between the customer and the developer controls when, how, and what that shall be delivered.

The bespoke development process includes several different steps of RE. The most common and important are described below.

3.1.1.1 Elicitation

Elicitation is one of the first steps in RE. The goal of the elicitation process is to find all relevant requirements and stakeholders. The first step is to create a stakeholder analysis that defines the customer and its needs. In the bespoke situation this is an easier task than in MDRE because of the close relation to the customer. After analysing the stakeholders, elicitation focuses on requirement gathering which includes catching, finding, and searching for requirements from the customer and the stakeholders. This step includes many different methods for finding the requirements, including e.g. customers and user interviews, prototyping, and focus groups [1].

3.1.1.2 Specification

When a requirement is found it needs to be documented, and this is done in the specification activity. Its goal is to specify the requirement on a correct, understandable and unambiguous way [1, 6]. Methods used here aid both the elicitation and the validation activities by means of finding even more requirements and visualising requirements for easier understanding and better validation. Specification methods include how to choose attributes for traceability and understandability such as owner, origin, and description [6]. The specification is often performed with the help of requirement tools that helps create an overview of all requirements.

3.1.1.3 Prioritisation

Before implementation starts, the requirements are prioritised, often by or with help from the customer. This is done to specify which function or features that has the highest value or importance, and indicates which feature that shall be implemented first [15]. This makes it possible to see what functionality that can and should be implemented within the project’s time limit or budget. Thereby it also indicates which functions that should be excluded if the project runs out of time or money. The prioritisation is often called negotiation in a bespoke development process. It is in this step the contract finally is fully defined with the help of a final requirement document. The prioritisation can be conducted in many different ways and with many different points of view, e.g. implementation costs or user satisfaction [1].

(22)

3.1.1.4 Requirements Management

During the project, the developing company conducts requirement management (RM), specifying requirement on different abstraction levels, making roadmaps for the development process, and assigns resources. RM handles the requirements, keeps track of changes, and sees to that no requirements are lost or forgotten.

3.1.1.5 Validation

Validation is often conducted throughout the project. Its purpose is to secure that the right product is developed, compared to verification that secures that the product is developed right. Validation can be done by making sure that all product goals are fulfilled. As the project is delivered, validation is done by the customer. The product is checked with the help of the requirement specification to make sure that it includes all negotiated functionality [1].

3.1.2 Market-driven requirements engineering (MDRE)

Market-driven development is a relatively new area in research as well as in the industry. Until recently, few structured methods for handling a market-driven requirements process existed, which have lead to even fewer implementations within companies [7]. The lack of knowledge in this area has also resulted in many companies working with market-driven products, but using bespoke models for their development.

One of the main differences between market-driven development and bespoke development lies in the customer relation. A market-driven process lacks a known and well defined customer and has instead a market or target group as customers [1]. Due to this, the project manager and the product-developing organisation often find it hard to keep contact with the market and getting feedback on what the market expects [2]. One of the first steps in market-driven development is therefore to specify the market. This can be done in a three step elicitation [11] starting with defining the market segment by means of price sensitivity, size, geographical information and so on. The second step is defining the user within the market. The user shall be general enough to describe the needs of every segment within the market. If the market is too wide, more than one user can be defined and described. The final step is defining the future user. This is done to satisfy the market at release, and not the present market. A market-driven development process must always aim at the future, from release and forward.

Due to the lack of direct contact between development and the market, the marketing and sales departments in the developing company plays a more important role during the development process in MDRE compared to bespoke development. They often act as the communication channel between the company and its partners, the market, and the customers [2, 4]. It is important that the communication between development, sales, and marketing is working well during a market-driven development and that information regarding feature request and wishes does not get filtered without careful consideration. Sales and marketing has the obligation to fill the lack of customer presence. This obligation does not only include representing the market at start of development, but also in the future. To accomplice this, the need for continuous and recursive elicitation and stakeholder analysis is of greatest importance.

There is also a market-driven development process that stretches in the direction of bespoke development, called mixed MDRE. This occurs when the market consists of a lucid numbers of distinct customers [3]. In this case, the sales department gets an even more important job of collecting requirements and feature requests. This is due to their need and possibility of continuous contact with the customers, including feedback.

Even though the aim is to collect as many requirement as possible from the market, more than 50% often spring from internal sources [2, 7, 11], why internal elicitation still plays an important part. This is especially true in technology driven organisations where there is a strong technological push.

3.2 Challenges in MDRE

There are many challenges in MDRE and the majority of them are related to the fact that there is not only one customer, but rather a market [2]. The requests and expectations from the customers are not unified, which aggravates the requirement and development process. The most common of these challenges are presented below. RP is a major challenge of MDRE [7] and is covered in detail in section 3.3.

(23)

3.2.1 Market instead of customer

The biggest challenge in MDRE is the lack of one well-known and defined customer [4]. The customer exists in form of a market or market segment. The market has many different needs and expectations and is difficult to read. The developing company has to perform market analyses, e.g. user interviews, focus groups and task demonstrations, to collect the needed information [7, 4]. This is a challenging and time consuming task, often carried out by the market or sales department.

3.2.2 Departments gap

The communication between departments in a market-driven process has to be well-functioning, especially between sales, market and development [2, 4]. As requirements, needs and feature suggestions often are collected through sales and marketing, the information has to be forwarded to development without loss of relevant information. Prioritisation and selection of requirements for development cannot be done solely by the market and sales side of the company. Development has to be highly involved and the product manager, who is in charge of the product and act as the link between sales and development, has to have total control over the product.

As for the marketing and sales departments it is important to get input from development, so that they can provide customers with accurate information, and so that they know what is feasible to develop in the organisation.

3.2.3 Traceability

This refers to the ability to trace requirements to their origins. Traceability in RE can be divided in several different sub categories covering forward and backward traceability, dependency traceability and traceability to source. Forward and backward traceability moves through the different abstraction-levels, dependency traceability moves within the same abstraction-level. Both forward, backward and dependency traceability are used in bespoke RE and has the purpose to create an overview and understanding for the requirements and their interactions. Source or origin traceability has the purpose to define from where the requirement sprung. This can e.g. be a customer, market analysis, or brainstorming meeting. In MDRE this is especially important as input to the prioritising and to create a possibility to get further specification from the source.

3.2.4 Continuous requirement flow

MDRE has a constant flow of requirements, and the requirements change during development [2, 4]. This is a result of the market changing and customers, partners, legislation, and research and development (R&D) reacting to that change [3]. With the continuous requirement process the development process has to support changes in requirements as well as being able to accept new ones. The development process in a market-driven development process is often recursive, stretching over multiple releases [13].

The constant flow of requirements also demands a well-working method for handling the requirements in by collecting, grouping and prioritising them [2, 4]. It is also important that the requirement proposer gets feedback on what has and will happen with the requirement. More than 80% of successful ideas to services and products come from customers [7], whom almost always want feedback to stay interested.

With the constant flow of requirements there is a risk for overloads and bottlenecks in the requirement elicitation [4]. As projects and products get more mature, the requirement flow often increases [2]. Many companies are facing this problem, and for some the problem gets too big to handle, leaving the only solution to drop their requirement database and starting from scratch [4].

One way of handling a constant requirement flow is through triage, which comes from the French word trier and means “to sort” [14]. Triage is, among other areas, used in emergency care e.g. at emergency call-centres and at mass casualties incidence to prioritise wounded. This is done to dispense the workforce where it makes the most effect. For example is there no need to spend manpower to attend to a person whose fatal injuries can not be helped even with medical care when the medical personnel instead can help an injured person which has a chance for recovery [14]. The same method can be applied to RE. Requirements can easily be divided in to three areas. The ones which must be included in order to get a working product, the ones

(24)

impossible to include, and finally the ones in between. By doing this, the amount of requirements which needs the most work, the ones that are not necessary in the product but still possible to develop, can get the most attention and refinement [14].

3.2.5 Time-to-market vs. functionality

Elements that control a market-driven development process are time and functionality [19]. The two are often opposite of one and other, since a short time-to-market often decreases the functionality, and much functionality increases the development time and the time-to-market. It is important to find a balance between functionality and time-to-market to get a product to the market at the right time, with the right functionality [19]. The recursive development process also supports this problem. By using a recursive process a product or service can be released early with basic functionality to the market in order to get market shares. Following releases can then increase functionality and create a more complete product [15]. A continuous and elaborated RP is needed to succeed with these challenges.

3.2.6 Innovations vs. expectations

To help secure customer satisfaction, the requirements can be divided in to different requirement types based on expectation from the customers. The different groups of requirements have different impact if they are included in the product or service, but also different impact if they are excluded [20]. This applies to bespoke development as well.

Expected requirements are functionality that the customers do not mention or make wishes for; for them it is obvious that this functionality is included in the product without them having to point it out. If the functionality is included, it will not have an impact of the customer satisfaction. On the other hand, if the functionality is excluded, the satisfaction will drastically decrease [7].

Normal requirements are functionality that the customers explicitly point out as wanted. The more that are included in the product, the more satisfied the customers will be, and the less that are included, the less satisfied the customers will be.

The last group of requirements are the sensational requirements. These are requirements generally not expected by the customer and are therefore not decreasing the satisfaction if they are excluded. If they on the other hand are included, they will drastically increase the satisfaction [20].

Fig 1:Illustration of requirement types and their effects on customer satisfaction.

3.2.7 Requirements elicitation

Eliciting requirements means to find them. Requirements are often hidden in formulations only touching the real essence of what to develop. If you ask the customers what they want, the

Customer Satisfaction Requirement Fulfilment Sensational Normal Expected

(25)

to solve that needs to be identified [1]. This kind of input results in “design in the requirements”, i.e. descriptions of how instead of what to develop, which obstructs efficient and innovative development. The best way to get around this issue is to ask “Why?” until the original problem is found [1]. Finding the problem allows you to create innovative and efficient solutions, solutions that the customer, without the technological expertise, might never think of.

There are many methods for eliciting requirements, each with somewhat different areas of effectiveness. The table in fig 2 illustrates the methods and their area of usage. Not all listed methods will be explained in detail, but this gives an idea of the variety to choose from. For more details on all of these methods, see Lauesen [1].

Things to elicit P re se nt w o rk P re se nt pro b le m s G oa ls a n d k ey i ssu es F ut ure s y st em i d ea s R ea li st ic p os sib il it ie s C o ns eq ue nc es a nd ri sk C o m mi tme n t C o nf li ct re so lut io n R eq ui re m ent s P ri o ri ti es C o m p let en es s Techniques Stakeholder analysis (Group) interview Observation Task demo Document studies Questionnaires Brainstorm Focus groups Domain workshops Design workshops Prototyping Pilot experiments Similar companies Ask suppliers Negotiation Risk analysis Cost/benefit Goal-domain analysis Domian-requirment analysis

Fig 2:Table illustrating areas of effectiveness for different elicitation methods. Dark for more

effective and light for less effective [1].

The sources for requirements in MDRE are many, and none shall be forgotten. The developing organisation is of course an important source, ideas pop up here and there, and engineers come up with new features, to name a few possibilities. According to the findings of the case study, the technical support personnel is a good source since they get frequent input from the customers, and know which issues they have. Sales and marketing are always in contact with the customers and knows what will sell, and so they are also a good source [4]. One source that tech-driven companies might not always be focusing enough on is the customers. In MDRE there should be a continuous flow of requirements from the market, both requirements coming to you from the customers as well as requirements actively elicited from the market [2, 4]. To elicit accurate requirements, and all of the most important ones, is an absolute condition to be able to create any valuable products at all [15]. Trying different methods and finding out what suits the organisation best is also essential.

(26)

Stakeholder analysis is generally a good idea to perform, and it provides information to the RP [7]. The purpose of stakeholder analysis is to answer the following questions, which when answered opens up views to find new requirements:

• Who are the stakeholders?

• What goals do they see for the system?

• Why would they like to contribute?

• What risks and costs do they see?

• What kind of solutions and suppliers do they see? [1]

Brainstorming is an easy and common way to elicit requirements. However, because of simplifications or lack of knowledge it is seldom performed to its full potential. A brainstorming session should be structured, lead by a coordinator, and open minded to new seemingly stupid ideas, which might turn out to be great. To let the ideas grow on you and to find the good ones, prioritisation should done a day or two after the session [1, 7].

Domain workshops have many advantages. The essence here is to let developers and expert users co-operate to analyse or design something. The expert users have valuable domain specific business knowledge, which cannot be contributed by managers, who on the other hand may be helpful in defining goals and visions. The workshop is a great way to involve users and customers, and getting an understanding for issues associated with using the product. The outcome of the workshop can be task descriptions, dataflow diagrams, or activity diagrams [1].

Goal-domain and domain requirement analysis are two of the main ingredients in the Requirement Abstraction Model (RAM, see section 3.4.1). They focus on analysing the existing requirement and finding new related ones. These methods are useful to gain completeness in the requirements specification [1].

Observation can be really useful for learning how the users use a product or to see how the users act in their own environment. This is especially good for identifying issues that the user finds hard to describe, a situation often compared to the problem of how to describe how to ride a bike. The technique is effective for finding the true customer needs [1, 7].

Scenario analysis helps understanding the product and its domain. A scenario takes time to fully develop, but can be useful in both validation by the customers and finding requirements. This technique is also considered a way of documenting requirements, however not commonly viewed that way in the industry [1, 7].

These are but a few of the many of techniques described in the literature. They are listed here as they are likely to fit the organisation this thesis is for, based on the analysis of the Company.

3.2.8 Varying abstraction levels of requirements

During elicitation requirements come up in different forms and on different abstraction levels. This is natural as different responsibilities generate different ways of thinking and therefore different level of detail. Also the various elicitation methods often produce requirements on different levels. An issue in this area is that there has to be defined levels of abstraction that are commonly understood so that every requirement is documented according to these levels. If no such understanding exists the requirement specification quickly becomes messy and inconsistent. A risk is that requirement on a high level of abstraction are assign for development, which leads to random interpretations of functionality. Hence a large amount of effort is spent on producing unwanted features instead of producing value.

When well-established abstraction levels exist and requirements are placed into those levels, it becomes possible to create traceability and completeness in the specification by performing work-up. This is well described by Gorschek’s RAM [6], covered in section 3.4.1.

3.2.9 Requirements capture, specification, and documentation

Once a requirement is identified it has to be specified and documented. Specifying the requirement refers to finding as many aspects of it as is needed, filling in the blanks. Documenting it is to file it in a proper way so that it is accessible in an effective manner.

(27)

Requirements might be specified as e.g. user tasks, scenarios, data models, virtual windows, state machines, or diagrams [1], but the most common way in the industry today is to use a kind of function-list style. This is basically writing the requirements down in a list. The strength of using function-list as specification technique is that it can easily be verified and validated after implementation. The drawback is that it gives a false sense of completeness and that many requirements are not suited for this kind of specification. For example, how do you specify a user interface with good usability qualities in a list, or how is a state flow represented efficiently? Other specification techniques also aid the elicitation as they provide good overview, which function-lists do not. Function lists are good for implementation and for performing the Create, Read, Update, Delete (CRUD) [1] check, which shall be applicable for all data entities.

How to specify a requirement is preferably ruled by guidelines that makes the requirements comparable to each other, i.e. requirements on the same abstraction level should have the same attributes. Gorschek [6] recommends a list of attributes for each requirement:

• Source

A link to the requirement source. Can be a person, customer, document, group or meeting.

• Owner

The owner is responsible for follow-up and acts as advocate for the requirement.

• Manager

Identifying the person responsible for specification, abstraction level and work-up.

• Description

Shall not exceed 5 sentences. Describes the essential in the requirement.

• Reason/Gain/Advantage

Shall explain WHY the requirement exists and what ADVANTAGE it provides in its context.

• Risk/Limitations

Limitations and risks that are not apparent in the description.

• Title

Not more than five words. Reflects the requirement’s essential meaning.

• Reference No.

Used for easy referencing.

• Relation/Dependency

Links to other requirements to point out important connections and dependencies on the same level of abstraction.

• State

Current state of the requirement.

• Reason for rejection

If the requirement is rejected a reason shall be stated to documentation and traceability reasons.

• Deadline

Used to see to that the requirement is not forgotten, e.g. by being set as draft for ever.

• Version

Makes it possible to trace requirement history.

• Date of creation

• Latest change

It is common that requirements are documented in Word or Excel documents, but these are not powerful tools when it comes to MDRE. The steady stream of requirements and the need to assign requirement to different releases calls for greater support. There are a quite a few RE-tools on the market, most handling the requirement in data bases which is a good practice. This

(28)

allows for many different views, and helps keeping the requirements structured. Using some kind of repository for the requirements is a good way to keep them ordered and gathered, but if not well-managed, a repository can be challenging as it might overflow and overview might be lost [4].

The way requirements are documented also affects how accessible they are. Good insight and overview of the specification is important to let everyone involved in the production know what they are doing, which increases motivation and productiveness. Using good specification and documentation techniques is a simple way to increase performance in the RE process.

3.2.10 Prioritising mechanisms

At many stages in MDRE there is a need to prioritise things. Mainly this concerns prioritisation of requirements according to different aspects, like most valuable or most urgent. This is one of the most important and hardest tasks in RE, as the number of requirements always exceeds what is possible to produce [20]. To get good, usable, and accurate results a prioritisation technique should be used. This section covers four useful techniques: grading, the 100$-method, analytic hierarchy process (AHP), and binary search tree [1, 22].

Grading is a common approach to prioritisation. A number of grade-levels are set and then the objects are graded according to these levels, one by one. This is a simple and quick but not powerful way to prioritise. A risk is that nearly all requirements are graded the same, e.g. all requirements are perceived as important and thus get the highest grade. The result is that the prioritisation becomes useless. Another problem with grading is how to interpret the grades value. Is a 4 twice as important as a 2? The issues with this method originates from the lack of common point of reference, and so each grading has the characteristics of the questions “how tasty is an apple?” or “how good is a pear?” [20].

In the 100$-method the one who carries out the prioritisation is given a set amount of imaginary money, e.g. 100$, and uses them to buy requirements for what that person perceive they are worth. This leads to that you can only buy what you can afford, and a requirement that is twice as important as another shall cost twice as much. This can be done with multiple participants, but that might lead to tactical voting where everyone only concentrate at a small part of the product [11]. This method is more powerful than grading, and does not require much more preparation.

Pair-wise comparison is considered by many to be the most powerful method and produces a relative value for each requirement. One method that uses pair-wise comparison is the AHP [14]. Each requirement is compared to every other and graded according to a specific aspect, like “which one is more valuable?”. The grade is set on a scale that goes from “much less valuable” to “much more valuable” in e.g. 9 steps. The consequence is a high number of comparisons; n(n-1)/2 where n is the number of requirements. This makes AHP cumbersome in handling large amounts of requirements and thus not suitable for MDRE, unless used on smaller parts or on abstraction-levels where the number of requirements is smaller. However, the result of AHP is very useful and powerful. Prioritising on cost and value would generate the following diagram:

(29)

R1 R2 R3 R4 R5 R6 R7 R8 R9 0 10 20 30 40 50 60 70 80 90 100 0 10 20 30 40 50 60 70 80 90 100 Cost Va lu e

Fig 3:The result of AHP visualised, where each point represents a requirement.

This way of representing the priorities gives an easy overview of what the return of investment will be, and so AHP makes a great contribution to the planning of product development.

The binary search tree also uses pair-wise comparison. Binary search tree is a tree structure where every node has a maximum of two children and every node is associated with a requirement. The tree is created by first selecting a reference requirement placed at the top of the tree. After that, each requirement is put into the tree by comparing it to the nodes; if the new requirement is more important than the node it moves to the right, and otherwise to the left. The tree can then be traversed to generate a list where the requirements are ordered according to priority. In this way no requirement can have the same priority as another [22].

Fig 4:A binary search tree, numbered according to priority, where 1 is the least

important and 9 is the most important.

The binary search tree method is much less complex than AHP and requires only an average of n*log(n) comparisons [22], which makes it possible to apply even with larger amounts of requirements. However, it does not provide the same exact information as the AHP.

3.2.11 Non-functional requirements

There are two main challenges regarding non-functional requirements. First, eliciting them properly, and second, how to specify them in a manner that contributes to the requirements specification rather than complicates it.

The first issue is best solved by using elicitation techniques that are useful for that purpose, and using checklists for validating that all necessary non-functional requirements are there [1]. There are a few different checklists available, e.g. IEEE 830, ISO 9126, and McCall. These list quality aspects that there should be requirements covering. Which aspects that are most suitable for an organisation differs, and is best evaluated by tryouts, using some standard lists to create

1 3 2 4 5 7 6 8 9

(30)

an own. This work should also include grading the importance of the different aspects. The only way to be good in all areas is to use more resources, which most often is not possible. Hence, one should concentrate on those that are most important. Fig 5 shows a list example.

Fig 5:The McCall and Matsumoto list [1].

The second issue has more to do with the implication of a requirement, and how it can be fulfilled in development. A requirement formulated like “The system shall have low response times.” might have a good intension, but there is no way to fulfil it. Like a functional requirement a non-functional requirement shall be testable, and making it so also makes it more understandable for developers and needs less interpretation. As an example a GPS-guiding system could have the requirement: “A new route shall be calculated within 10 seconds.” When formulating testable requirements one also has to account for plausibility. Are the specified values possible to reach? Is the market asking for that quality? It is common that one always specifies high quality demands on all areas, but one should consider whether it really creates enough value to motivate the high amount of effort needed to meet the requirements [1].

3.3 Release Planning

In market-driven product development a product is developed in several releases. There are several reasons for this, including gaining market shares early by releasing before one’s competitors and getting customer feedback early so that the product can be developed with the right features. In most cases there are more requirements to implement than is possible to assign to a single release due to budget, resource, and time-to-market constraints [16]. RP is done to maximise the business value of each release, measured in return of investment [15]. It includes prioritising the requirements, estimating their resource demands, and selecting requirements for a certain release [12]. According to Ruhe et.al. [18] a good release plan should:

• Provide maximum business value by offering the best possible blend of features in the right sequence of releases.

• Satisfy the most important stakeholders involved.

• Be feasible with available resources.

• Reflect existing dependencies between features. [18] Top level Second level Short explanation

Operation: Integrity How well the system handles physical disturbances and prevents malicious access attempts.

Correctness How many errors there are in the system.

Reliability How frequently the system malfunctions and percentage of time it is available.

Usability How easy it is to learn the system, how efficient it is for carrying out day to day tasks.

Efficiency How fast the system responds, how many resources it uses, how accurately it computes values, etc.

Revision: Maintainability How easy it is to locate and repair errors. Testability How easy it is to test the system after a change. Flexibility How easy it is to expand the system with new

features.

Transition: Portability How easy it is to move the system to a new software or hardware platform.

Interoperability How easy it is for the system to cooperate with other systems.

Reusability How easy it is to reuse parts of the software in other systems.

(31)

3.3.1 Purpose of release planning – What’s in it for us?

Well done RP gives many advantages, and can make the difference between a successful valuable product and a waste of resources. It actualises strategic decisions regarding properties like marketability, performance, scalability, stability, and functionality [17], and it considers product profitability in both the short- and long-term [16]. By focusing the development on the right features, resources can be better allocated and produce a higher return of investment. Research shows that 80% of the value of a product comes from 20% of the features, and that 20% of the features use 80% of the development resources. Also, it usually only requires 50% of the costs to produce 80% of the value, compared to supporting all needs proposed [7, 15]. Thus, the importance of focusing on the right features is evident.

A profitable product must meet customer requirements and provide high value to both their business and to their customers. Still profitability might not be reached unless the product is released at the right time with a high level of quality in comparison to competitors [15]. By aligning the product, project and business decisions, and the decision criteria used in different parts of the organisation, the value chain will be more efficient. This is a major issue in software development organisations. To be able to do this, one needs to understand how technical decisions and business strategy affects each other [15].

In well-structured RP these issues are addressed by analysing requirement dependencies, stakeholder needs, market segments, competitors and more. RP is one of the most critical tasks of product development because this is where it is ultimately decided what features that are included in a release, and due to the many variables to consider it is extremely complex [12].

3.3.2 Difficulties – Why is release planning hard?

In product development there are three major aspects that depend on each other: time-to-market, needs, and costs. This set the most basic constraint to RP. The more needs one wants to satisfy, the longer it takes to develop and the more expensive it will be. Adjusting one of these parameters affects the others. If the release date is set earlier, either the number of features has to be reduced or more resources are needed [7].

Parallel to these issues, requirements have to be prioritised and estimated in various aspects, so that time and resources not only are spent on the right amount of requirements but also on the right selection [12]. In order to succeed in RP, requirements need to be elicited, analysed and specified before entering the RP phase [15], otherwise estimates and priories are even harder to get right than they already are. Estimated parameters needed for each requirement are dependencies, value, and cost [12]. The RP process itself also requires some parameters before it is started. This concern time-horizon, objectives, stakeholder involvement, shot and long term planning, time-to-market and scope [16, 17]. These parameters are multidimensional, meaning they have different significance depending on perspective, such as stakeholder, programmer, or developing organisation. These parameters and aspects are covered in more detail in section 3.3.3.

Creating Valuable Products

Lund 2008-12-01

Master Thesis