Requirements engineering processes
This presentation is the property of its rightful owner.
Sponsored Links
1 / 46

Requirements Engineering Processes PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on
  • Presentation posted in: General

Requirements Engineering Processes. Objectives. To introduce the notion of processes and process models for requirements engineering To explain the critical role of people in requirements engineering processes

Download Presentation

Requirements Engineering Processes

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


Requirements engineering processes

Requirements Engineering Processes


Objectives

Objectives

  • To introduce the notion of processes and process models for requirements engineering

  • To explain the critical role of people in requirements engineering processes

  • To explain why process improvement is important and to suggest a process improvement model for requirements engineering


Processes

Processes

  • A process is an organized set of activities which transforms inputs to outputs

  • Process descriptions encapsulate knowledge and allow it to be reused

  • Examples of process descriptions

    • Instruction manual for a dishwasher

    • Cookbook

    • Procedures manual for a bank

    • Quality manual for software development


Design processes

Design processes

  • Design processes are processes which involve:

    • Creativity,

    • Interaction with a wide range of different people,

    • Engineering judgment,

    • Background knowledge, and

    • Experience


Design processes1

Design processes

  • Inputs not precisely defined

  • Many possible outputs satisfying inputs

  • Cannot be automated or specified in detail

  • Different people tackle intellectual tasks in different ways and adapt the process to suit their own way of thinking.


Design processes2

Design processes

  • Examples of design processes

    • Writing a book

    • Organizing a conference

    • Designing a processor chip

    • Requirements engineering


Re process inputs and outputs

RE process - inputs and outputs


Input output description

Input/output description


Re process variability

RE process variability

  • RE processes vary radically from one organization to another

  • Factors contributing to this variability include

    • Technical maturity

    • Disciplinary involvement

    • Organizational culture

    • Application domain

  • There is therefore no ‘ideal’ requirements engineering process


Process models

Process models

  • A process model is a simplified description of a process presented from a particular perspective

  • Processes may be defined at different levels of detail.

    • In some cases, processes are defined at a very fine level of detail

    • The steps in the process must be carried out exactly as described.


Process models1

Process models

  • Different people usually enact a process in different ways depending on the background of the people involved and the particular circumstance in which the process is enacted.

  • The same person will enact the same process in different ways at different times

  • Types of process models include:

    • Coarse-grain activity models

    • Fine-grain activity models

    • Role-action models

    • Entity-relation models


Requirements engineering process model 1

Requirements Engineering Process Model #1


Re process activities

RE process activities

  • Requirements elicitation

    • Requirements discovered through consultation with stakeholders

  • Requirements analysis and negotiation

    • Requirements are analyzed and conflicts resolved through negotiation

  • Requirements documentation

    • Arequirements document is produced

  • Requirements validation

    • The requirements document is checked for consistency and completeness


Requirement engineering process

Requirement Engineering Process

  • Alan Davisdefines requirements engineering as:

    • “all activities up to but not including the decomposition of the software into its actual architectural components”

  • 2nd definition: (focus is on what RE is rather than what it is not)

    • “Investigating and describing the problem domain and requirements and designing and documenting the characteristics for a solution system that will meet those requirements.”


Alternative requirement engineering process model

Alternative Requirement Engineering Process Model

  • The following sub-tasks may be identified:

    • Elicitation

    • Analysis

    • Specification

    • Human machine interface (HMI) design

    • Validation


Requirements engineering processes

Alternative

RE Process

Model


Clarification of the alternative re model

Clarification of the Alternative RE Model

  • Initially, information comes from questions to the users

  • This “raw” information feeds through the elicitation process and primarily consists of problem domain information and functional requirements.

  • Analysis uncovers more problem domain understanding which feeds back into and guides the elicitation process.

  • The specification can be done when the analysis is complete.

  • The detailed external design of the HCI (“look and feel”) is factored out of the specification because if it is part of the spec., it can mask the essential, logical behavior of the system.


Outputs of the alternative re model

Outputs of the Alternative RE Model

  • Four documents are produced:

    • Elicitation notes: not in a structured format, not passed on from the RE phase, useful for traceability purposes

    • Requirements document (the analysis document): consists of a precise description of the problem domain together with the requirements

    • Specification: contains a definition of the required behavior of the solution system; also known as RS, SRS,RD; forms the basis of the contract between client and developer

    • HMI Design Document: elaborates the details of the external interfaces of the solution system (may not always be an interface for humans); will have some overlap with the specification


What comes next and what about validation

What comes next (and what about Validation?

  • The requirements document, the specification document, and the HCI specification form the input to the design phase

  • Why does this RE model leave off Validation?

    • Validation is an extremely important part of RE, and is not shown as a separate process because it permeates the entire process.

      • During an elicitation interview, repeat the client’s statements back to them to check understanding;

      • When the 1st draft of the requirements document is complete, do a formal review of it; etc.


Software validation

Software Validation

  • Validation attempts to ensure that the correct functionality for the solution system has been defined.

  • Need to validate the entire RE process (and the entire SWE process as well) to check:

    • Is the description of the problem domain an accurate reflection of its properties?

    • Are the requirements (the effects to be produced in the problem domain) accurately recorded?

    • Is the external design correct; will the invented behavior of the new system produced the required effects?

    • Is the specification an accurate reflection of the intended external design?


Spiral model of the re process 3 rd model

Spiral model of the RE process (3rd model)


Actors in the re process

Actors in the RE process

  • Actors in a process are the people involved in the execution of that process

  • Actors are normally identified by their roles rather than individually

  • Requirements engineering involves actors who are primarily interested in the problem to be solved (end-users, etc.) as well actors interested in the solution (system designers, etc.)

  • Role-action diagrams document which actors are involved in different activities


Rad for software prototyping

RAD for software prototyping


Role descriptions

Role descriptions


Human and social factors

Human and social factors

  • Requirements engineering processes are dominated by human, social and organizational factors because they always involve a range of stakeholders from different backgrounds and with different individual and organizational goals.

  • System stakeholders may come from a range of technical and non-technical background and from different disciplines


Types of stakeholder

Types of stakeholder

  • Software engineers responsible for system development

  • System end-users who will use the system after it has been delivered

  • Managers of system end-users who are responsible for their work

  • External regulators who check that the system meets its legal requirements

  • Domain experts who give essential background information about the system application domain


Factors influencing requirements

Factors influencing requirements

  • Personality and status of stakeholders

  • The personal goals of individuals within an organization

  • The degree of political influence of stakeholders within an organization


Process support

Process support

  • CASE tools provide automated support for software engineering processes

  • The most mature CASE tools support well-understood activities such as programming and testing and the use of structured methods

  • Support for requirements engineering is still limited because of the informality and the variability of the process


Case tools for re

CASE tools for RE

  • Modeling and validation tools support the development of system models which can be used to specify the system and the checking of these models for completeness and consistency.

  • Management tools help manage a database of requirements and support the management of changes to these requirements.


A requirements management system

A requirements management system


Requirements management tools

Requirements management tools

  • Requirements browser

  • Requirements query system

  • Traceability support system

  • Report generator

  • Requirements converter and word processor linker

  • Change control system


Requirements management activities

Requirements Management Activities

  • Defining the requirements baseline (a snapshot in time representing the current agreed-on body of requirements)

  • Reviewing proposed requirements changes and evaluating the likely impact of each proposed change before deciding weather to approve it

  • Incorporating approved requirements changes into the project in a controlled way

  • Keeping project plans current with the requirements

  • Negotiating new commitments based on the estimated impact of changed requirements

  • Tracing individual requirements to their corresponding designs, source code, and test cases

  • Tracking requirements statusand change activity throughout the project


Process improvement

Process improvement

  • Process improvement is concerned with modifying processes in order to meet some improvement objectives

  • Improvement objectives

    • Quality improvement

    • Schedule reduction

    • Resource reduction


Planning process improvement

Planning process improvement

  • What are the problems with current processes?

  • What are the improvement goals?

  • How can process improvement be introduced to achieve these goals?

  • How should process improvements be controlled and managed?


Re process problems

RE process problems

  • Lack of stakeholder involvement

  • Business needs not considered

  • Lack of requirements management

  • Lack of defined responsibilities

  • Stakeholder communication problems

  • Over-long schedules and poor quality requirements documents


Process maturity

Process maturity

  • Process maturity can be thought of as the extent that an organization has defined its processes, actively controls these processes and provides systematic human and computer-based support for them.

  • The SEI’s Capability Maturity Model is a framework for assessing software process maturity in development organizations


Capability maturity model

Capability maturity model


Maturity levels

Maturity levels

  • Initial level

    • Organizations have an undisciplined process and it is left to individuals how to manage the process and which development techniques to use.

  • Repeatable level

    • Organizations have basic cost and schedule management procedures in place. They are likely to be able to make consistent budget and schedule predictions for projects in the same application area.


Maturity levels1

Maturity levels

  • Defined level

    • The software process for both management and engineering activities is documented, standardized and integrated into a standard software process for the organization.

  • Managed level

    • Detailed measurements of both process and product quality are collected and used to control the process.

  • Optimizing level

    • The organization has a continuous process improvement strategy, based on objective measurements, in place.


Re process maturity model

RE process maturity model


Re process maturity levels

RE process maturity levels

  • Initial level

    • No defined RE process. Problems such as requirements volatility, unsatisfied stakeholders and high rework costs. Dependent on individual skills.

  • Repeatable level

    • Defined standards for requirements documents and policies and procedures for requirements management.

  • Defined level

    • Defined RE process based on good practices and techniques. Active process improvement process in place.


Good practice for re process improvement

Good practice for RE process improvement

  • RE processes can be improved by the systematic introduction of good requirements engineering practice

  • Each improvement cycle identifies good practice guidelines and works to introduce them in an organization


Examples of good practice guidelines

Examples of good practice guidelines

  • Define a standard document structure

  • Uniquely identify each requirement

  • Define policies for requirements management

  • Use checklists for requirements analysis

  • Use scenarios to elicit requirements

  • Specify requirements quantitatively

  • Use prototyping to animate requirements

  • Reuse requirements


Key points

Key points

  • The requirements engineering process is a structured set of activities which lead to the production of a requirements document.

  • Inputs to the requirements engineering process are information about existing systems, stakeholder needs, organizational standards, regulations and domain information.

  • Requirements engineering processes vary radically from one organization to another. Most processes include requirements elicitation, requirements analysis and negotiation and requirements validation.


Key points1

Key points

  • Requirements engineering process models are simplified process description which are presented from a particular perspective.

  • Human, social and organizational factors are important influences on requirements engineering processes.

  • Requirements engineering process improvement is difficult and is best tackled in an incremental way.

  • Requirements engineering processes can be classified according to their degree of maturity.


  • Login