Weitere ähnliche Inhalte
Ähnlich wie Be a winner…use requirements engineering p (20)
Mehr von Sven Krause (16)
Kürzlich hochgeladen (20)
Be a winner…use requirements engineering p
- 1. Be a winner…
use Requirements Engineering
Sven Krause, 2012
Slide 1
23. Mai 2012
Sven Krause
© Zühlke 2011
- 2. 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
- 3. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 3 © Zühlke 2011
- 5. Requirements Engineering is a part of
Software development
Software Development in case of:
• Product Development
• Legacy System Optimisation
• Problem solving
• Etc.
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 5 © Zühlke 2011
- 6. Requirements Engineering is a part of
Software development
Wikipedia
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 6 © Zühlke 2011
- 11. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 11 © Zühlke 2011
- 12. 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)
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 12 © Zühlke 2011
- 13. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 13 © Zühlke 2011
- 14. 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
- 15. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 15 © Zühlke 2011
- 17. 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
- 19. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 19 © Zühlke 2011
- 20. 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)
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 20 © Zühlke 2011
- 21. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 21 © Zühlke 2011
- 22. 4 elements
Slide 22
23. Mai 2011
Sven Krause
© Zühlke 2011
- 23. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 23 © Zühlke 2011
- 24. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 24 © Zühlke 2011
- 25. 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)
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 25 © Zühlke 2011
- 26. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 26 © Zühlke 2011
- 27. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 27 © Zühlke 2011
- 28. 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!
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 28 © Zühlke 2011
- 29. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 29 © Zühlke 2011
- 30. Example for Documentation structure
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 30 © Zühlke 2011
- 31. 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
- 32. 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.
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 32 © Zühlke 2011
- 33. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 33 © Zühlke 2011
- 34. Techniques for Checking Requirements
There are several techniques for systematic checks of
requirements.
• Expert reports
• Review
• Inspection
• Walkthrough
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 34 © Zühlke 2011
- 35. 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
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 35 © Zühlke 2011
- 36. 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.
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 36 © Zühlke 2011
- 37. CPRE – Certified Professional
Requirements Engineer
http://certified-re.de/
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 37 © Zühlke 2011
- 38. Thank you
for your attention
Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 38 © Zühlke 2011