1. www.wileyeurope.com/college/van lamsweerde Requirements Engineering © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models to Software Specifications

2. 2 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons What is requirements engineering ?  Set of activities producing the requirements on a software- intensive system –elicitation, evaluation, specification, analysis, evolution management –system objectives, functionalities, target qualities, constraints, assumptions  Requirements quality assurance  Requirements quality assurance is a key concern for software quality assurance

3. 3 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Requirements engineering (RE), roughly...  Identify & analyze problems with an existing system as-is (system-as-is), to-be  Identify & evaluate objectives, opportunities, options for new system (system-to-be),  Identify & define functionalities of, constraints on, responsibilities in system-to-be, requirements document  Specify & organize all of these in a requirements document to be maintained throughout system evolution System = software + environment (people, devices, other software)

4. 4 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Example: transportation between airport terminals as-is  Problem (system-as-is) : –passengers frequently missing flight connections among different terminals; slow & inconvenient transportation –number of passengers regularly increasing to-be  Objectives, options (system-to-be) : –support high-frequency trains between terminals or –with or without train drivers ?  Functionalities, constraints: –software-based control of train accelerations, doors opening etc. to achieve prompt and safe transportation  RE deliverable: requirements document for system-to-be

5. 5 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Requirements in the software lifecycle R equirements engineering Software design Software implementation Software evolution Getting therightsystem Getting thesoftwareright

6. 6 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Why requirements engineering ?  RE is critical –Major cause of software failure Requirements-related errors are the most numerous, persistent, expensive, dangerous –Severe consequences: cost overruns, delivery delays, dissatisfaction, degradations, accidents,... –RE has multiple impact: legal, social, economical, technical  RE is hard

7. 7 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons What makes RE hard ?  Broad scope –multiple system versions: as-is, to-be, to-be-next –hybrid environment: human organizations, policies, regulations devices, physical laws  Multiple concerns –functional, quality, development concerns  Multiple abstraction levels –strategic objectives, operational details

8. 8 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons What makes RE hard ? (2)  Multiple stakeholders –with different background –with different interests and conflicting viewpoints  Multiple intertwined tasks during iterative elicitation-evaluation-specification-consolidation –conflict management –risk management –evaluation of alternatives, prioritization –quality assurance –change anticipation

9. 9 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Model-based RE  Model: –abstract representation of system (as-is or to-be) –highlights, specifies, inter-relates key system features  Multi-view  Multi-view model: –different system facets for requirements completeness

10. 10 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Why models for RE ? key aspects  Focus on key aspects (abstraction from multiple details) structure  Provides structure for RE activities –target for what must be elicited, evaluated, specified, consolidated, modified –interface among RE activities: produce/consume model items analysis  Facilitates analysis –support for early detection and fix of errors  Support for understanding, explanation to stakeholders  Basis for making decisions –multiple options made explicit  Basis for generating the requirements document

11. 11 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Learning RE: objectives sound precise  Get a sound, precise understanding of concepts, principles, processes, and products involved in RE techniques  Master state-of-the art techniques for requirements elicitation, evaluation, specification, analysis, evolution systematic  Be able to construct, analyze and exploit high-quality models for RE in a systematic way practical  Gain practical experience in applying techniques in concrete, realistic situations

12. 12 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Book support Requirements Engineering: From System Goals to UML Models to Software Specifications Axel van Lamsweerde Wiley, Jan. 2009

13. 13 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Some features, risks & challenges of RE... unsuccessful project unrealizable Achieve goal Maintain goal multi-language specs multiple stakeholders model

14. 14 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons techniques  Concentrates on solid, replicable RE techniques –far beyond high-level principles & guidelines construction  Emphasizes model construction (beyond mere use of diagrammatic notations) –procedures, heuristic rules, tactics, modeling patterns, bad smells –UML compliance wherever possible  Based on case studies in a variety of domains Approach taken in the book

15. 15 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Approach taken in the book (2)  Numerous exercises at the end of each chapter  Comprehensive biblio notes at the end of each chapter –to encourage further study  Multiple tracks & entry points to meet a variety of learning needs –basic, model-driven, advanced tracks kept hidden  Most techniques are grounded on a formal framework kept hidden for wider accessibility

16. 16 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons The book has three parts  Part 1: Fundamentals of RE  Part 2: Building models for RE  Part 3: Analyzing and exploiting RE models

17. 17 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Part 1: Fundamentals of Requirements Engineering basic concepts  Setting the scene: basic concepts & principles elicitation  Domain understanding & requirements elicitation evaluation  Requirements evaluation –Conflict management, risk analysis, evaluating alternative options, requirements prioritization specificationdocumentation  Requirements specification and documentation –Structured natural language, use of diagrammatic notations, formal specification quality assurance  Requirements quality assurance –Inspections & reviews, requirements database queries, specification animation, formal verification evolution  Requirements evolution –Change anticipation, traceability management, change control  Goal-orientation  Goal-orientation in RE

18. 18 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Part 2: Building system models for RE objectives  Modeling system objectives with goal diagrams  Risk  Risk analysis on goal models conceptual objects  Modeling conceptual objects with class diagrams agents  Modeling system agents and responsibilities operations  Modeling system operations behaviors  Modeling system behaviors: scenarios and state machines  Integrating multiple system views model building method  A goal-oriented model building method in action

19. 19 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Part 3 Reasoning about system models  Semi-formal reasoning for model analysis & exploitation –Query-based analysis of the model database –Analysis of conflicts, obstacles, and security threats –Qualitative & quantitative reasoning about alternatives –Model-driven generation of the requirements document –From goal-oriented requirements to software architecture  Formal specification of system models –A real-time temporal logic for specifying model annotations –Specifying goals, domain properties, and operationalizations  Formal reasoning for specification construction & analysis –Checking goal refinements; deriving operationalizations –Generating obstacles and anti-goals; analyzing conflicts –Synthesizing behavior models

20. 20 www.wileyeurope.com/college/van lamsweerde Requirements Engineering© 2009 John Wiley and Sons Additional resources http://www.wileyeurope.com/college/van lamsweerde  Course slides  More case studies & examples  Requirements document generated from model built in Chap. 15  Instructor’s protocol for obtaining solutions to exercises  Book figures http://www.objectiver.com  Objectiver tool for building & playing with models –Free limited access for educational use