8-Lecture VIII

(1)

Farhan Aadil

Assistant Professor

COMSATS Institute of Information Technology

Lecture 8

Actor and Stakeholder in RE

(2)

COMSATS Institute of Information Technology, Attock

2 _{Farhan Aadil}

Recap of Last Lecture - 1

• We introduced the concept of requirements engineering process

• We discussed inputs and outputs of the requirements engineering process

(3)

Recap of Last Lecture - 2

• We introduced high-level activities in the requirements engineering process

– Requirements elicitation

– Requirements analysis and negotiation – Requirements specification

(4)

4 _{Farhan Aadil}

Today’s Topics

• Actors and stakeholders in the requirements engineering process

• Process and process improvement for requirements engineering

(5)

Who are Actors?

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

• Actors are normally identified by their roles rather than

(6)

6 _{Farhan Aadil}

Actors in the RE Process - 1

• Requirements engineering involves people who

are primarily interested in the problem to be solved

(end-users, etc) as well as people interested in the

solution (system designers, etc.)

• Another group of people, such as health & safety

regulators, and maintenance engineers may be

effected by the existence of the system

(7)

Actors in the RE Process - 2

• Role-action diagrams are process models which

show the actors associated with different process

activities

• They document the information needs of different

people involved in the process

(8)

8 _{Farhan Aadil}

Role-Action Diagram for Software Prototyping

(9)

Quiz 3

(10)

10 _{Farhan Aadil}

Role Descriptions - 1

10

Role

Description

Domain

Expert

Responsible for proving

information about the

application domain and the

specific problem in that

(11)

Role

Description

System

End-user

(12)

12 _{Farhan Aadil}

12

Role

Description

Requirements

Engineer

Responsible for eliciting and

specifying the system

(13)

Role

Description

Software

Engineer

(14)

14 _{Farhan Aadil}

Role Descriptions - 5

14

Role

Description

Project

Manager

Responsible for planning and

estimating the prototyping

(15)

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

(16)

16 _{Farhan Aadil}

Stakeholder Types

• Software engineers • System end-users

• Managers of system end-users • External regulators

• Domain experts

(17)

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

(18)

18 _{Farhan Aadil}

Process Support

• One way to minimize errors in the requirements engineering is to use process models and to use CASE tools

• 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

(19)

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

(20)

20 _{Farhan Aadil}

Assignment 2

(21)

Process Improvement

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

• Improvement objectives

(22)

22 _{Farhan Aadil}

Planning Process Improvement

Some important questions arise:

• 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?

(23)

RE Process Problems

• Lack of stakeholder involvement • Business needs not considered • Lack of requirements management • Lack of defined responsibilities

• Stakeholder communication problems

(24)

24 _{Farhan Aadil}

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

(25)

The Process

• A software process is a road map that helps you

create a timely, high quality result.

• It is the way we produce software

• Provides stability and control

• Work Product

(26)

26 _{Farhan Aadil}

Process Maturity

• SEI – Software Engineering Institute • 5 maturity levels

• Capability Maturity Model (CMM)

(27)

CMM Maturity Levels

INITIAL – Ad hoc Process

REPEATABLE – Project Management DEFINED – Process Definition

MANAGED – Process Measurement

(28)

28 _{Farhan Aadil}

(29)

(30)

(31)

Key Process Areas (KPAs)

(32)

32 _{Farhan Aadil}

Level 1

Level 1 – Initial: The software process is characterized as ad hoc and occasionally even chaotic. Few processes are defined, and success depends upon individual effort

(33)

Key Process Areas (KPAs)

•

Goals

•

Abilities

•

Methods for

monitoring

implementation

•

Commitments

•

Activities

•

Methods for

verifying

(34)

34 _{Farhan Aadil}

Level 2

Level 2 – Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary project discipline is in place to repeat earlier successes on projects with similar applications

(35)

Level 2 KPAs

•

Software Configuration

Management

•

Software Quality Assurance

(36)

36 _{Farhan Aadil}

Level 2 KPAs - Continued

•

Software project tracking and

oversight

•

Software project planning

•

Requirement management

(37)

Level 3

(38)

38 _{Farhan Aadil}

Level 3 KPAs

•

Peer reviews

•

Inter-group coordination

•

Software product Engineering

•

Integrated software

management

(39)

Level 3 KPAs - Continued

•

Training program

•

Organization process

management

(40)

40 _{Farhan Aadil}

Level 4

Level 4 – Managed: Detailed measures for software process and product quality are controlled. Both the software process and products are quantitatively understood and controlled using detailed measures

(41)

Level 4 KPAs

•

Software quality management

•

Quantitative process

(42)

42 _{Farhan Aadil}

Level 5

Level 5 – Optimizing: Continuous process improvement is enabled by qualitative feedback from the process and from testing innovative ideas and technologies

(43)

Level 5 KPAs

•

Process change management

•

Technology change

management

(44)

44 _{Farhan Aadil}

(45)

RE Process Maturity Model

Standardized requirements engineering Fewer requirements errors

Defined process based on best practices Process improvement in place

Initial

Repeatable

(46)

46 _{Farhan Aadil}

Initial RE Process Maturity Level

• There is no defined RE process.

• It suffer from requirements problems such as requirements volatility, unsatisfied stakeholders and high rework costs. • It is dependent on individual skills and experience

(47)

Repeatable RE Process Maturity Level

(48)

48 _{Farhan Aadil}

Defined RE Process Maturity Level

• Defined RE process based on good practices and

techniques. Active process improvement process is in place

(49)

Best Practices for RE Process Improvement

• RE processes can be improved by the systematic

introduction of best requirements engineering practices

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

(50)

50 _{Farhan Aadil}

Requirements Engineering Costs

• About fifteen percent (15%) of system development costs • However, if the requirements engineering process is not

executed properly, this cost can increase substantially

(51)

Summary

• 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

(52)

52 _{Farhan Aadil}

References

• ‘Requirements Engineering: Processes and

Techniques’ by G. Kotonya and I.

Sommerville, John Wiley & Sons, 1998

• Software Requirements: Objects, Functions,

and States by A. Davis, PH, 1993

• Software Engineering 6

th

Edition, by I.

Sommerville, 2000

• Software Engineering 5

th

Edition, by R.

Pressman