Be a winner…use requirements engineering p

Be a winner…
use Requirements Engineering
Sven Krause, 2012

Slide 1
23. Mai 2012

Sven Krause

© Zühlke 2011

Intro

Sven Krause Zühlke
Product Zühlke is an independent technology
and consultancy company providing
Developer
bespoke software solutions, product
Business innovation and management
Analyst consulting. We advise, develop and
integrate to efficiently deliver
Project- & solutions of the highest quality. Over
Q-Mgt. the past 40 years we have built an
enviable track record and are now an
Consultant & internationally renowned solution
sven.krause@zuehlke.com
Coaching provider with teams in Austria,
Senior Business Consultant
Germany, Switzerland and United
Zuehlke Management
Kingdom.
Consultants AG

Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 2 © Zühlke 2011

Goals & Storyline

The participants understand
• what Requirements Engineering is
• why Requirements Engineering is so important
• the 4 elements of Requirements Engineering

Agenda
• Introduction, overview and fundamentals
• 4 Elements
• Standardisation


Introduction, overview and
fundamentals

Slide 4
23. Mai 2011

Sven Krause

© Zühlke 2011

Requirements Engineering is a part of
Software development

Software Development in case of:
• Product Development
• Legacy System Optimisation
• Problem solving
• Etc.


Requirements Engineering is a part of
Software development

Wikipedia

Waterfall model


V-Modell


RUP


SCRUM


Definition of Requirements Engineering

Requirements Engineering is a cooperative, iterative,
incremental process, the goals of which are to make sure
that
1. all relevant requirements are known and understood to a
level of detail that is necessary
2. the involved stakeholders achieve an satisfactory level of
agreement about the known requirements
3. all requirements are document according to
documentation guidelines or specified according to
specification guidelines.
Stakeholder
Fokus

Ideen
Bedürfnisse
Ziele
Init. Voranalyse Konzept Spezifik. Design
e Anforderungen
Problem
sche
Wün


Definition of requirements

According to IEEE a requirement is

1. A condition or capability needed by a user to solve a
problem or achieve an objective
2. A condition or capability that must be met or possessed
by a system or system component to satisfy a contract,
standard, specification, or other formally imposed
document
3. A documented representation of a condition or capability
as in (1) or (2)


The kinds of requirements

Requirements

Product Project carrier Regulatorien
(System) - Vorgehensmodell - Garantie - Gesetzgebung
- Prozess - Wartung - Normen
- Artefakte - Releases - Standards
Software - Methodik - Support - Konventionen
- Kosten - Hotline - Guidelines
- Dauer
- Meilensteine
Hardware - Team
- Gewicht - Dokumentation
- Grösse (z.B. Display) Non functional
- Energie-Verbrauch (Qualitativ, Technisch)
- Performance - Performance
- Kapazität - Sicherheit
- Skalierbarkeit - Verfügbarkeit Functional
- Sicherheit - Zuverlässigkeit - Funktionen
- Zuverlässigkeit - Robustheit (Use Cases)
- Robustheit - Installierbarkeit - Daten
- Installierbarkeit - Portabilität - Zustände
- Kompatibilität - Änderbarkeit - Fehlerbehandlung
- Wartbarkeit - Wartbarkeit - Schnittstellen

Functional vs non functional requirements

Functional requirements specify a processing of the
system, without consideration for boundary conditions or
restrictions Altogether
according to ISO
9126 also quality
Non functional requirements specify conditions and criteria are called
restrictions those the system must to be sufficient

01.10.2007 Slide 14 © Zühlke 2011

Reasons, why requirements engineering
are so important

Unklare Anforderungen und Ziele

Fehlende Ressourcen bei Projektstart

Politik, Egoismen, Kompetenzstreitigkeit
Fehlende PM-Erfahrung auf
Leitungsebene
Unzureichende Projektplanung

Schlechte Kommunikation

Mangel an qualifizierten Mitarbeitern
Fehlende PM-Methodik, z.B.
Risikomanagement

Mangelhaftes Stakeholder Management
Fehlende Unterstützung des
Managements %
10 20 30 40 50 60 70 80
Quelle: Gesellschaft für Projektmanagement in Zeitschrift IT Business 23 / 2005


The consequences of bad requirements

Rainer Grau 18.03.2009 Slide 16 © Zühlke 2011

Reasons, why projects (without
requirements engineering) fail

• Unclear requirements and goals
• Unsatisfactory inclusion of the involved ones
• Missing resources
• Unrealistic expectations
• Politics, egoism, authority disputes
• Frequent changes of the requirements

Sven Krause 10. December 2010 Slide 17 © Zühlke 2011

RE summary


Symptoms of inadequate RE

Good RE is important since many problems in software and
system development have their origin in this discipline.
Correcting them later results in high costs.
Typical symptoms on inadequate RE are unclear and missing
requirements.
• The wrong assumption by stakeholders that many things
are self-explaining and need no explicit treatment
• Communications problems based on different know-how
and experience
• Project pressure exerted by contractors asking for early
delivery of productive systems


Benefit of Requirements Engineering

• To fulfill customer expectations better
• To cut error cost
• Lower claims and re-engineering
• Less maintenance costs
• To reduce Interpretation
• To avoid risk (software is developed, which the customer
really wants)
• Re-Use (testing)


Motivation

200 Kostenüberschreitung (%)

160

120

80

40

0
0 5 10 15 20
Anteil der Kosten der Anforderungen an den Gesamtkosten (%)
Bowen, J.P.; Hinchey, M.G.: Ten Commandments of Formal Methods ... Ten Years Later, IEEE Computer, Vol. 39, No. 1, January 2006, pp. 40-48


4 elements

Slide 22
23. Mai 2011

Sven Krause

© Zühlke 2011

The 4 elements of requirements
engineering

needs Employment
Methods of of natural
the Usability speech
Master,
Standard analyze

elicitation
document
& verify Notation forms
(e.g. UML)

Verifying and validating
Review techniques Techniques of specify
the modelling

requirements


Sources of requirements

sponsor partner
regulation
user Knowledge
person
Customer
Stakeholders indirect
(Buying centre)
decision makers
market

Adjacent
Interface doc. system
Existing Existing
system
document system
Low doc.
System doc. Trouble Ticket
Strategy doc.
Governance

Elicitation techniques

Different elicitation techniques are needed to find
conscious, unconscious and subconscious requirements of
stakeholder
• Questioning techniques (interviews, questionnaires)
• Creativity techniques (brainstorming, change of
perspective, analogies, creative reframing)
• Document based techniques (system archaeology,
reusability of requirements)
• Observation techniques (field observation, apprenticing)
• Supporting techniques (mind mapping, workshops,
use case modelling, prototype)


Categorization of requirements
Kano model

During elicitation of requirements it is important to know
which of the requirements are most important to achieve
customer satisfaction.

content performance
factors

excitement
factors completely

incompletely

Basic factors

discontent


Structuring Documents

Documentation is a key supporting feature for goal oriented
communication

• It is necessary to document important information
• Any more or less formal way of capturing requirements
is called a documentation technique (from writing
various styles to using formal diagrams)
• Many people come in contact with the documentation
• A documentation support is necessary because
requirements are long-lasting, they may be legally
relevant and they should be accessible to all people


Forms of requirement documents

Number, form and naming of assigned document types
depend on
• Process and Standards
– Hermes, V-Modell, RUP, Volere, CMMI
Use of Templates for document types
• Example V-Modell
– Lastenheft und Pflichtenheft
• Example RUP
– Vision, Use Case Modell und Supplementary
Specification
• Example XP
– Story Cards und Task Cards

Important: Templates to the environment and the needs of
the project adapt!

Sample of all requirement documents!

The Templates suggested by standards resembles each
other in three basic elements:
• overview, context, scope
– For all (that means developmer just like manager)
readable short overview of the project.
– No details, but constrains, goals, solution desired
– RUP: Vision Document
• Functional requirements
– Specification of the functionality of the system
– RUP: Use Case Model
• non functional requirements
– RUP: Supplementary Specification


Example for Documentation structure


Einsatz von UML in Analyse, Spezifikation
und im Prüfen

Erhebung, Analyse und Dokumentation mit UML
• Use Case Diagramm
– Eingesetzt zusammen mit Storyboards und UI-Prototyping
– Konsistenzprüfung gegen Modellierung der Datenanforderungen

• Sequenz- und Aktivitätsdiagramm
– Spezifikation der Soll-Abläufe in Use Cases
– Erhoben und analysiert in Interviews, Workshops und durch
Beobachtung

• Klassendiagramme
– Spezifikation der Datenanforderungen
– Durch Analyse aller Ergebnissen von Erhebungen
– Konsistenzprüfung gegen Modellierung der Use Cases

• Zustandsdiagramm
– Formulierung der „Lebensgeschichte“ Geschäftsobjekten
– Formulierung des Verhaltens technischer Elemente
– Konsistenzprüfung gegen Use Case Modellierung und
Datenanforderungen
– Zustandsänderungen sind über Use Cases formuliert
– Daten sind im Datenmodell formuliert
01.10.2007 Slide 31 © Zühlke 2011

Basics for Checking and of Reconciling
Conflicting Requirements

Basics for Checking Requirements

The major goal of checking requirements is to
find out whether they conform to quality criteria
(e.g. correctness or completeness) that have
been set beforehand.

Basics of Reconciling Conflicting Requirements

The goal for reconciling conflicts within the
requirements is to create a common and agreed
understanding of the requirements among all
relevant stakeholders.


Quality criteria for Requirements

Each individual requirements should conform to
requirements’ quality criteria.

• Harmonized • Testable
• Prioritized • Implementable
• Unambiguous • Traceable
• Valid and current • Complete
• Correct • Understandable
• Consistent


Techniques for Checking Requirements

There are several techniques for systematic checks of
requirements.
• Expert reports
• Review
• Inspection
• Walkthrough


Principles for Checking Requirements

These principles ensure that during checking a maximum
number of errors in the requirements can be identified.
• Involve the right stakeholders
• Separate error discovery and error correction
• Check from different points of view
• Switch between different styles of documentation
• Construct development artefacts based on the
requirements
• Repeat checks


Summary

• RE is the systematic, disciplined procedure with elicit,
documents, checks and reconcile, and manage from
requirements.
• A goal is about to understand and describe, what customers
wish or need.
• With RE the risk is to be minimized that a system or a
product is developed, which is not useful or pleases to the
customer.
• Problem definition (what) and description of solution (How)
alternate during the development process and depend on
the point of view of the Stakeholders.


CPRE – Certified Professional
Requirements Engineer

http://certified-re.de/

Thank you
for your attention


Be a winner…use requirements engineering p

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Be a winner…use requirements engineering p

Similaire à Be a winner…use requirements engineering p (20)

Plus de Sven Krause

Plus de Sven Krause (16)

Dernier

Dernier (20)

Be a winner…use requirements engineering p