requirement engineering a roadmap l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Requirement Engineering – A Roadmap PowerPoint Presentation
Download Presentation
Requirement Engineering – A Roadmap

Loading in 2 Seconds...

play fullscreen
1 / 20

Requirement Engineering – A Roadmap - PowerPoint PPT Presentation


  • 285 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Requirement Engineering – A Roadmap' - salena


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
requirement engineering a roadmap

Requirement Engineering – A Roadmap

Bashar Nuseibeh

Steve Easterbrook

Presented By

Adnan Choudhary

1 introduction
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
1. Introduction (contd.)
  • Inherent difficulties
    • Numerous and distributed stakeholders
    • Vary and conflicting goals
    • Goals may not be explicit
    • Difficult to articulate requirements
2 foundation
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
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 contd6
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
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
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
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 contd10
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
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
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 contd13
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
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
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
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
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
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
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
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