Introduction to Requirements Engineering

1. Introduction to Requirements Engineering “The hardest single part of building a software system is deciding precisely what to build”-F.Brooks

2. Overview Picture What is Requirements Engineering about? What is RE? Notion of a requirement The requirements engineering process Why Requirements Engineering is needed? When to Engineer Requirements? Approaches to Requirements Engineering

3. What is RE about? • The WHY question • Why the system needs to be developed? • The WHAT question • What the system shall do? « Requirements definition must say – why a system is needed, based on current or foreseen conditions, – what system features will satisfy this context, ……………….» (Ross77) IEEE Computer 85, IEEE SE 91-92, Bubenko94, Mylopoulos92, Dardenne93, Loucopoulos95, Rolland98 etc..

4. WHY WHAT What is RE about? Tentative Definition Requirements Engineering is the activity which transforms a fuzzy idea into a precise specification of stakeholders’ needs that shape the system to be built and therefore, defines the intended link between a system and its environment

5. What is RE about? Mission statement, goals WHY? The Requirements Engineering process Requirements Specification WHAT?

6. What is a Requirement? “Something that the product must do or a quality that the product must have” (Robertson99) “A description of how the system shall behave, an information about the application domain, constraints on operations, a system property etc.” (Kotonya98) “A requirement specifies how a goal should be accomplished by a proposed system” (Anton96)

7. What is a Requirement? Examples • a constraint : the system shall include a spelling checker • a required function : the system shall identify “old customers” • a required quality : the print out for old customers shall be in colour

8. What is a Requirement? Requirements taxonomy Functional (1) versus non functional (2) (1) Things the system must do (2) Qualities that the product must have Ex : Send Christmas cards to old customers(1) print them in colour (2)

9. What is Engineering Requirements? A complex process with intertwined activities and multiple actors User Client Requirements Engineer Elicitation Validation Project manager facilitator Specification Documentation Negotiation Domain expert System Analyst

10. What is Engineering Requirements ? Modelling as a core activity • The existing system (As-Is) has to be modelled • The alternative hypothetical systems (To-Be) have to be modelled • Models serve as a basic common interface to the RE activities • (previous slide) • Models provide the basis for documentation and evolution • What aspects to model in the Why-What range? • How to model such aspects? • How to define the model precisely? • How to reason about the model? Questions

11. Why is RE Needed ? " Inadequate, Inconsistent, Incomplete or ambiguous requirements are numerous and have a critical impact on the quality of the resulting software" (Bell&Tayer76) "Late correction of requirements errors cost up to 200 times as much as during such requirements engineering" (Boehm81) "The primary cause of safety-related faults was errors in functional interface requirements " NASA's Voyager and Galileo programs, (Brooks87)

12. Why is RE Needed ? • Poor requirements are major source of failures (Standish95) • 8000 projects, 350 US companies : • 1/3 of projects never completed & 50% succeeded only partially • Most perceived problems are related to requirements specification ( >50%) - (ESI96) 3800 organisations in 17 European countries

13. When to Model Requirements ? Traditionally : the early phase of the software development cycle RUP, (Jacobson98) Inception Elaboration Construction Transition Requirements Analysis Design Implementation Tests Life Cycle Objectives Life Cycle Architecture Initial Operational Capability Product Release

14. Exercise Decide what is to be the contents of a student registration system for your University

15. RE Framework 2 sources of requirements Understanding the Usage Fit Relationship is essential to meet users' expectations The individual, pragmatic perspective SUBJECT WORLD System Environment Scenario Driven Approaches USAGE WORLD Usage Fit relationship SYSTEM WORLD

16. Actor C System Scenario 1 Requirements Collection Scenario Actor A Actor B Actor B Actor A Every Actor describes the way he/she would like to interact with the system Every Actor has his/her view on how to use the system Scenario Based RE The “User” point of view

17. Temporal sequence of interactions between the system-to-be & its environment Example : The Meeting Scheduler (Potts94)

18. Maturitylevels (80%) • INITIAL • REPEATABLE • DEFINED • MANAGED • OPTIMISED The RE process The development world is concerned with methods, models and tools to support the RE process It is necessary to improve the maturity level of development teams Including RE teams (Humphrey89)

19. The RE process How to improve the current practice? • Improving methods : the methodological impact • From handicraft to industrial performance: • formalisation of the RE process (definition of process models) • and tool driven guidance • Improving RE process management : the managerial • impact • Continuous improvement cycle • and mechanisms for capitalising from experience

20. Tracing the RE Process

21. Requirement Engineering – A Roadmap 1. Introduction • Abstract • Success of a software ? • How to know the purpose ? • Identifying stakeholders • Identifying needs of stakeholders • Creating documentation for: • Analysis • Communication • Implementation

22. 1. Introduction (contd.) • Inherent difficulties • Numerous and distributed stakeholders • Vary and conflicting goals • Goals may not be explicit • Difficult to articulate requirements

23. 2. Foundation • Definition of Requirement Engineering “ Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families. ”

24. 2. Foundation (contd.) • What's good about the definition ? • Highlights the importance of real-world goals • Precise specification of: • Analyzing – requirements • Validating – what stakeholders need • Defining – what designers have to build • Verifying – they have done so correctly • Evolution – capable to cope with the changes • What's ambiguous in the definition ? • Main focus is on software engineering

25. 2. Foundation (contd.) • The context in which RE takes place is usually human activity system and the problem owner are people. • Techniques for eliciting and modeling, drawn on cognitive and social sciences: • Cognitive Psychology • Anthropology • Sociology • Linguistics

26. 3. Context and Groundwork • RE is often the fore-end activity in the software system development process • RE plays an important role in the management of change in software development • RE processes depend on the type of product • Groundwork mean the assessment of project’s feasibility and associated risks

27. 4. Eliciting Requirements • Requirements to Elicit • Boundaries • Identify the high level boundaries of the system • Stakeholders and Use Cases depend on boundaries • Stakeholders • Customer or Clients • Developers • Users • Goals • Eliciting High level goals early in development • Tasks • When it is difficult to articulate user requirements

28. 4. Eliciting Requirements (contd.) • Elicitation Techniques • Traditional Techniques • Questionnaires and Surveys • Interviews • Analysis of existing documentation • Group Elicitation • Group brainstorming sessions • RAD (Rapid Application Development) • JAD (Joint Application Design) • Prototyping • Where there is great deal of uncertainty • Early feedback from stakeholders is needed

29. 5. Communicating Requirements • Requirement Management “ The ability, not only to write requirements but also to do so in a form that is readable and traceable by many, in order to manage their evolution over time ” • Requirement Traceability (RT) “ The ability to describe and follow life of a requirement in both forwards and backwards direction ”

30. 6. Agreeing Requirements • Maintaining agreement with the stakeholders can be a problem • Validation “ Validation is the process of establishing that the requirements and models elicited provide an accurate account of stakeholder requirements ” • Validation is difficult for two reasons: • Question of truth and what is knowable • Reaching agreement among different stakeholders

31. 7. Evolving Requirements • Adding requirements • Changing stakeholder needs • Missed in initial analysis • Requirement Scrubbing – Removing requirements • Usually only during development, to forestall cost and schedule overruns • Manage inconsistency in requirements • Managing changing requirements • Continued requirement elicitation • Evaluation of Risk • Evaluation of systems in the environment

32. 8. Evolving Requirements (contd.) • Product Family • Increasingly important form of development activity • Range of software product that share similar requirements and architectural characteristics, yet differ in certain key requirements • Research issue : Identifying the core requirements for the architectures that are: • Stable in the presence of change • Flexible enough to be customized and adapted to changing requirements

33. 9. Integrated Requirements Engineering • Different approaches to manage and integrate RE activities: • Problem Frames • Viewpoints • Automated tools: • DOORS • Requisite Pro • Cradle

34. 10. Requirement Engineering Roadmap • Three radical ideas • Modeling and analysis cannot be performed adequately in isolation from the organizational and social context in which the new system will have to operate • RE should not focus on specifying the functionality of a new system, but instead should concentrate on modeling indicative and optative properties of the environment • Attempt to build consistent and complete requirement models is futile.

35. What's the Future ? • New techniques for formally modeling and analyzing properties of the environment • Richer model for capturing and analyzing non-functional requirements • Bridging the gap between requirements elicitation approaches. • Better understanding of software architectural choices • Reuse of requirement models • Multidisciplinary training of requirements practitioners