Business Case: How to work out...

Business Case: How to work out

Requirements? Maria Arcus

Department of Computer Science

Open Source Research Group

Friedrich-Alexander-Universität Erlangen-Nürnberg

Supervisor: Prof. Dr. Dirk Riehle

Student ID: 21549606

E-Mail: [email protected]

Time Frame: 1.8.-01.02.2013

mailto:[email protected]

Business Case: How to work out Requirements?

II

ABSTRACT

The aim of this master thesis is to demonstrate the way the software requirements are built

on the example of a case written in the form of Harvard Business Case.

“The importance of complete, consistent and well documented software requirements is

difficult to overstate” (Early 1986). There is no bigger risk to a software project than

incomplete, misunderstood, or under-emphasized software requirements. However, it is not

always clear how to work out requirements.

This case was written based on a real software project and gives an overview of the process

how the requirements are discovered, documented, validated and managed. It also illustrates

the methodologies and techniques used by requirements engineer, and defines the key

players. The case ends with an open question - how can the process of working out

requirements could be improved or reinforced?

Along with the case, this work contains structured summary of major concepts with the

theoretical materials the case was based on. The discussion guide provided in the final part

of this thesis is the instruction how this case should be presented to the auditory.

The thesis is licensed by CC-BY-3.0.

http://creativecommons.org/licenses/by/3.0/


III

CONTENTS

ABSTRACT ........................................................................................................................... II

TABLES ................................................................................................................................ V

ACRONYMS ........................................................................................................................ VI

1 INTRODUCTION ............................................................................................................ 1

2 BUSINESS CASE: HOW TO WORK OUT REQUIREMENTS? ...................................... 2

2.1 The story ................................................................................................................. 2

2.2 Lucky complaint – how it all began .......................................................................... 3

2.3 GfK Group ............................................................................................................... 4

2.4 Business Analysis ................................................................................................... 8

2.5 ReDQC PS Scope ................................................................................................... 9

2.6 Kick off ...................................................................................................................11

2.7 Requirements Elicitation .........................................................................................13

2.7.1 First Round .....................................................................................................13

2.7.2 PRD ................................................................................................................14

2.7.3 Second Round ................................................................................................16

2.7.4 Detailed Requirements ....................................................................................17

2.8 The Cost of Poor Requirements .............................................................................20

2.9 Prioritization ...........................................................................................................21

2.10 Peer review ............................................................................................................22

2.11 Final review and Sign Off .......................................................................................22

3 STRUCTURED SUMMARY...........................................................................................24

3.1 Requirements Engineering .....................................................................................24

3.1.1 Key players .....................................................................................................25

3.1.2 How to handle stakeholders ............................................................................26

3.2 Eliciting Requirements ............................................................................................26

3.2.1 Requirement ...................................................................................................26

3.2.2 Requirements Elicitation ..................................................................................27

3.2.3 Sources of requirements .................................................................................27

3.2.4 Requirements discovery technique ..................................................................27

3.3 Documenting Requirements ...................................................................................29

3.3.1 Requirements documentation in Natural Language .........................................30

3.3.2 Requirements documentation in conceptual models........................................31

3.3.3 Glossary ..........................................................................................................32

3.4 Requirements validation .........................................................................................33


IV

3.4.1 Why requirements validation ...........................................................................33

3.4.2 Requirements validation techniques ................................................................33

3.5 Requirements Management ...................................................................................34

3.5.1 Why prioritizing requirements ..........................................................................34

3.5.2 Prioritization techniques ..................................................................................35

3.6 Analysis and improvements strategy ......................................................................35

3.6.1 Suggestions for process improvement ............................................................35

3.6.2 Requirements engineering tools ......................................................................36

3.6.3 Tools’ benefits .................................................................................................36

3.6.4 Proposed tools ................................................................................................37

4 CLASS DISCUSSION GIUDE .......................................................................................39

4.1 Background ............................................................................................................39

4.1.1 Who/what is GfK Group? .................................................................................39

4.1.2 What is the relation of GfK Retail and Technology to GfK Group? ...................39

4.1.3 What is GfK Retail and Technology’s product? ................................................39

4.1.4 What is the GfK Retail and Technology product management approach? .......39

4.1.5 Difference of V-Model and Agile in regard of RE process ................................40

4.2 Requirements Engineering .....................................................................................40

4.2.1 What are the main activities of requirements engineering?..............................40

4.2.2 Key players of the requirements engineering ..................................................40

4.2.3 What is their role of a Stakeholder in product development? ...........................40

4.3 Elicitation ................................................................................................................40

4.3.1 What is requirements elicitation? .....................................................................40

4.3.2 What is a requirement? ...................................................................................40

4.3.3 What sources of requirements are described in the case? ..............................40

4.3.4 What other sources of requirements and techniques could be defined? ..........41

4.4 Requirements documentation .................................................................................41

4.4.1 How were the requirements built? ...................................................................41

4.4.2 Why documenting glossary, meeting minutes, meeting protocols? ..................41

4.5 Requirements validation .........................................................................................41

4.6 Requirements management ...................................................................................42

4.7 Problems being faced .............................................................................................42

4.8 Proposed solution ..................................................................................................42

4.9 Main question: What should GfK Retail and Technology do? .................................42

APPENDIX .......................................................................................................................... VII

BIBLIOGRAPHY ................................................................................................................... IX


V

FIGURES

Figure 1: Top 10 of the Market Research Sector 2010 .......................................................... 5

Figure 2: GfK Locations and Subsidiaries .............................................................................. 6

Figure 3: StarTrack General Workflow ................................................................................... 7

Figure 4: V-Model .................................................................................................................. 8

Figure 5: Business Analysis Process ..................................................................................... 9

Figure 6: ReDQC PS Stakeholders ......................................................................................11

Figure 7: Example of high level requirements .......................................................................12

Figure 8: Core of a requirement ............................................................................................18

Figure 9: Requirement phrasing template GfK Retail and Technology GmbH ......................19

Figure 10: Structure of a complete requirements template ...................................................19

Figure 11: Example of overall performance requirements ReDQC .......................................20

Figure 12: StarTrack Organogram ...................................................................................... VIII

TABLES

Table 1: Main causes of project failure according to Standish Group .................................. VIII

Table 2: Requirements engineering defects cost ................................................................ VIII


VI

ACRONYMS

BA Business Analyst

BABOK Business Analysis Body of Knowledge

BO Business Owner

CRC Class Responsibility Collaboration

CH Switzerland

DI Data In

DII Data In International

IT Information Technologies

MTM Microsoft Test Manager

NR Non-Functional Requirements

PMO Project Management Office

PR Process Step

PRD Product Requirements Document

QC Quality Check

RM Requirements Management

UK United Kingdom

UML Unified Modeling Language

URL Uniform Source Locator

ReDQC Retailer Data Quality Check

ReDQC PS Retailer Data Quality Check Performance and Stability

1

1 INTRODUCTION

One of the most important aspects of software development is the quality of the finished

product. But who measures the software quality? The answer is of course - the user. The

software quality is the indicator of how well it satisfies users’ needs, which are exposed via

requirements. Therefore the question, how do we get requirements, comes up?

The first chapter demonstrates the process of working out requirements and what stands

behind this process on the example of a software project in a German company, GfK Retail

and Technology GmbH. The case illustrates the phases of the followed in the given project

process, and actions performed by the business analyst to build the requirements. Although

this process was functioning fine, some minor problems indicated that there was still room for

improvements. Therefore, the question how to improve the existing process comes up in the

story.

The second chapter provides the structured summary of the concepts and theoretical

materials relevant to the business case. The major concepts comprise requirements

engineering process phases like requirements elicitation, documentation, validation and

requirements management. The given concepts also include the key players and the relevant

to each phase techniques, as well as example of requirements construction method with

examples.

The discussion guide with the instructions how this case could be followed and presented to

the auditory is provided in the third chapter.


Licensed CC-BY-3.0 2

2 BUSINESS CASE: HOW TO WORK OUT REQUIREMENTS?

"If you don't have time to do it right, when will you have time to do it over?"

John Wooden1

(Note: All names have been changed to protect the parties' privacy.)

2.1 The story

It was a cold December morning 2011 when Michael Meyer, business analyst (BA) at GfK

Retail and Technology GmbH, arrived to the office. He just finished the Product

Requirements Document 2 (PRD) for his current project and already scheduled the

prioritization meeting with business owner and stakeholders for 20th of December 2011. It

was a project for performance and stability improvement of an internal GfK application

ReDQC. This project was an average one, without any unsolvable obstacles. Nevertheless,

during this project Meyer started to notice that the business analysis process needed some

improvements.

ReDQC - Retailer Data Quality Check, performed raw data quality check (QC) received from

the retailers all over the world. The application inspected data for potential errors,

discrepancies, and inconsistencies which were stored in its error pools. ReDQC was a major

part of the dataflow in GfK StarTrack reporting system, which provided retail and technology

market sector information.

"…We don’t need to prioritize requirements. They’re all important, or I wouldn’t have given

them to you…“3, stated in the reply to the prioritization meeting invitation, Meyer has received

from one of the stakeholder.

In fact, requirements prioritization phase was a usual procedure in the StarTrack business

analysis process, as in any other company, but not every stakeholder understood its

importance. The prioritization was mainly used to determine which requirement of a software

product should be included in a particular release and define the implementation order, to

minimize risk during development. Moreover, it is significantly less expensive to correct

problems before the development phase actually begins.

1 John Robert Wooden (October 14, 1910 – June 4, 2010) was an American basketball player and coach.

2 A document that outlines all the requirements that should be met for building a product or new features for an

existing product. 3 Extract from ReDQC PS project stakeholder’s email to BA.



2.2 Lucky complaint – how it all began

It appears that the “ReDQC Performance and Stability” (ReDQC PS) project was initiated

thanks to several complaints raised by ReDQC users during last two years (2010-2011), and

especially due to Robert Bauer’s last request. ReDQC application was a legacy application

developed more than ten years ago and ever since has not been seriously updated;

therefore its performance could not compete with the recently developed applications. It was

hard to ignore the difference between ReDQC and any other applications’ response time.

“It is quite annoying… on any performed action you have to wait one to two minutes,

especially when working with countries that have a big amount of data, like Germany.

Sometimes the application hanged, not too often though, maybe once a week.” confessed

Robert Bauer, StarTrack DataIn specialist 4 . According to request submission process

developed at GfK Retail and Technology GmbH, any user, who has a suggestion for system

improvement or a complaint, had to raise a helpdesk request. The request had to be

assigned to the Portfolio Management department with “new demand” reason. Afterwards,

portfolio management team would review the request, analyze and prioritize accordingly.

Only after these actions a project could be created.

Portfolio Management team initiated the ReDQC PS project using this procedure in

November 2011. At that time, senior management had already recognized the need to

improve their existing applications. Customer and user complaints had played an important

role in this decision. The focus on internal applications represented a departure from prior

practice. Previously, management had considered applications like ReDQC a second priority,

while development of new applications was the main project’s strategy.

Soon after processing Bauer’s complaint, Portfolio Management department has provided

confirmation of resources availability for “ReDQC Performance and Stability” project. It was

that fortunate coincidence when users’ needs were taken in account so hastily. One of the

triggers of this decision was also the fact that behind ReDQC performance and stability

enhancement was not only user satisfaction, but also the work efficiency factor, namely such

performance was slowing down the whole DataIn team’s working process, not to mention

that it affected users’ eagerness to work.

4 StarTrack DataIn specialist – is an expert in Data In domain, in the given case specialist in ReDQC application

and business user.



2.3 GfK Group5

Headquartered in Nuremberg, Germany, the GfK Group was Germany's largest market

research institute, and the fifth largest market research organization in the world. It was

established in 1934 by an association of university teachers, among them Professor Wilhelm

Vershofen, who formulated the business idea of GfK, which till today represents the

quintessential cornerstone – the base of the company success: "Let the voice of the

consumer be heard".

It was founded as scientific institute “Gesellschaft für Konsumforschung”, whose purpose

was to examine the consumers’ habits and attitudes towards the consumer goods based on

continuous measures using special surveys and to process the findings of such studies for

the purposes of economic practice and teaching. [http://www.gfk.com] GfK conducted the

first brand study in Germany, and by 1937 published the first figures of German consumer’s

purchasing power6.

The internationalization of GfK stated in 1961 by opening of the first subsidiary outside

Germany and led to its commercialization. By 2012 GfK has grown from a German company

with 15 employees in 1949 into a worldwide company with over 12 000 employees. The GfK

Group was Germany's largest market research institute, and the fifth largest market research

organization in the world, which generated annual revenue of more than USD 1.7 million in

2010.

5 This section draws heavily from “Starting Out”, http://www.gfk.com.

6 The amount of goods or services that can be purchased with a unit of currency.

http://en.wikipedia.org/wiki/Market_research



http://www.gfk.com/



Figure 1: Top 10 of the Market Research Sector 2010

In 1970 GfK Group has founded GfK Retail and Technology GmbH, a market research

company which provided sales reporting for technical consumer goods markets. These

markets included Automotive, Babycare, Consumer Electronics, Domestic Appliances,

Entertainment Media, Fashion, etc.

GfK Retail and Technology GmbH introduced their product, StarTrack, in late ‘90s.

StarTrack, a global system was used to provide customers with the market research

information and sales data about items sold in over 90 countries worldwide.



Figure 2: GfK Locations and Subsidiaries

StarTrack delivered regular reports and information based on the sales data received from

retailers. The retailers provided information like: number of sales per shop for particular

period, brand name, number of items, model type, configuration and more detailed

information for sold item.

Based on this raw data and with application of complex processes StarTrack system

provided customers with information which items were sold best, where, over what channels

and why. Moreover, it provided transparency what consumers were buying and why based

on changing consumer trends. This market research helped customers understand people,

markets, products and brands.

Behind StarTrack laid complex workflow, which comprised three main process parts: DataIn,

Pre-Processing and DataOut. DataIn workflow part was responsible for the conversion of

data delivered by retailers in different formats into GfK standard format; inspection of

incoming data for completeness and quality. Pre-Processing part was in charge of

processing data which has been prepared by DataIn, so that it could be reported to the client

with high quality level. DataOut provided data to the client both for administration and data

access purposes, which allowed management of reports and data via StarTrack Portal and

GfK StarTrack Explorer.



Figure 3: StarTrack General Workflow

One of the major DataIn workflow’s components was ReDQC, developed and released in

1999. It was the cornerstone of the data quality check therefore was of high importance

within the whole dataflow in the StarTrack system.

ReDQC analyzed the converted data file that was generated from a retailer delivery. Then it

produced QC measurements based on previous periods’ deliveries and on stored tolerance

ranges (% change). The converted data file was then automatically loaded into ReDQC and

aggregated.

After data errors have been identified there were two possibilities to fix them. First has been

done automatically by the system based on the previously human made decisions. The

second was performed manually by a user. User could check the data for discrepancies and

errors on different level of granularity which has helped to make the process more effective.

After ReDQC job has been done raw data was stored in the data warehouse and ready for

the next level of preprocessing.

During pre-processing the data is extrapolated, i.e. a universe is constructed out of known

sales data. As a result extrapolation can be used in the production process to create

reporting which allows building conclusions for the overall market and supply customers with

possibility to receive relevant reports.



2.4 Business Analysis

GfK Retail and Technology GmbH StarTrack followed the V-Model7 software development

methodology, which implies eliciting and documenting all requirements completely in an early

project phase before any design or realization decisions are made.

Figure 4: V-Model

Along with V-Model Star Track has also adapted process which implies that before business

analysis could be started, each project must go through the demand phase and get business

analyst lead approval and resources availability confirmation.

When Michael Meyer first heard of plans for ReDQC Performance and Stability project, it

was already forwarded to the portfolio management team, part of Business Liaison

department.

On 15th of November 2011 the demand for respective period was complete and Andreas

Baier, business analysis lead, assigned ReDQC Performance and Stability project to Michael

Meyer, an experienced business analyst. Even though Meyer already had a pending for sign

off project, it was a usual practice to lead several projects in parallel. Right after he has got

7 A software development process which may be considered an extension of the waterfall model. Instead of

moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing.



acquainted with the project details Meyer has proceeded to preparation for the first meeting

with ReDQC PS business owner8 (BO) Thomas Mueller.

The StarTrack business analysis process underwent several reorganizations on June 2010,

and after that involved following participants: Business Analysis Lead, Business Owner,

Business Analyst, Enterprise Functional Architect, Development Process Manager, Technical

Project Lead, and Test Lead. Each of them played its role at the defined by new business

analysis process phase.

Figure 5: Business Analysis Process

According to StarTrack organizational structure Business Liaison Department with

department head Matthias Schmidt was in charge of business analysis and architecture,

while development was performed by a separate Development department with head Gregor

Fischer. Service Delivery and Testing department headed by Frank Braun was in charge of

testing.

2.5 ReDQC PS Scope

Thomas Mueller’s interest in ReDQC quality improvement was of more strategic nature. As

head of Global DataIn, Mueller has considered this project as the beginning of the whole

8 Within GfK R&T GmbH Business Owner initiates and sponsors the ideas, suggestions or requirements with the

focus to transfer them into a project and finally into a real-life solution. His responsibilities are to develop a project goal, a project approach and a financial model. He also ensures to prepare the organization to operate the new business capabilities.



DataIn domain performance increase. Therefore he has prepared all necessary details in

advance before receiving the invitation to the first meeting from the business analyst.

The meeting with BO was set up on 21st of November 2011, and appeared to be very

productive.

“First of all we have to agree on the project objectives, scope, and goals” said Mueller,

and started to get into “ReDQC Performance and Stability” details. He explained why

ReDQC needed an improvement and gave several examples of performance issues

reported by users:

“It is of great importance now to improve ReDQC performance. You should understand

that this application was developed in 1999 and cannot keep pace with the up to date

soft- and hardware. Moreover, the understanding of performance has also greatly

evolved since that time.”

“Just to make sure we are on the same page; are new functionalities and all boundary

system/applications out of scope?” asked Michael Meyer. “Yes, precisely, only the

increasing of the performance and stability of the existing functions within the ReDQC

tool are in scope.” confirmed Mueller. “The objective - ReDQC should be more

performant and get much more stability” added business owner.

The last important question left to be discussed was the list of stakeholders. Meyer needed

to confirm the names and their areas of interest in ReDQC, in order to be able to set up

further meetings and start the interviews.

By the end of the meeting with business owner Meyer had all required information including

the stakeholder’s contact details. ReDQC PS stakeholders group was rather international

group and included six people: business owner Thomas Mueller himself, Martin Gross

Responsible for Global DataIn, Steffen Huber Manager for DataIn national and coding

Germany, Robert Bauer DataIn specialist, Richard Black UK Business Group Director

DataIn, and John Smith CH responsible for knowledge about ReDQC.



Figure 6: ReDQC PS Stakeholders

2.6 Kick off

On 27th of November 2011 Thomas Mueller organized ReDQC Performance and Stability

kick off meeting where all stakeholders including BA Michael Meyer were invited. Being

responsible for defining the stakeholders, business owner has introduced everybody to each

other. Every participant shared their area of interest and expectations from the ReDQC PS

project.

By repeating his own reasons mentioned during his meeting with Michael Meyer, Mueller

communicated the project background and explained the participants the necessity in it. He

made sure that every stakeholder sees the whole picture and understand the goals and

scope. He emphasized that the project scope covers only increasing of the performance and

stability of the existing ReDQC functions, meaning that new functionalities were out of scope.

As project business owner, Mueller vocalized a number of high level requirements and

explained them more detailed, but skipping precise details like acceptable response time.

The purpose of these requirements was to build a foundation of future requirements and

visualize the goals.



Figure 7: Example of high level requirements

After a long discussion the stakeholders expressed their own preliminary wishes and

suggestions. Robert Bauer, one of the most engaged stakeholder approached Meyer after

the kick off meeting and promised to provide his own requirements and an excel document

with partial ReDQC application response time measurements he did during his daily work.

“I believe these measurements could be used as comparison for future application

performance check.” said Bauer.

The other stakeholders have also sent Meyer their proposals and suggestions, though not

completely related to the project scope. These requests were a mixture of new functionalities

wishes with performance improvement requirements. Meyer was happy to see such an eager

collaboration right after the first meeting. Apparently, the problem of slow performance and

application instability was a pain for everybody for a while.

Michael Meyer’s duty for now was to send over the meeting protocol. He gathered the

expressed during the meeting requirements and suggestions and put them together into a list

of high level requirements. These requirements were only the raw material which he had to

rework. After the requirements analysis Meyer defined which of them are in or out of ReDQC

PS scope. He also sorted them by area and category, preparing the basis for each type of

non-functional requirements. When this was done Meyer has sent over identified

requirements to all participants for familiarization and agreement.

Now that Michael Meyer had all necessary information about goal, scope, stakeholders and

high level requirements he could proceed to first interviews round with the stakeholders. He

had to plan the meetings with each stakeholder apart and collect all relevant information.



2.7 Requirements Elicitation

Elicitation of requirements is fundamental activity of requirements engineering, which is

based on gained during requirements engineering knowledge, and comprises various

requirements sources like documents, legacy systems and stakeholders. The purpose of

requirements elicitation is to thoroughly identify the business needs, risks, and assumptions

associated with any given project (Pohl 2011).

The preparation for elicitation process plays an important role, since it includes definition of

the relevant stakeholders and proper elicitation techniques.

According to BABOK9, project’s stakeholders may include customers/end users, suppliers,

the project manager, quality analysis, regulators, project sponsors, operational support,

domain subject matter experts, and implementation subject matter experts.

Commonly used requirements elicitation methods as identified by BABOK include:

Brainstorming, Document Analysis, Focus Groups, Interface Analysis, Interviews,

Observations, Prototyping, Requirements Workshops, and Survey/ Questionnaire.

According to BABOK, one-on-one interviews are among the most popular types of

requirements elicitation, since it involves personal communication between analyst and

stakeholder and gives opportunity to discuss in-depth stakeholder’s thoughts and get his or

her perspective on the business need. Moreover, interviews gather more information than

sorting and ranking techniques (Iba 2009). However, a single applied technique cannot

guarantee complete and comprehensive requirements discovery.

Interview is most common methodology for GfK Retail and Technology GmbH as well,

though other techniques like document analysis, brainstorming, observations and workshops

are often applied too.

2.7.1 First Round

At the stage of high level requirements collection BA’s duty was to document users’ feedback

even if sometimes it was not relevant to the project scope, but after first round of meetings

and interviews with each stakeholder Meyer had an impression that they simply forgotten the

scope. One after another stakeholders described in details what they would like to be added

to the application, all possible new functionalities, except the ones related to the performance

and stability issues.

9 A Guide to the Business Analysis Body of Knowledge (BABOK) is the written guide to the collection of business

analysis knowledge reflecting current best practice, providing a framework that describes the areas of knowledge,

with associated activities and tasks and techniques required.

http://en.wikipedia.org/wiki/Business_analysis

http://en.wikipedia.org/wiki/Business_analysis



“I would also like to have a tool panel on the right hand side of the screen which will

contain all the export possibilities. Plus the export should be possible to do not only in

the excel format, but I would prefer to choose the export file format myself.” shared

(stakeholder) his thought with BA. “Yes of course, these requirements will be

document, but let me remind you that the scope of this project is improving ReDQC

performance and stability only.” emphasized Meyer, “I am afraid that all functional

requirements should be overtaken as a separate project”.

Meyer felt that for the stakeholders these interviews were not only a way to contribute and

improve the applications’ performance but also a chance to share all their needs from daily

business. Some of business users expressed wishes to change the interface into a more

modern user friendly and intuitive way, or add a new functionality that could make their work

easier.

Only the meeting with DataIn specialist, Robert Bauer, who provided Meyer with application

response measurements after the kick off meeting, was the most productive. During the

meeting Bauer literally demonstrated the performance problems he raised in the request. He

performed several companies’ data checks during which business analyst saw how slow the

performance actually was. Meyer proposed to make the complete measurements of each

screen and tab in the ReDQC and document them in the same way he did earlier as a proof

of the problem.

After first round of meetings Meyer spent two days on analyzing and arranging users’

feedback according to the topic and functional area. He arranged the requirements in the

table format that reflected information about the requirement author, date it was received,

functional area and relevance to the ReDQC project scope.

He sighed with relief and sent business owner and stakeholders’ the requirements list for

review and confirmation. Nevertheless, he still had to rework the high level requirements into

the detailed once.

2.7.2 PRD

One of the important activities during requirement engineering is documentation. Information

that has been established or worked out during different activities must be documented.

Among information that has to be documented are, for example, protocols of interviews and

reports of validation or agreement activities, and also change requests. Though, the main

and most important documentation task in requirements engineering is to document the

requirements for the system in a suitable manner (Pohl 2011).



The document that was used for software requirements collection within GfK Retail and

Technology GmbH was called Product Requirements Document (PRD), and it comprised

project description, objectives, current and target situation analysis and other essential for

the project information. Within ReDQC project, PRD was used as main documented source

of reliable software requirements.

To become a basis for the subsequent development processes, the requirements document

must meet certain quality criteria and according to IEEE standard10 (Engineering 1998b), the

requirements document must hold unambiguity and consistency, clear structure, modifiability

and extendibility, completeness and traceability. Therefore, BA in charge of the document

tracks and documents all the changes applied during the business analysis phase up till the

final sign off of the document.

The forthcoming business analysis phase meant, for Meyer, working on the current and

target situation analysis and documenting ReDQC business processes by means of

conceptual models i.e. developing use cases.

The documentation process in GfK Retail and Technology StarTrack comprised not only

requirement documentation in natural language but also by means of activity diagrams and

use cases diagrams, which allow gaining a quick overview of the functionalities of the

specified system. They describe which functions are offered to the user by the system and

how these functions relate to other external interacting entities. In case of ReDQC PS it was

done for a general overview of application’ functions.

So far by the end of the week on 2nd of December, Meyer worked out workflow diagrams,

which visualized current for that period and target business processes within ReDQC

application, together with accompanying table containing explicitly described business

processes.

The PRD versioning and accessibility was also BA’s responsibility, therefore Meyer had

constantly updated the document and uploaded it to the StarTrack share point11 and notified

the stakeholders about new version available for review. It was necessary to provide exact

URL both for the public and private folders where the newest document version was stored,

and make sure that each of the stakeholders has the access to it.

10 The Institute of Electrical and Electronics Engineers Standards Association (IEEE-SA) is an organization

within IEEE that develops global standards in a broad range of industries.

11 Microsoft SharePoint Web application platform.



2.7.3 Second Round

During the requirements engineering activity, it is necessary to review the quality of the

developed requirements. Among others, the requirements are presented to the stakeholders

with the goal to identify deviations between the requirements defined and the stakeholders’

actual wishes and needs (Pohl 2011).

Requirements review is an iterative process; each iteration within ReDQC project started on

Mondays, when the stakeholder meeting took place, and lasted one week till the next

meeting. All participants were supposed to send their review feedback by beginning of the

following week - next iteration phase. The main reason of this process was that requirement

defects are best identified as requirements are written, not weeks later by a review of a large

document.

Although in the first meetings the stakeholders showed their interest in the project, only a few

participants have provided their review feedback by the end of first iteration week. Michael

Meyer was a bit surprised to find such weak involvement after very promising kick off and

interview meetings, nevertheless he decided to wait and see what happens during next

review session on Monday, 12th of December.

On Monday meeting Meyer has reminded that meeting agenda was to review the so far

documented requirements, business processes and use cases, to discuss the received

feedback, any appeared objections and confirm the agreed requirements. It came out that

some stakeholder still didn’t send their review feedback, moreover some were not ready to

discuss the sent by BA product requirement document.

To achieve a better involvement and commitment from participants Meyer tried to implicate

them in discussions as much as possible during the meeting. He went through each detail,

question and finally, by the end of the meeting, collected needed feedback. He thanked the

participants and expressed his expectations for productive further cooperation:

“I appreciate your contribution and hope for a very productive further work with you all”.

However there were more delays from stakeholders’ side during the next review iterations.

Several stakeholders repeatedly postponed the meeting review sessions due to the work

overload. It was difficult to get all stakeholders together in one meeting, especially since two

of them were located in other GfK offices in UK and CH. Some of them would not send the

review feedback by the due date, which caused the overload of amount of information to be

reviewed for next review iteration. Meyer was especially dependent on the stakeholders that

were real ReDQC application users, only these stakeholders were actually the source of



performance requirements. Having some experience in business analysis Meyer knew that

delays with feedback was a normal practice. Stakeholders were usually overloaded with daily

business tasks and involvement in the business analysis took them extra efforts.

What Meyer did not expect was that the stakeholders mixed up the meaning of requirements

they were talking about, i.e. during the review meetings they seem to be talking about one

thing, but apparently meant totally different one. Therefore, he documented the requirements

word by word during the interviews and confirmed its definition with the authors. Sometimes

it was rather hard to agree on the requirement meaning and narrative especially since it was

done in English, which was not a native language for every stakeholder.

Meyer was worrying about project deadline and of course he knew that in order to complete

the project successfully it was necessary to make sure that the project’s goals are followed. It

often happened that the project scope and goals slightly change along the project lifecycle, in

result it caused delays. This was the reason why he confirmed “ReDQC Performance and

Stability” project goals and scope every week with Mr. Mueller.

2.7.4 Detailed Requirements

Within three weeks since the kick off meeting Meyer received ReDQC performance

measurements from several stakeholders and arranged those in a single excel file for a

future agreement on the acceptable response time. He also did the refinement of the initially

gathered high level requirements and reworked them into more detailed low level

requirements by natural language means.

Natural language, or in other words prose, is the most commonly applied documentation

form for requirements in practice. In contrast to other documentation forms, prose has a

striking advantage - no stakeholder has to learn a new notation. In addition, language can be

used for miscellaneous purposes - the requirements engineer can use natural language to

express any kind of requirements (Pohl 2011).

The approach of requirements construction in natural language form developed by SOPHIST

GmbH, consulting and training company, was adopted and integrated into the GfK Retail and

Technology GmbH business analysis processes in 2011. The “shall”, “should” and “will”

auxiliary verbs were used in this approach to indicate requirements priorities (Please see

Figure 8). Namely, “shall” denote something that is required, in other words obligatory

requirements, and is used to dictate the provision of a functional capability, while “should”

determines urgently recommended requirements, and by “will” future requirements are

denoted.



This approach is the most common one to define requirement’s legal obligation level;

however it was slightly reworked by GfK Retail and Technology GmbH before its integration

into the company’s business analysis process. The standard verbs “shall”, “should” and “will”

were replaced accordingly by “needs to”, “shall” and “must” and incorporated into

requirements template.

Figure 8: Core of a requirement

According to companies’ requirements construction template in order to build a requirement it

was necessary to follow five basic steps. First step begins with the process definition

introduced by a verb, the central point of a requirement, namely a functionality (for instance

prints, save, calculate). A verb plays very important role, because the whole requirement is

connected to this process word. Therefore it is of high importance to determine the required

process in the beginning of the requirement building process.

In the second step it is necessary to characterize the activity of the system, since the way the

system works is closely linked to the process word. According to the adopted approach three

types of system activities are defined: The system carries out the process by itself –

independent system activity; the system provides the user with process functionality – user

interaction; the system carries out the process dependent on a third factor (for e.g. a different

system), remains passive and waits for an external event – interface requirement.

The third step defines the level of importance with the help of “needs to”, “shall” or “must”,

which completes the core of the requirement and emphasizes the legal relevance. Following

first three steps a basic structure of a requirement is obtained:

E.g. Basic requirement version 1: The system needs to provide the administrator the ability

to print.



Next step is necessary to determine precisely the process by introducing the missing object.

In the example requirement is not apparent what is to be printed and where it is to be printed

to.


to print the error message to the network printer.

In the final step a logical or temporary condition is defined, under which the functionality is

performed. These constraints are located at the beginning of a requirement.

Figure 9: Requirement phrasing template GfK Retail and Technology GmbH

E.g. Basic requirement version 3: If an error message has been generated, the system

needs to provide the administrator the ability to print the error message to the network

printer.

Figure 10: Structure of a complete requirements template

The performing of described requirement building steps guarantees a good requirement

construction. Nevertheless the template does not exclude the need of analytical thinking and

performance of constructed requirements optimization which support working out a good

requirement (Ruppb).



Figure 11: Example of overall performance requirements ReDQC

2.8 The Cost of Poor Requirements

Software engineering history has shown that not all of IT projects are successful. Often

projects are late, over budget, and may not deliver what they promise. There are many

reasons that cause all these complications. The problems related to requirements

engineering according to (Zowghi 2002) are one of the main reasons for software projects

failures. This means that the final product does not have all the requirements gathering from

users and customers.

The software requirements identification and management difficulties could be caused by the

fact that:

The requirements are difficult to identify;

Requirements are not easy to be described in words;

Requirements were not clear and well not organized;

There are different types of requirements in different levels of details;

It can be impossible to manage the requirements if they cannot be controlled;

According to a study of the Standish Group, “Incomplete Requirements and Specifications”

factor is on the second place for project challenged factors (Please see Table 1). About 20

percent of the software projects investigated in 2006 failed, and around 46 percent of

projects exceeded time or budget constraints, and/ or did not meet customer satisfaction

(Rubinstein 2007).

Approximately 60 percent of all errors in system development projects originate during the

phase of requirements engineering, according to Boehm. Apparently most of the errors are



discovered in later project phases. The later in the development project a defect in the

requirements is corrected, the higher are the costs associated with fixing it. The effort to fix a

requirements defect is up to 20 times higher if the correction is done during programming

instead of during requirements engineering phase, and up to 100 times higher if the defect is

fixed during the user acceptance testing (Boehm 1981).

Requirements engineering plays an important role in the software development. As stated by

(Oberg 2000) a requirement is the condition or capacity that a system that is being

developed must satisfy. Therefore, the compliance with requirements determines the

success or the failure of a project.

2.9 Prioritization

The criterion of requirements prioritization within ReDQC Performance and Stability was the

requirement importance for the stakeholders, which meant that all stakeholders were

required to be present during prioritization session.

Multiple techniques exist for prioritization, but many organizations use a three-level

prioritization scale. A variation of Single-Criterion Classification technique has been adapted

by GfK Retail and Technology GmbH since 2009, which classifies requirements with respect

to the importance of the realization of the requirements for the system’s success

(Engineering 1998b).

The adopted version of prioritization meant that each requirement was assigned to one of the

following priority classes:

Priority 1 – mandatory or must have

Priority 2 – should have

This technique was adapted due to its effectiveness and less required time and efforts than

other techniques like Prioritization Matrix According to Wiegers12.

Meyer explained all aspects of prioritization importance in his reply to the stakeholder, and

also mentioned that he will explain further details of that process during their meeting.

The prioritization took place on 20th of December and lasted around two hours, during which

the stakeholders successfully reviewed and prioritized all the requirements. This meeting

also helped to reveal and a number of duplicate requirements from the product requirements

document.

12

An analytical prioritization approach for requirements.



2.10 Peer review

The hardest work was done - business requirements were gathered, reviewed and

prioritized. Meyer could now prepare the PRD document for the final review and hopefully

soon get a sign off. He already updated the documentation with the latest changes from the

prioritization session and was almost ready to send it over. However, according to the

company business analysis process, before the sign off, the PRD required first peer review13.

Peer review in this case was an internal review within Business Liaison department by other

business analysts. The business analyst college checked the ReDQC PS product

requirements document for errors, incompleteness and inconsistencies according to the

confirmed checklist:

- Technical mistakes

- Grammar mistakes

- Consistency

- Use cases

- Constraints

- Narratives

- User interfaces

As soon as the PRD passed peer review, Meyer notified the ReDQC Performance and

Stability BO and stakeholders about upcoming final requirements review and sign off.

Besides stakeholders and BO the PRD review, following the company process, had to be

performed by functional architect Martina Schwarz, development process manager Gregor

Fischer, technical project lead Katrin Richter, and test lead Frank Braun. The requirements

and PRD can be handed over for development only after it has been formally signed off by all

reviewers.

2.11 Final review and Sign Off

On Monday the 9th of January Michael Meyer sent the ReDQC Performance and Stability

product requirements document for final review and sign off. All of the review parties had to

agree on the requirements. According to IEEE Standard, a requirement is agreed upon if it is

correct in the opinion of all stakeholders and all stakeholders accept it as valid (Engineering

1998b).

13

Review method employed to maintain standards, improve performance and provide credibility and determine an

academic paper's suitability for publication.



“Dear All,

The PRD document for ReDQC Performance and Stability is ready for your final review.

Please find attached the latest document version, otherwise it could be found on the

StarTrack share point, under the ReDQC project folder.

In case of no objections on the requirements and PRD document please send me your

formal sign off by the end of review. In case of any questions please do not hesitate to

contact me.

I appreciate your cooperation and thank you all for the support and help.

Best Regards,

Michael Meyer”

As soon as the email was sent Michael Meyer started to think and analyze whether he has

done everything right. All his actions were performed in accordance with the business

process, but were the process ideal or there is still room for perfection? What could have

been done better?



3 STRUCTURED SUMMARY

This chapter gives an overview of the concepts and theoretical materials relevant to the

business case.

3.1 Requirements Engineering

How to work out requirements? In order to make a software development project succeed, it

is necessary to know the requirements for the system and to document them in a suitable

manner. The systematic approach to this is called Requirements Engineering.

The goals of requirements engineering is to define the relevant requirements, achieve a

consensus among the stakeholders about these requirements, document requirements in

accordance with given standards, and systematically manage them It is crucial to avoid

building software that works, but doesn’t work for the people using it. Four core activities of

requirements engineering aim to support these goals: Elicitation, Documentation, Validation,

and Management.

Requirements engineering phase is embedded in the software development model practiced

in the project, and by that it influence the way requirements are worked out. It is seen as a

self-contained phase in case of Waterfall model or V-Model. Namely these models goal is to

complete requirements eliciting, analysis and documentation in an early project phase,

before the design and realization decisions are made. In another words working out

requirements prior to the development phase is aimed. Therefore, requirements engineering

is distinguished as a finite, time-restricted initial system development phase.

On the other hand, in agile models like eXtreme14 Programming, requirements engineering is

considered to be a continuous, complementary process. Since it is difficult to predict future

functionalities and requirements change over the course of the project, only necessary

requirements elicitation is performed once they are supposed to be implemented. In these

process models, system development phase comprises and integrates requirements

engineering as a continuous and comprehensive process.

V-Model is practiced by GfK Retail and Technology GmbH; therefore, working out

requirements within StarTrack project is also considered as a finite and time constrained

phase in system development.

14

A type of agile software development methodology, intended to improve software quality and responsiveness to

changing customer requirements.



3.1.1 Key players

As well as in any other processes there is certain group of key players in the requirements

engineering performing particular activities. Major players in working out requirements at GfK

Retail and Technology GmbH and in particular for ReDQC PS project are business analyst

performing role of requirements engineer and stakeholders.

First of all as soon as the stakeholders are defined it is necessary to agree upon mutual

rights and responsibilities of the stakeholders and the requirements engineer in order to

facilitate communication and cooperation and to successfully integrate the stakeholders into

the elicitation process.

3.1.1.1 Requirements Engineer

The central role in working out requirements is the requirements engineer, in the given case

executed by business analyst. Basically he/she is the mediator between stakeholders and his

duty is to actively engage stakeholders in defining requirements. Requirements engineer

identifies the needs lying behind the stakeholders’ statements, and then amends them in

form of requirements so that architects and developers can understand and implement them.

It is the task of requirements engineer to gather, document and consolidate requirements of

different stakeholders. Hence, a requirements engineer has to possess excellent

communication and moderation skills, analytical thinking and be able to grasp IT knowledge

and understand the domain, and of course ability to adjust both to business users and IT

specialist language.

3.1.1.2 Stakeholders

Identifying the relevant stakeholders is a central task of requirements engineering. It is

especially relevant for ReDQC PS project, since stakeholders are legitimate and major

source of requirements.

Stakeholder definition: An individual, group of people, organization or other entity that has

a direct or indirect interest in a system (Hull et al. 2011).

The stakeholders in ReDQC PS project included: project business owner, business users,

domain specialists, business group director, managers.

Stakeholder’s interest may be stipulated by the form of his/her involvement and interaction

with the system i.e. system usage, benefits or disadvantage from the system in any form,

responsibility for the system or any other form of affect.



3.1.2 How to handle stakeholders

It is very important to collect stakeholder’s relevant information: name, title/position, contact

information, project requirements/expectations, and stakeholder’s type internal or external.

Meetings with stakeholder, ideally in person, should be well planned and prepared. The

introduction to the interview and the questions itself should be prepared in advance. In order

to build trust with stakeholders it is necessary to let them get to know the BA.

Communication plan shared with the stakeholders would be an advantage i.e. regular

meetings, via email, conference calls, and how often i.e., weekly, monthly, quarterly.

3.2 Eliciting Requirements

3.2.1 Requirement

Before getting into details of requirements elicitation it would be helpful first to define what a

requirement actually is.

According to IEEE-STD-1220-1998 (Engineering 1998a) requirement is a statement that

identifies a product or process operational, functional, or design characteristic or constraint,

which is unambiguous, testable or measurable, and necessary for product or process

acceptability (by consumers or internal quality assurance guidelines).

In other words requirements could be interpreted as criteria, constrains, directives, needs,

regulations, rules, etc. Three general types of requirement could be distinguished: functional

requirements, quality requirements, and constraints. Functional requirements specify the

functionality offered by future developed system. These requirements could be also divided

into functional requirements, behavioral requirements, and data requirements.

Aimed qualities of the system to be developed like performance, availability, dependability,

portability or scalability are defined by quality requirements, or in other words non-functional

requirements. This type of requirements is the main focus of the ReDQC PS project

described in the case.

The last type of requirements is constraints – it limits the solutions and design alternatives

necessary for meeting the given functional and quality requirements. This type of

requirements is not implemented and can constrain the system itself or the development

process.



Additionally to the above named classification, a number of different classifications of

requirements are used in practice. Namely/ for instance following types of requirements are

defined within StarTrack project at GfK Retail and Technology GmbH: Functional, Non-

Functional, Look and Feel, Usability, Accessibility, Performance, Operational and

Environmental, Maintainability and Support, Security, Cultural and Political, and finally Legal

requirements.

3.2.2 Requirements Elicitation

Requirements elicitation or simply discovering of the requirements is the process of system

requirements collection from stakeholders, i.e. users and customers. Though, stakeholders

are not always the only source of requirements.

In case of stakeholder’s involvement certain activities should be realized before requirement

elicitation. A range of introduction (kick off) meetings, calls and conferences should be

performed where the stakeholders will get necessary information and instructions related to

the project and its goals.

3.2.3 Sources of requirements

Depending on the project three different kinds of requirements sources are generally defined:

stakeholders, documents, and system.

Stakeholders are represented by people or organizations that affect the requirements of a

system, for instance customers, system users, developers, architects, and testers. Within

ReDQC PS project stakeholders were represented by business owner, domain specialists,

and system users, and were basically the most important source of requirements.

Documents like standards and legal documents, domain- or organization-specific documents,

usually provide important information that can initiate requirements.

Systems in operation, in our case ReDQC, can be another source of requirements. Based on

the experience in working with the system, users can request changes or extensions.

In the described case stakeholders and system in operation ReDQC are main sources of

requirements.

3.2.4 Requirements discovery technique

It is necessary to decide on the technique to actually discover requirements. And this

decision depends on many factors, for instance time and budget constraints, as well as



stakeholder’s availability, experience of the business analyst with a specific elicitation

technique, or project risks. The choice of the right elicitation technique for the respective

project is made by the requirements engineer based on the given cultural, organizational,

and domain-specific constraints. There are no universal methods to discover requirements,

though combination of appropriate techniques can help to achieve the aimed result.

All existing techniques could be grouped into interactive and passive technique. Interactive

are interviews, workshops, meetings. Passive techniques include prototypes, observations,

documentation study.

3.2.4.1 Survey technique

Survey technique includes methods for eliciting explicit knowledge, namely these are

interviews and questionnaires. This type of technique aims at obtaining as precise and

objective statements as possible from stakeholders regarding their requirements. Survey

technique imply that the respondent obtains required knowledge and capable of sharing it, as

well as committed to invest time and efforts.

Within ReDQC PS project elicitation was performed mainly by means of interview technique

driven by the business analyst. This method was used due to the fact that the project was

initiated based on the ReDQC users’ requests for performance improvement. Therefore

close communication with the stakeholders could highly support requirements elicitation

process.

ReDQC PS groups of stakeholders numbered less than ten people, hence the questionnaire

method was considered to be not necessary, since it implies a large number of participants

that must be surveyed.

3.2.4.2 Creativity technique

Creativity techniques serve to establish innovative requirements by means of brainstorming,

change of perspective, and analogy methods. Though, these methods are usually not well

suited for defining fine-grained requirements about the system behavior. Therefore these

methods were not applied during eliciting requirements within ReDQC PS project.

3.2.4.3 Documentation centric technique

This technique supportive in reuse of experiences and solutions gained from existing legacy

systems. Especially in case a system is replaced it guarantees that the entire functionality of

the legacy system is defined. However other elicitation techniques should be combined with

document-centric when new requirements for the new system have to be identified.



This technique comprises: system archaeology, perspective based reading, and reuse

methods. Documentation centric technique was effectively applied to refresh the knowledge

about existing functionalities during eliciting new ReDQC requirements.

3.2.4.4 Observation technique

This technique is used when the domain specialists are not able to spend enough time with

requirements engineers for interviews. During observation, the requirements engineer has

possibility to observe the stakeholders while they go about their work. This technique has

also been applied in the described project with the purpose to observe and record ReDQC

performance characteristics.

Usually this technique is fulfilled via field observation and apprenticing methods, where

apprenticing implies that the requirements engineer learn and perform the procedures of the

domain specialist.

3.2.4.5 Support technique

Support techniques are used as addition to other elicitation techniques and include: mind

mapping, workshops, CRC cards, audio and video recording, modeling action sequences,

prototypes. Though these techniques are only complementary, some of them might greatly

help in discovering requirements for instance using visualization.

Use case modeling is used to represent a functionality that must be supported by the

systems to be developed. Prototypes are helpful to define requirements in case when

stakeholders have no strong understanding of what is to be delivered. Another support

technique is workshop. It assists in elaborating the goals or certain functionalities of the

system during a joint meeting of requirements engineer and stakeholders.

Both workshops and use case modeling methods are often used during StarTrack projects in

support to the main eliciting techniques. In terms of ReDQC project none of these methods

were applied since new functionalities were not in project scope.

3.3 Documenting Requirements

Information that has been obtained and worked out during various performed activities must

be documented in a proper way. This information includes interview protocols, reports,

agreements, change requests, but most important requirements.

The central document in business analysis phase within StarTrack is called Product

Requirements Document (or PRD). It is created and amended by business analyst



(requirements engineer) assigned for given analysis. It comprises not only the collection of

defined during elicitation phase requirements but also serves to give an overview of project

scope, objectives, stakeholders, analysis of current and target process situation, as well as

derived use cases. It aims to support the project goals and to guarantee common

understanding of all project members.

3.3.1 Requirements documentation in Natural Language

Product Requirements Document is created by means of natural language; most commonly

applied documentation form for requirements, practiced by many organizations. Natural

language or prose has a great advantage for stakeholders, it exclude the need to learn a new

notation form. Moreover, it can be used to express any kind of requirements.

All collected during elicitation phase requirements within ReDQC PS project are also

constructed by means of natural language with the help of predefined requirements template.

Initially developed by SOPHIST GmbH, consulting and training company, approach has been

adopted and integrated into the GfK Retail and Technology GmbH business analysis

processes.

A requirement template is a generic, syntactical requirements template is the blueprint that

determines the syntactical structure of a single requirement (Please see Figure 9).

This requirements construction approach follows five steps process:

Step 1: Define the process (functionality) introduced by a verb, the central point of a

requirement (for instance prints, save, calculate). A verb plays very important role, because

the whole requirement is connected to this process word. Therefore it is of high importance

to determine the required process in the beginning of the requirement building process.

Step 2: Characterize the activity of the system, as the way the system works is closely linked

to the verb defining process/functionality.

According to the adopted approach three types of system activities are defined:

- The system carries out the process by itself – independent system activity;

- The system provides the user with process functionality – user interaction;

- The system carries out the process dependent on a third factor (for e.g. a different

system), remains passive and waits for an external event – interface requirement

(Please see Figure 8).



Step 3: The third step defines the level of importance with the help of “needs to”, “shall” or

“must”, which completes the core of the requirement and emphasizes the legal relevance.

Initial three steps support construction of basic requirement structure:


to print.

Step 4: Determine precisely the process by introducing the missing object. In the example

requirement is not clear what is to be printed and where it is to be printed to.


to print the error message to the network printer.

Step 5: The logical or temporary condition is to be defined, under which the functionality is

performed. These constraints are located at the beginning of a requirement. Though, the

conditions are not mandatory (Please see Figure 10).

E.g. Basic requirement version 3: If an error message has been generated, the system

needs to provide the administrator the ability to print the error message to the network

printer.

In spite of many advantages of natural language described above, its usage can bring

disadvantages in form of requirements ambiguity and in risk to mix up different types of

requirements during documentation.

3.3.2 Requirements documentation in conceptual models

In comparison to natural language, the conceptual models illustrate the documented

requirements much more compactly and a trained reader can easier understand them.

Moreover, conceptual models cite less ambiguity (i.e., fewer ways to be interpreted)

than natural language due to their higher degree of formality.

However, using conceptual modeling languages for requirements documentation requires

specific knowledge of modeling and different types of conceptual models cannot be used

universally as natural language. When documenting requirements by means of models,

special modeling languages must be used that belong to the appropriate requirement

perspective (data, functional or data perspective).

Each of the diagram types suites a particular purpose. For instance a use case diagram

allows getting a brief overview of the specific system functionalities and how these

functionalities relate other external interacting entities.



Class diagrams are used to document requirements with regard to the static structure of

data, to document static-structural dependencies between the system and the system

context or to document complex domain terms in a structured manner.

Activity diagrams are suited to model the sequential character of use cases or to model a

detailed specification of the interaction of functions that process data and also for process

modeling.

In reality, documents contain a combination of natural language and conceptual models. This

mixture allows reducing the disadvantages and grants the advantages of both documentation

types. For instance, models can be amended or complemented by natural language

comments and natural language requirements and glossaries can be summarized, while their

dependencies can be depicted clearly by models means.

Likewise this hybrid approach is practiced by GfK RT GmbH. The conceptual models are

widely used along with natural language for requirements documentation purpose within

StarTrack projects at GfK RT GmbH, namely Use case, Class, and Activity diagrams are

engaged.

3.3.3 Glossary

To avoid conflicts in requirements engineering related to different interpretations of terms by

people that are involved in the development process, it is necessary to make sure that

everyone shares the same understanding of the used terminology. Therefore, all relevant

terms must be defined in a common glossary. A glossary is a collection of term definitions

and contains the following elements:

Context-specific technical terms

Abbreviations and acronyms

Everyday concepts that have a special meaning in the given context

Synonyms, i.e., different terms with the same meaning

Homonyms, i.e., identical terms with different meanings

Within StarTrack projects glossary’s creation is a duty of the in charge for business analysis

BA. After glossary is created it is usually available for other team members’ access and

reuse.



3.4 Requirements validation

Validation during requirements engineering is extremely important and meant to ensure that

the documented requirements meet the predetermined quality criteria, such as correctness

and agreement by every involved stakeholder.

3.4.1 Why requirements validation

To ensure that the stakeholder’s actual wishes and needs are met and to identify deviation

between defined requirements it is necessary to review the quality of the developed

requirements. During validation meetings the requirements are presented to the

stakeholders, where it is decided whether the requirements possesses needed quality level

and whether they can be approved for further usage.

Another goal of requirements validation is to discover error and requirements defects on the

early stage. Early validation of requirements can:

Reduce the requirement writing time

Reduce the time and effort of a formal review

Ensure you get the important feedback in a formal review

Reduce rework for requirements misunderstood by designers

Reduce retest required for requirements misunderstood by testers

Reduce the number of problems found by users

Result in a shorter development cycle with a higher quality product

The quality of the validation results can be increased by involving relevant stakeholders,

separating the identification and the correction of errors into tasks apart, validation of the

requirements from different user’s views/perspectives, and by performing repeated

validation.

3.4.2 Requirements validation techniques

Following three major types of reviews can be differentiated:

Commenting – during individual validation the requirements are handed over to another

person (e.g. co-worker). In terms of ReDQC PS project this type of review was called peer-

review and has been applied for review of the whole PRD document, including requirements.



Inspections - an inspection session usually serves the purpose of collecting and evaluating

error indications, and requires a thorough preparation and is typically divided into various

phases (planning, overview, error detection, and error collection).

Walk-through - is a lightweight version of a review, less strict than an inspection and the

involved roles are differentiated to a lesser degree.

Besides that manual validation techniques, which are also known by the general

term review, were widely used for requirements validation within ReDQC PS project.

3.5 Requirements Management

Requirements management comprises tasks like prioritizing requirements, tracing

requirements as well as versioning requirements and managing requirement changes.

Requirements management is relevant both for individual requirements as well as complete

requirements documents.

To support requirements management, information about the requirements must be

documented along the entire life cycle of a system. This comprises requirement unique

identifiers, its name, the author and sources of the requirement (i.e. workshops, reviews

meetings, emails, etc.), and the person responsible for the requirement.

3.5.1 Why prioritizing requirements

At GfK Retail and Technology GmbH prioritization is mainly used to determine importance

degree of a software product requirement therefore to support decision whether it should be

included in a particular release and further it supports the implementation order, to minimize

risk during development.

Before starting requirements prioritization a goal or in other words the purpose of

prioritization must be defined. In the given business case prioritization aimed to define the

level of importance of the delivered requirements, i.e. critical for improvement of ReDQC

performance and stability. Additionally, relevant and available stakeholders should be

defined for this activity.

The criterion for prioritization, or a combination of several criteria should be chosen and

documented as well. Typical criteria are: cost of implementation, risk, importance, duration of

implementation, etc. In our case the main criteria for requirements prioritization was

importance for ReDQC users.



3.5.2 Prioritization techniques

Within ReDQC PS project the technique of Single-Criterion Classification has been mainly

used. This technique classifies requirements with respect to the importance of the realization

of the requirements for the system’s success. According to chosen prioritization technique

each requirement must be assigned to one of the following priority classes:

Priority 1 – mandatory or must have

Priority 2 – should have

However, there are many other techniques like, Ranking, Top-Ten techniques, Kano

classification, and prioritization matrix according to Wiegers. The choice of prioritization

technique depends on such factors like time and efforts needed and project properties.

3.6 Analysis and improvements strategy

The given case is an example of Business Analysis process which demonstrates how the

software requirements were worked out in reality. The process itself was working perfectly

fine, nevertheless there is always possibility to do something better.

Several weaknesses of the described business analysis process could be emphasized. First

of all, the whole process of working out requirements was based on manual work, i.e.

activities that could be automated, like PRD creation, were performed manually. Second,

limited access to the requirements exclusively via PRD stored in Share Point. Third, the PRD

documents were too voluminous, which was the reason why the intermediate requirements

and documents review have not always taken place in time. Another minus of the business

analysis process that impeded the speed of PRD creation was that the current situation

processes had to be visualized from scratch for every initiated project, instead of reuse of

unified existing processes (for instance, the process of legacy systems).

Based on the listed problems there are two types of improvements that could be proposed

and combined: first is to improve the process itself and the second is to support the process

by integrating complementary tools.

3.6.1 Suggestions for process improvement

Following actions could reinforce the existing process and make it more efficient:

- Reduce the volume and length of the PRD document which will ease the review

process and its further usage during following delivery phases.



- Introduce mandatory intermediate reviews both of the requirements and the whole

document which will improve the quality of the requirements, reduce the risk of

requirements defects and make the final review and sign off easier.

- Introduce unified requirements patterns which will support faster requirements

construction by their reuse.

- The unified processes of StarTrack legacy systems could be created, stored and

reused, i.e. the business process should be once visualized by means of e.g. UML,

approved and located for future common reuse within business analysis team. Which

will improve process traceability; reduce time and efforts for constant process

reconstruction.

3.6.2 Requirements engineering tools

Different activities of requirements engineering should be supported by appropriate tools that

ideally integrate and continue processing the already existing information generated during

working out requirements.

During the project in the given case all defined requirements were collected and stored in a

single document – Product Requirements Document. The PRD was created in MS Word,

while MS Excel has been used during the actual phase of requirements collection. The PRD

document has been located and available for further software delivery phases in the relevant

project’s Share Point, where document’s status and version could be tracked as well. Hence

Share Point, MS Word, and MS Excel were basically the main tools used for managing

requirements.

These tools could be considered as basic when comparing them to nowadays available

range of requirements management tools that highly support requirements engineering

process in different ways. There are many reasons why special tools could be used for

working out requirements within GfK Retail and Technology GmbH.

3.6.3 Tools’ benefits

These tools allow management of the requirements in a database and provide automated

traceability functions, by enabling creation of electronic links between parent and child

requirements as well as between test cases and requirements. Version control and change

management are also supported.

Structured Requirements: Requirements management tools supports gathering

requirements and define attributes needed to track each requirement, such as Requestor,

Date, Owner, etc.



Save Time: Automation of tasks like requirements document creation, traceability and other

tasks can reduce time when it comes to managing your requirements.

Access and Traceability: A requirements management tool enables usage of unified

requirements patterns stored in the supporting tool, for a faster requirements construction

and further reuse. More visibility and transparency in tracking the RM stage (how many

requirements approved, created, deleted, etc.).

Workflow and Best Practices: Most of the RM tools possess built-in workflow and best

practices for requirements management related tasks.

Easy to Collaborate: The requirements management tool enables possibility to collaborate

with internal and external stakeholders. Unique location (single point of access) with

management possibilities, which helps to avoid documents and requirements access

problems (check in/ checkout).

3.6.4 Proposed tools

Spark Systems Enterprise Architect: One of the tools that could be used is Enterprise

Architect, which is already widely used within StarTrack GfK Retail and Technology by

Business Analysis department for modeling use cases and processes. Enterprise Architect

could be integrated not only for the benefit of Business Analysis but also for the whole

software development process as it supports common features of Requirements

Management like customization of requirements documentation, linking requirements to the

further design and implementation details which support the traceability through all project

phases. It would be strategically wise to continue using the tool that team is already

acquainted with (Sparxsystems).

IBM Rational DOORS: Requirements management software for complex and embedded

systems, which enables users to capture, trace, analyze and manage requirements changes.

This tool is claimed to be highly intuitive and collaborative, supporting powerful requirements

traceability. Rational DOORS maintains documents generation as well as ability to exchange

requirements data with other requirements management tools. This tool supports

requirements-driven testing with built-in test tracking tool, and integrations with Rational

Quality Manager and HP Quality Center (IBM).

At the time when the case was written there was no defined final solution or confirmed

strategy for business analysis process improvement. Taking in consideration the active

usage of Enterprise Architect it would be wise to follow the hybrid improvement strategy,



process activities amendment in combination with extensive supportive requirements

management tools integration.



4 CLASS DISCUSSION GIUDE

This chapter provides an instruction for the case discussion together with the questions

relevant to the thesis topic and described in previous chapter concepts and theory.

This case is about the requirements engineering process and the difficulties one can face

during working out software requirements. A well-defined process is not always enough for a

successful result. Along following the requirements engineering process steps it is necessary

to have supportive efficient tools and of course good communication level. Each of these

factors will help to keep transparency within the project.

4.1 Background

As an introduction of the case follow the given questions related to the company background.

In this way the students will have possibility to review information related to the company

business.

4.1.1 Who/what is GfK Group?

Market Research Organisation - Gesellschaft für Konsumforschung

4.1.2 What is the relation of GfK Retail and Technology to GfK Group?

GfK Retail and Technology GmbH, a market research company which provided sales

reporting for technical consumer goods markets, has been founded by GfK Group in 1970.

4.1.3 What is GfK Retail and Technology’s product?

StarTrack reporting system - provided retail and technology market sector information

ReDQC is the compliant system of the StarTrack – performs raw data quality check

4.1.4 What is the GfK Retail and Technology product management

approach?

In house software development

Follow mainly V-Model

Strong focus on market research technologies



4.1.5 Difference of V-Model and Agile in regard of RE process

V-Model implies eliciting and documenting all requirements completely in an early

project phase before design and development phase

In Agile models requirements engineering is a continuous, iterative complementary

process

4.2 Requirements Engineering

4.2.1 What are the main activities of requirements engineering?

Requirements Elicitation, Documentation, Validation and Management

4.2.2 Key players of the requirements engineering

Requirements engineer – performed by Business Analyst

Stakeholder – performed by project business owner, business users, domain

specialists, business group director, managers

4.2.3 What is their role of a Stakeholder in product development?

Stakeholders are legitimate and major source of requirements

With direct or indirect interest in the developed system

4.3 Elicitation

4.3.1 What is requirements elicitation?

Discovering of the requirements, i.e. the process of system requirements collection

Introduction (kick off) meetings, calls and conferences are the “must do”

4.3.2 What is a requirement?

Criteria, constrains, directives, needs, regulations, rules, etc.

Three general types could be distinguished: functional requirements, quality

requirements, and constraints

Non-Functional requirements were in the focus of the given case

4.3.3 What sources of requirements are described in the case?

Stakeholders - represented by business owner, domain specialists, and system users



System in operation - ReDQC

4.3.4 What other sources of requirements and techniques could be defined?

Documents like standards and legal documents, domain- or organization-specific

documents

Techniques – survey (interviews and questionnaires), creativity (brainstorming,

change of perspective, analogy), documentation centric, observation, support

technique (mind mapping, workshops, audio and video recording, and prototypes)

4.4 Requirements documentation

Product Requirements Document - central document in business analysis phase

Documentation in Natural Language and in conceptual models

4.4.1 How were the requirements built?

By means of predefined requirements template developed by SOPHIST GmbH

Requirements construction approach follows five steps process:

o Define the process (functionality) introduced by a verb

o Characterize the activity of the system

o Define the level of importance via “needs to”, “shall” or “must”

E.g. Basic requirement version 1: The system needs to provide the

administrator the ability to print.

o Determine precisely the process by introducing the missing object

E.g. Basic requirement version 2: The system needs to provide the

administrator the ability to print the error message to the network printer.

o Define logical or temporary condition

E.g. Basic requirement version 3: If an error message has been generated,

the system needs to provide the administrator the ability to print the error

message to the network printer.

4.4.2 Why documenting glossary, meeting minutes, meeting protocols?

To avoid conflicts related to different interpretations of terms

Keep track of changes

4.5 Requirements validation

Iterative requirements and documentation validation



Validation techniques –commenting, review, inspection, and walk-through

4.6 Requirements management

Prioritization - define the level of importance of the delivered requirements

Technique of Single-Criterion Classification applied within ReDQC

Other techniques - Ranking, Top-Ten techniques, Kano classification

4.7 Problems being faced

PRD creation too tedious and time consuming process

Stakeholders’ review feedback delays – too big PRD volume

Not full involvement of the stakeholders in the business analysis – daily overload

Misunderstandings in requirements definition – due to language issues

Delays in requirements prioritization

Changing demands – changing company’s strategies

Lack of transparency between stakeholders

Limited access to the requirements

4.8 Proposed solution

Reduce manual work amount like document creation by introducing supporting tools:

o Requirements Management tools

o Introduce unified requirements patterns

o Enforce requirements/documents changes traceability

Reduce the volume and length of the PRD document

Introduce mandatory intermediate reviews both of the requirements and PRD

Escalate the review delays and weak stakeholder involvement immediately to BO

Introduce unified legacy systems’ processes storage for further reused

4.9 Main question: What should GfK Retail and Technology do?

How can the business analysis process be improved?


Licensed CC-BY-3.0 VII

APPENDIX

Protagonist

Mr. Michael Meyer Business Analyst

Mr. Meyer studied Business Administration at the University of Bamberg and later Business

Informatics at the University of Tübingen where he started his working career as a software

developer.

After eight years of software development Mr. Meyer decided to try

himself in software business analysis. In 2005 he began working as

business analyst in a German medium sized software development

company. In 2010 Mr. Meyer came to the GfK Retail and Technology

as an experienced business analyst. He led business analysis for a

number of different sized projects within StarTrack project.


Licensed CC-BY-3.0 VIII

Figure 12: StarTrack Organogram

Table 1: Main causes of project failure according to Standish Group

Table 2: Requirements engineering defects cost


Licensed CC-BY-3.0 IX

BIBLIOGRAPHY

Aurum 2005 Aurum, A., & Wohlin, C. (Eds.). (2005). Engineering and Managing

Software Requirements (p. 69–94). Berlin/Heidelberg: Springer-Verlag.

doi:10.1007/3-540-28244-0

Bell 1976 Bell, T. E., & Thayer, T. A. (1976). Software Requirements: Are they

Really a Problem?

Berander 2005 Berander, P., & Andrews, A. (2005). Requirements Prioritization. (A.

Aurum & C. Wohlin, Eds.)Engineering and Managing Software

Requirements, (November), 69–94. doi:10.1007/3-540-28244-0

Biffl et al. 2006 Biffl, S., Winkler, D., Reinhard, H., & Wetzel, H. (2006). Improvement in

Europe : Issues, 229–238. doi:10.1002/spip

Boehm 1981 Boehm, B.W. (1981). Software engineering economics. Englewood Cliffs:, Prentice Hall

Boehm 1988 Boehm, B. W., & Papaccio, P. N. (1988). Understanding and controlling

software costs. IEEE Transactions on Software Engineering, 14(10),

1462–1477. doi:10.1109/32.6191

Damian 2001 Damian, D., & Sridhar, N. (2002). International Workshop on Global

Software Development.

Early 1986 Early, M. (1986). Relating software requirements to software design.

SIGSOFT Softw. Eng. Notes, 11(3), 37-39.

Engineering 1998a Engineering, S., & Committee, S. (1998). IEEE Standard for

Application and Management of the Systems Engineering Process

(Vol. 1998).

Engineering 1998b Engineering, S., & Committee, S. (1998). IEEE Recommended

Practice for Software Requirements Specifications (Vol. 1998).

Hull et al. 2011 Hull, E., Jackson, K., & Dick, J. (2011). Requirements

Engineering (Google eBook) (p. 207). Springer. Retrieved from

http://books.google.com/books?id=5xREIrqnDQEC&pgis=1


Licensed CC-BY-3.0 X

Iba 2009 Iba, & Brennan, K. (2009). A guide to the Business Analysis Body of

Knowledge (BABOK guide), version 2.0 (p. 272). IIBA. Retrieved from

http://books.google.com/books?id=CFHw8jSEWwkC&pgis=1

IBM IBM - Rational DOORS: Requirements management for complex

systems and software development. Retrieved September 4, 2012,

from http://www-

01.ibm.com/software/awdtools/doors/features/?S_CMP=wspace

Karlsson 1996 Karlsson, J., & Ryan, K. (1996). Supporting the selection of software

requirements. Proceedings of the 8th International Workshop on

Software Specification and Design, 146–149.

doi:10.1109/IWSSD.1996.501157

Lauesen 2002 Lauesen, S. (2002). Software Requirements: Styles & Techniques (p.

591). Pearson Education. Retrieved from

http://books.google.com/books?id=6Yu7s6XOV8cC&pgis=1

Lederer 1986 Lederer, A. L. (1986). What the Human Resources User Wants.

Proceedings of the twenty-second annual computer personnel

research conference on Computer personnel research conference, 43–

52. Retrieved from

http://onlinelibrary.wiley.com/doi/10.1002/cbdv.200490137/abstract

Martin et al. 2007 Martin, D., Rooksby, J., & Rouncefield, M. (2007). Users as contextual

features of software product development and testing. Proceedings of

the 2007 international ACM conference on Conference on supporting

group work - GROUP ’07, 301. doi:10.1145/1316624.1316670

Oberg 2000 Oberg, R., & Ericsson, M. (2000). Applying Requirements

Management.

Pohl 2011 Pohl Klaus, & Rupp Chris. (2011). Requirements Engineering

Fundamentals: ProQuest Tech Books. Rocky Nook. Retrieved from

http://proquest.safaribooksonline.com/9781933952819

Rubinstein 2007 Rubinstein D. (2007) Standish Group Report: There’s Less

Development Chaos Today - SD Times: Software Development News.


Licensed CC-BY-3.0 XI

(n.d.). Retrieved September 15, 2012, from

http://www.sdtimes.com/content/article.aspx?ArticleID=30247

Ruppa Rupp, C. (n.d.). The Requirements Template – The Assembly Plan of a

Requirement, 225–251.

Ruppb Rupp, C., & Patterns, R. (n.d.). Requirements Templates — The

Blueprint of your Requirement.

Requirements Management School 2010 Benefits of Requirements Management Tool -

Requirements Management School. (n.d.). Retrieved September 8,

2012, from

http://www.requirementsmanagementschool.com/w1/Benefits_of_Requ

irements_Management_Tool

Sparxsystems UML tools for software development and modelling - Enterprise

Architect UML modeling tool. (n.d.) Retrieved September 6, 2012, from

http://www.sparxsystems.com/

Weekly 2010 The importance of requirements in Software Design | Shawn Weekly @

Sidmand Consulting. (n.d.). Retrieved November 12, 2012, from

http://blog.sidmand.com/2010/04/importance-of-requirements-in-

software.html

Wiegers 2009 Wiegers, K. E. (2009). Software Requirements (Vol. 2009, p. 544).

O’Reilly Media, Inc. Retrieved from

http://books.google.com/books?id=WcO3Ca9NuvQC&pgis=1

Wikipedia V-Model (software development) - Wikipedia, the free encyclopedia.

(n.d.). Retrieved August 8, 2012, from http://en.wikipedia.org/wiki/V-

Model_(software_development)

Wikipedia Peer review - Wikipedia, the free encyclopedia. (n.d.). Retrieved

August 8, 2012, from http://en.wikipedia.org/wiki/Peer_review

Zowghi 2002 Zowghi, D., Does Global Software Development Need a Different

Requirements Engineering Process?, Proceedings of International

Workshop on Global Software Development – ICSE 2002, Orlando,

Florida, USA, 2002, 53-55.

http://en.wikipedia.org/wiki/Peer_review

Plagiarism Declaration

I hereby declare that, to the best of my knowledge and belief, this Master Thesis titled

“Business Case: How to work out Requirements?” is my own work. I confirm that each

significant contribution to, and quotation in this thesis from the work, or works of other people

is indicated through the proper use of citations and references.

Ich versichere, dass ich die Arbeit mit dem Titel “Business Case: How to work out

Requirements?” ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen

Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner

anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung

angenommen wurde. Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden,

sind als solche gekennzeichnet.

Nürnberg, 28.01.2013

Maria Arcus

Business Case: How to work out...

Documents

Transcript of Business Case: How to work out...