1. law, govt and politics
2. legal issues
3. legislation
4. building laws

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: arcush@gmail.com
Time Frame: 1.8.-01.02.2013
Business Case: How to work out Requirements?
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.
II
Business Case: How to work out Requirements?
CONTENTS
ABSTRACT ........................................................................................................................... II
TABLES ................................................................................................................................ V
ACRONYMS ........................................................................................................................ VI
1
INTRODUCTION ............................................................................................................ 1
2
BUSINESS CASE: HOW TO WORK OUT REQUIREMENTS? ...................................... 2
3
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
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
III
Business Case: How to work out Requirements?
3.4.1
Why requirements validation ...........................................................................33
3.4.2
Requirements validation techniques ................................................................33
3.5
3.5.1
Why prioritizing requirements ..........................................................................34
3.5.2
Prioritization techniques ..................................................................................35
3.6
4
Requirements Management ...................................................................................34
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
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
IV
Business Case: How to work out Requirements?
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
V
Business Case: How to work out Requirements?
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
VI
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.
1
Business Case: How to work out Requirements?
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.
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
Licensed CC-BY-3.0
2
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
3
Business Case: How to work out Requirements?
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
6
This section draws heavily from “Starting Out”, http://www.gfk.com.
The amount of goods or services that can be purchased with a unit of currency.
Licensed CC-BY-3.0
4
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
5
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
6
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
7
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
8
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
9
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
10
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
11
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
12
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
13
Business Case: How to work out Requirements?
“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).
Licensed CC-BY-3.0
14
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
15
Business Case: How to work out Requirements?
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
Licensed CC-BY-3.0
16
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
17
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
18
Business Case: How to work out Requirements?
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.
E.g. Basic requirement version 2: The system needs to provide the administrator the ability
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).
Licensed CC-BY-3.0
19
Business Case: How to work out Requirements?
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
Licensed CC-BY-3.0
20
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
21
Business Case: How to work out 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.
Licensed CC-BY-3.0
22
Business Case: How to work out Requirements?
“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?
Licensed CC-BY-3.0
23
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
24
Business Case: How to work out 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.
Licensed CC-BY-3.0
25
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
26
Business Case: How to work out Requirements?
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, NonFunctional, 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
Licensed CC-BY-3.0
27
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
28
Business Case: How to work out Requirements?
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
Licensed CC-BY-3.0
29
Business Case: How to work out Requirements?
(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).
Licensed CC-BY-3.0
30
Business Case: How to work out Requirements?
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:
E.g. Basic requirement version 1: The system needs to provide the administrator the ability
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.
E.g. Basic requirement version 2: The system needs to provide the administrator the ability
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.
Licensed CC-BY-3.0
31
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
32
Business Case: How to work out Requirements?
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 peerreview and has been applied for review of the whole PRD document, including requirements.
Licensed CC-BY-3.0
33
Business Case: How to work out 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.
Licensed CC-BY-3.0
34
Business Case: How to work out Requirements?
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.
Licensed CC-BY-3.0
35
Business Case: How to work out Requirements?
-
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.
Licensed CC-BY-3.0
36
Business Case: How to work out Requirements?
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,
Licensed CC-BY-3.0
37
Business Case: How to work out Requirements?
process activities amendment in combination with extensive supportive requirements
management tools integration.
Licensed CC-BY-3.0
38
Business Case: How to work out Requirements?
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
Licensed CC-BY-3.0
39
Business Case: How to work out Requirements?
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
Licensed CC-BY-3.0
40
Business Case: How to work out Requirements?

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
Licensed CC-BY-3.0
41
Business Case: How to work out Requirements?

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
42
Business Case: How to work out Requirements?
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
VII
Business Case: How to work out Requirements?
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
VIII
Business Case: How to work out Requirements?
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
IX
Business Case: How to work out Requirements?
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
X
Business Case: How to work out Requirements?
(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-insoftware.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/VModel_(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.
Licensed CC-BY-3.0
XI
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