• Save
Be a winner…use requirements engineering p
Upcoming SlideShare
Loading in...5
×
 

Be a winner…use requirements engineering p

on

  • 802 views

 

Statistics

Views

Total Views
802
Views on SlideShare
802
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Be a winner…use requirements engineering p Be a winner…use requirements engineering p Presentation Transcript

  • Be a winner…use Requirements EngineeringSven Krause, 2012 Slide 1 23. Mai 2012 Sven Krause © Zühlke 2011
  • Intro Sven Krause ZühlkeProduct Zühlke is an independent technology and consultancy company providingDeveloper bespoke software solutions, productBusiness innovation and managementAnalyst consulting. We advise, develop and integrate to efficiently deliverProject- & solutions of the highest quality. OverQ-Mgt. the past 40 years we have built an enviable track record and are now anConsultant & internationally renowned solution sven.krause@zuehlke.comCoaching provider with teams in Austria, Senior Business Consultant Germany, Switzerland and United Zuehlke Management Kingdom. Consultants AGRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 2 © Zühlke 2011
  • Goals & StorylineThe participants understand• what Requirements Engineering is• why Requirements Engineering is so important• the 4 elements of Requirements EngineeringAgenda• Introduction, overview and fundamentals• 4 Elements• StandardisationRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 3 © Zühlke 2011
  • Introduction, overview andfundamentals Slide 4 23. Mai 2011 Sven Krause © Zühlke 2011
  • Requirements Engineering is a part ofSoftware developmentSoftware 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
  • Requirements Engineering is a part ofSoftware development WikipediaRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 6 © Zühlke 2011
  • Waterfall modelRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 7 © Zühlke 2011
  • V-ModellRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 8 © Zühlke 2011
  • RUPRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 9 © Zühlke 2011
  • SCRUMRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 10 © Zühlke 2011
  • Definition of Requirements Engineering Requirements Engineering is a cooperative, iterative, incremental process, the goals of which are to make sure that1. all relevant requirements are known and understood to a level of detail that is necessary2. the involved stakeholders achieve an satisfactory level of agreement about the known requirements3. 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ünRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 11 © Zühlke 2011
  • Definition of requirements According to IEEE a requirement is1. A condition or capability needed by a user to solve a problem or achieve an objective2. 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 document3. 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
  • 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 - SchnittstellenRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 13 © Zühlke 2011
  • Functional vs non functional requirementsFunctional requirements specify a processing of thesystem, without consideration for boundary conditions orrestrictions Altogether according to ISO 9126 also qualityNon functional requirements specify conditions and criteria are calledrestrictions those the system must to be sufficient 01.10.2007 Slide 14 © Zühlke 2011
  • Reasons, why requirements engineeringare 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 / 2005Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 15 © Zühlke 2011
  • The consequences of bad requirementsRainer Grau 18.03.2009 Slide 16 © Zühlke 2011
  • Reasons, why projects (withoutrequirements engineering) fail• Unclear requirements and goals• Unsatisfactory inclusion of the involved ones• Missing resources• Unrealistic expectations• Politics, egoism, authority disputes• Frequent changes of the requirementsSven Krause 10. December 2010 Slide 17 © Zühlke 2011
  • RE summaryRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 18 © Zühlke 2011
  • Symptoms of inadequate REGood RE is important since many problems in software andsystem development have their origin in this discipline.Correcting them later results in high costs.Typical symptoms on inadequate RE are unclear and missingrequirements.• 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 systemsRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 19 © Zühlke 2011
  • 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
  • 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-48Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 21 © Zühlke 2011
  • 4 elements Slide 22 23. Mai 2011 Sven Krause © Zühlke 2011
  • The 4 elements of requirementsengineering 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 requirementsRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 23 © Zühlke 2011
  • 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. GovernanceRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 24 © Zühlke 2011
  • 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
  • Categorization of requirementsKano 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 discontentRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 26 © Zühlke 2011
  • 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 peopleRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 27 © Zühlke 2011
  • 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
  • Sample of all requirement documents!The Templates suggested by standards resembles eachother 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 SpecificationRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 29 © Zühlke 2011
  • Example for Documentation structureRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 30 © Zühlke 2011
  • Einsatz von UML in Analyse, Spezifikationund im PrüfenErhebung, 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 ReconcilingConflicting 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
  • 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• ConsistentRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 33 © Zühlke 2011
  • Techniques for Checking Requirements There are several techniques for systematic checks of requirements.• Expert reports• Review• Inspection• WalkthroughRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 34 © Zühlke 2011
  • 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 checksRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 35 © Zühlke 2011
  • 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
  • CPRE – Certified ProfessionalRequirements Engineer http://certified-re.de/Requirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 37 © Zühlke 2011
  • Thank you for your attentionRequirements Management, the quality warranty | Sven Krause 23. Mai 2011 Slide 38 © Zühlke 2011