Requirements Engineering From System Goals to UML Models to Software Specifications

1. Requirements EngineeringFrom System Goals to UML Models to Software Specifications

2. 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 is a key concern for software quality assurance

3. Requirements engineering (RE), roughly ... • Identify & analyze problems with an existing system (system-as-is), • Identify & evaluate objectives, opportunities, options for new system (system-to-be), • Identify & define functionalities of, constraints on, responsibilities in system-to-be, • Specify & organize all of these in a requirements documentto be maintained throughout system evolution System=software+environment (people, devices, other software)

4. Example:transportation between airport terminals • Problem (system-as-is): • passengers frequently missing flight connections among different terminals; slow & inconvenient transportation • number of passengers regularly increasing • Objectives, options (system-to-be): • support high-frequency trains between terminals • withorwithout train drivers ? • Functionalities, constraints: • software-based control of train accelerations, doors opening etc. to achieve prompt and safe transportation • RE deliverable: requirements documentfor system-to-be

5. Software implementation Software design Software evolution Requirements in the software lifecycle Getting the right system Requirements engineering Getting the software right

6. 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. 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. 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. Model-based RE • Model: • abstract representation of system (as-is or to-be) • highlights, specifies, inter-relates key system features • Multi-view model: • different system facets for requirements completeness

10. Why models for RE ? • Focus on key aspects(abstraction from multiple details) • Provides structure for RE activities • target for what must be elicited, evaluated, specified, consolidated, modified • interface among RE activities: produce/consume model items • 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. Learning RE: objectives • Get a sound, precise understanding of concepts, principles, processes, and products involved in RE • Master state-of-the art techniques for requirements elicitation, evaluation, specification, analysis, evolution • Be able to construct, analyze and exploit high-quality models for RE in a systematic way • Gain practical experience in applying techniques in concrete, realistic situations

12. Book support Requirements Engineering:From System Goalsto UML Models to Software SpecificationsAxel van LamsweerdeWiley,Jan. 2009

13. Some features, risks & challenges of RE ... unrealizable Achieve goal unsuccessful project Maintain goal model multi-language specs multiple stakeholders

14. Approach taken in the book • Concentrates on solid, replicable RE techniques • far beyond high-level principles & guidelines • 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

15. 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 • Most techniques are grounded on a formal framework kept hidden for wider accessibility

16. The book has three parts • Part 1: Fundamentals of RE • Part 2: Building models for RE • Part 3: Analyzing and exploiting RE models

17. Part 1: Fundamentals of Requirements Engineering • Setting the scene: basic concepts & principles • Domain understanding & requirements elicitation • Requirements evaluation • Conflict management, risk analysis, evaluating alternative options, requirements prioritization • Requirements specification and documentation • Structured natural language, use of diagrammatic notations, formal specification • Requirements quality assurance • Inspections & reviews, requirements database queries, specification animation, formal verification • Requirements evolution • Change anticipation, traceability management, change control • Goal-orientation in RE

18. Part 2: Building system models for RE • Modeling system objectives with goal diagrams • Risk analysis on goal models • Modeling conceptual objects with class diagrams • Modeling system agents and responsibilities • Modeling system operations • Modeling system behaviors: scenarios and state machines • Integrating multiple system views • A goal-oriented model building method in action

19. Part 3Reasoning 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. 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