Introduction to Requirements Engineering The hardest single part

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

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

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, ………………. » (Ross 77) IEEE Computer 85, IEEE SE 91 -92, Bubenko 94, Mylopoulos 92, Dardenne 93, Loucopoulos 95, Rolland 98 etc. .

What is RE about? Tentative Definition WHY 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 WHAT

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

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

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

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)

What is Engineering Requirements? A complex process with intertwined activities and multiple actors ation Specif ic Docum ation entatio n Do m exp ain ert tion tor Valid qu i En reme gin nts e er Elic ita Neg o tiati ilita Proje mana ct ger ie Cl Re tem Sys st ly Ana on fac User nt

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 Questions v. What aspects to model in the Why-What range? v How to model such aspects? v. How to define the model precisely? v. How to reason about the model?

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&Tayer 76) "Late correction of requirements errors cost up to 200 times as much as during such requirements engineering" (Boehm 81) "The primary cause of safety-related faults was errors in functional interface requirements " NASA's Voyager and Galileo programs, (Brooks 87)

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

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

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

RE Framework 2 sources of requirements The individual, pragmatic perspective SUBJECT System Environment WORLD Understanding the Usage Fit Relationship is essential to meet users' expectations Scenario Driven Approaches USAGE WORLD Usa rela ge Fi tion t ship SYSTEM WORLD

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

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

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

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

Tracing the RE Process

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

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

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. ”

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

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

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

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

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

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 ”

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

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

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

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

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.

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