Requirement Engineering – A Roadmap Bashar Nuseibeh Steve Easterbrook Presented By Adnan Choudhary

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

4. Eliciting Requirements (contd.) Elicitation Techniques Model-Driven Goal Based Methods – KAOS & I Scenario Based Methods - CREWS Cognitive Protocol Analysis Laddering Card Sorting Repertory Grids Contextual Alternative to Tradition and Cognitive techniques Ethnographic Technique– Participant Observation

5. Modeling and Analysis Requirements “ The construction of abstract descriptions that are amenable to interpretation ” Enterprise Modeling Understanding organization's structure Business rules Goals, tasks and responsibilities Data Data Modeling Understand, manipulate and manage large volume of information How to represent real world phenomenon into system information

5. Modeling and Analysis Requirements (contd.) Behavioral Modeling Dynamic or Functional behavior of stakeholders and system, both existing and required Domain Modeling Abstract description of the world in which the system will operate Requirements reuse within a domain Modeling Non-Functional Requirements Difficult to express in a measurable way Difficult to analyze Properties of a system as a whole

5. Modeling and Analysis Requirements (contd.) Analyzing Requirements Models Requirements Animation Automated Reasoning Analogical and Case-based Reasoning Knowledge based Critiquing Consistency Checking

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

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

8. 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 for formally modeling and analyzing properties of the environment Richer model for capturing and analyzing non-functional requirements Bridging the gap between requirements elicitation apporaches. Better understanding of software architectural choices Reuse of requirement models Multidisciplinary training of requirements practitioners