Lecture 02 RE Process

8/11/2019 Lecture 02 RE Process

1/49

Requirements

Engineering PROCESS

SWENG 580: advanced software

engineering

What are the principal

requirements engineering

activities?


2/49

EngineeringDivision

,ThePennsylvaniaStateUniversity

2

SWENG 580: Advanced Software Engineering

What is the requirements engineering

process?

The processes used for requirements engineering vary widely

depending on the application domain, the people involved and the

organization developing the requirements

However, there are a number of generic activities common to all

processes Requirements elicitation Requirements analysis

Requirements validation

Requirements management


3/49

EngineeringDivision


3


Requirements engineering process

Preliminary

Study

Requirements

Validation

Requirements

Definition

Requirements

Elicitation

Feasibility

Report Domain

Model

Requirements

Document

Definition of

Requirements

Requirements

Specification


4/49

EngineeringDivision


4


Feasibility studies

A feasibility study decides whether or not the proposed system isworthwhile

A short focused study that checks If the system contributes to organizational objectives

If the system can be engineered using current technology and within budget

If the system can be integrated with other systems that are used


5/49

EngineeringDivision


5


Feasibility study implementation

Based on information assessment (what is required), informationcollection and report writing

Questions for people in the organization What if the system wasnt implemented?

What are current process problems?

How will the proposed system help? What will be the integration problems?

Is new technology needed? What skills?

What facilities must be supported by the proposed system?


6/49

EngineeringDivision


6


Elicitation and analysis

Sometimes called requirements elicitation or requirements discovery

Involves technical staff working with customers to find out about the

application domain, the services that the system should provide and

the systems operational constraints

May involve end-users, managers, engineers involved in

maintenance, domain experts, trade unions, etc. These are calledstakeholders


7/49

EngineeringDivision


7


Problems with requirements analysis

Stakeholders dont know what they really want

Stakeholders express requirements in their own terms

Different stakeholders may have conflicting requirements

Organizational and political factors may influence the system

requirements

The requirements change during the analysis process. New

stakeholders may emerge and the business environment change


8/49

EngineeringDivision


8


Social and organizational factors

Software systems are used in a social and organizational context.This can influence or even dominate the system requirements

Social and organizational factors are not a single viewpoint but are

influences on all viewpoints

Good analysts must be sensitive to these factors but currently no

systematic way to tackle their analysis


9/49

EngineeringDivision


9


Example

Consider a system which allows senior management to accessinformation without going through middle managers Managerial status: Senior managers may feel that they are too important to use a

keyboard. This may limit the type of system interface used

Managerial responsibilities: Managers may have no uninterrupted time where they

can learn to use the system

Organizational resistance: Middle managers who will be made redundant maydeliberately provide misleading or incomplete information so that the system will fail


10/49

EngineeringDivision


10


Requirements checking

Validity: Does the system provide the functions which best supportthe customers needs?

Consistency: Are there any requirements conflicts?

Completeness: Are all functions required by the customer included?

Realism: Can the requirements be implemented given available

budget and technology

Verifiability: Can the requirements be checked?


11/49

EngineeringDivision


11


Requirements validation

Concerned with demonstrating that the requirements define thesystem that the customer really wants

Requirements error costs are high so validation is very important Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an

implementation error


12/49

EngineeringDivision


12


Requirements validation techniques

Requirements reviews Systematic manual analysis of the requirements

Prototyping Using an executable model of the system to check requirements.

Test-case generation

Developing tests for requirements to check testability

Automated consistency analysis Checking the consistency of a structured requirements description


13/49

EngineeringDivision


13


Requirements management

Requirements management is the process of managing changingrequirements during the requirements engineering process and

system development

Requirements are inevitably incomplete and inconsistent New requirements emerge during the process as business needs change and a better

understanding of the system is developed Different viewpoints have different requirements and these are often contradictory

S G S f


14/49

EngineeringDivision


14


Requirements change

The priority of requirements from different viewpoints changes duringthe development process

System customers may specify requirements from a business

perspective that conflict with end-user requirements

The business and technical environment of the system changes

during its development

SWENG 580 Ad d S ft E i i


15/49

EngineeringDivision


15


Requirements evolution

Initialunderstanding

of problem

Changedunderstanding

of problem

Initial

Requirements

Changed

Requirements

Time



16/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

16


Enduring and volatile requirements

Enduring requirements. Stable requirements derived from the coreactivity of the customer organization. E.g. a hospital will always have

doctors, nurses, etc. May be derived from domain models

Volatile requirements. Requirements which change during

development or when the system is in use. In a hospital,

requirements derived from health-care policy



17/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

17


Requirements management planning

During the requirements engineering process, you have to plan: Requirements identification

How requirements are individually identified

A change management process

The process followed when analyzing a requirements change

Traceability policies

The amount of information about requirements relationships that is maintained

CASE tool support

The tool support required to help manage requirements change



18/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

18


Traceability

Traceability is concerned with the relationships betweenrequirements, their sources and the system design Source traceability

Links from requirements to stakeholders who proposed these requirements

Requirements traceability

Links between dependent requirements

Design traceability

Links from the requirements to the design



19/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

19


Traceability matrix

Req. id 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2

1.1 U R

1.2 U R U

1.3 R R

2.1 R U U

2.2 U

2.3 R U3.1 R

3.2 R


20/49



21/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

21


Joint application development

Joint application design (JAD) is a process whereby highlystructured group meetings or mini-retreats involving system users,

system owners, and analysts occur in a single room for an extended

period of time (four to eight hours per day, anywhere from one day to

a couple weeks).

JAD-like techniques are becoming increasingly common in systems planning andsystems analysis to obtain group consensus on problems, objectives, and

requirements.



22/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

22


Joint application design participants

Sponsor (top management, final say) Leader (facilitator, independent)

Users and Managers (requirements, business rules)

Scribe(s)

IS staff



23/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

23


Joint application design sessions

Most JAD sessions span a three- to five-day time period andoccasionally last up to two weeks.

The success of any JAD session is dependent upon proper planning

and effectively carrying out that plan.



24/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

24


Planning the JAD sessions

Before planning a JAD session, the analyst and sponsor must: Determine the scope of the project

It is also important that the high-level requirements and expectations of each JAD

session is determined.

Ensure that the sponsor is willing to commit people, time, and other resources to effort.

Planning for a JAD session involves three steps: Selecting location.

Selecting participants.

Preparing agenda.



25/49

EngineeringDivision

,ThePennsylvaniaS

tateUniversity

25


Room layout for JAD session

41' - 0"

30'-0"

Flipchart

IS Professionals

&

Other Observers

Users

and

Managers

JAD

Leader

Scribe

Workstation Printer

BlackboardOverhead Projector

Computer

Projection

Device

Food & Refreshments



26/49

EngineeringDivision,

ThePennsylvaniaS

tateUniversity

26


Selecting participants

Sponsor, analysts and managers select a leader. Leader may be in-house or contracted in.

One or more scribes must also be selected. Normally selected from the IS staff

IS Staff are selected from the development team(s)

Analyst and managers must select individuals from the usercommunity. Should be knowledgeable about their business area and able to articulate it.



27/49


ThePennsylvaniaS

tateUniversity

27


Conducting a JAD session

Session begins with brief overview of agenda and objectives. Leader should follow these guidelines:

Stick to agenda.

Stay on schedule (agenda topics are allotted specific time).

Ensure scribe is able to take notes.

Avoid technical jargon. Resolve conflicts (try not to defer).

Encourage group consensus.

Encourage user and management participation without allowing individuals to

dominate the session.

Make sure that attendees abide by the established ground rules.



28/49


ThePennsylvaniaS

tateUniversity

28


JAD document

The end product of a JAD session is typically a formal writtendocument. Essential in confirming the specifications agreed upon during the session(s) to all

participants.

Content and organization of specification obviously dependent on objectives of

session.

Analyst may choose to provide different set of specifications to different participantsbased upon their role.



29/49


ThePennsylvaniaS

tateUniversity

29


Benefits of JAD

An effectively conducted JAD session offers the following benefits: JAD actively involves users and management in the development project (encouraging

them to take ownership in the project).

JAD reduces the amount of time required to develop systems.

When JAD incorporates prototyping as a means of confirming requirements and

obtaining design approvals, benefits of prototyping are realized



30/49


ThePennsylvaniaS

tateUniversity

30


Quality function deployment

a method for developing a design quality aimed at satisfying theconsumer and then translating the consumers demand into design

targets and major quality assurance points to be used throughout the

production phase

(Akao, 1990)

Provides a structure for ensuring that customers wants and needare carefully heard, then directly translated into a companys internal

technical requirementsfrom analysis through implementation to

deployment.



31/49


ThePennsylvaniaS

tateUniversity

31


Voice of customer

What customers want and need from the product. Heard directly from customers and stated in their words, as much as

possible.

Forms basis for all analysis, design and development activities, to

ensure that products are not developed from only the voice of the

engineer, nor are they technology-driven



32/49


ThePennsylvaniaS

tateUniversity

32

g g

Background of QFD

First introduced by Yoji Akao in 1966. Applied to manufacturing, heavy industry and systems engineering

at first.

Applied to software systems by IBM, DEC, HP, AT&T and Texas

Instruments



33/49


ThePennsylvaniaS

tateUniversity

33

g g

QFD process (1)

The basic idea of QFD is to construct relationship matrices betweencustomer needs, technical requirements, priorities and (if needed)

competitor assessment.

To achieve this the following process is prescribed:1. Identify stakeholdersattributes or requirements

2. Identify technical features of the requirements3. Relate the requirements to the technical features

4. Conduct an evaluation of competing products

5. Evaluate technical features and specify a target value for each feature

6. Prioritize technical features for development effort.


34/49



35/49


ThePennsylvaniaS

tateUniversity

35

g g

Benefits of QFD

Improves user involvement Improves management support and involvement

Shortens the development lifecycle

Improves project development

Supports team involvement

Structures communication processes

Provides a preventive tool for improving quality

Avoids loss of information



36/49


ThePennsylvaniaS

tateUniversity

36

Designer as apprentice

A new computer system changes how its customers work.Designing such a system requires intimate knowledge of customers'

work and motives to ensure that the system supports them well. The

creation of a new system implicitly means designing the new work

practice it will supportThe fundamental problem in the relationship

between customers and designers is to enable learning: how dodesigners learn enough about customers' work to design well?

What kind of relationship allows customers to impart deep

knowledge about their work?

Beyer & Holtzblatt



37/49


ThePennsylvaniaS

tateUniversity

37

Apprenticeship

The relationship between master craftsman and apprentice standsout as a useful model.

The apprentice learns a skill from the master just as we want the

designer to learn about the customers work from the customer.



38/49


ThePennsylvaniaS

tateUniversity

38

Rationale

The critical aspects of the relationship are: Teaching ability is not needed

Seeing the work reveals what matters

Seeing the work reveals details

Seeing the work reveals structure



39/49


ThePennsylvaniaS

tateUniversity

39

Teaching ability is not needed

Customers cannot talk about their work effectively, but can talkabout it as it unfolds.

Don't have to work out the best way to present it, or the motives;

they just explain what theyre doing.

"I'm entering edits from my marked up copy here... I'm working in200% magnification so I can really see how things line up. It doesn't

matter that I can't see all the text in this magnification because I'm

not checking for continuity or natural flow of words; I'll do that in

another pass later..."



40/49


ThePennsylvaniaS

tateUniversity

40

Seeing the work reveals what matters

People are not aware of everything they do and sometimes why theydo it.

Some actions are result of years of experience and have subtle

reasons; others are habit and no longer have a valid justification.

The presence of an apprentice provides the opportunity for the

master (customer) to think about the activities and how they cameabout.



41/49


ThePennsylvaniaS

tateUniversity

41

Seeing the work reveals details

Unless we are performing a task it is difficult to be detailed indescribing it.

True in most cases, but especially true in decision-making. Often predicated on many issues.

Tendency to generalize and group together similar examples; but miss important

detail.



42/49

EngineeringDivisio

n,

ThePennsylvaniaS

tateUniversity

42

Seeing the work reveals structure

Patterns of working are not always obvious to the worker. An apprentice learns the strategies and techniques of work by

observing multiple instances of a task and forming an understanding

of how to do it themselves, incorporating the variations.



43/49

EngineeringDivisio

n,

ThePennsylvaniaS

tateUniversity

43

But the designer is not an apprentice!

Apprentices want to know how to do the work, designers want to findout what a system might do to support work. So, the designer: must be responsible for seeing work structure

must articulate their understanding

is trying to improve the work

has specific focus


44/49



45/49

EngineeringDivisio

n,

ThePennsylvaniaS

tateUniversity

45

Articulate their understanding

The designer doesnt demonstrate their understanding like anapprentice so isnt corrected when the their understanding is

wrongmust feedback to the customer instead.



46/49

EngineeringDivisio

n,

ThePennsylvaniaS

tateUniversity

46

Trying to improve the work

An apprentice is not expected to improve the process, the designeris.

If the designer has an idea for improving the process, this must be

fed back to the customer immediately (at the time).

Both customer and designer learn:

Customer learns what may be possible Designer expands understanding of the work (if the idea is shot down!)



47/49

EngineeringDivisio

n,

ThePennsylvaniaS

tateUniversity

47

Specific focus

The apprentice is there to learn whatever the master knows. The designer is there to address specific needs.

Must guide customer in talking about and demonstrating those parts of the work



48/49

EngineeringDivisio

n,

ThePennsylvaniaS

tateUniversity

48

Key points

RE is the process of eliciting, documenting, analyzing, validating andmanaging requirements

Many approaches exist, some more complete than others.

Crucial that there is a defined approach and that documentation

exists for each stage.

Documentation can range from high-level abstract statementsthrough psuedocode-like specifications to formal logics or models.

The elicitation process must take into account many disparate skills:

compsci, engineering, philosophy, social science.

Always striving to gather complete, precise and detailed

specifications of system requirements



49/49

EngineeringDivisio

n,

ThePennsylvaniaS

tateUniversity

References

General: I. Sommerville, Software Engineering, Addison-Wesley, 6th Ed.

JAD: J. Whitten & L. Bentley, Systems Analysis & Design Methods, McGraw-Hill, 4th Ed.

QFD:

S Haag, MK Raja & LL Schkade, Quality Function Deployment Usage in SoftwareDevelopment, Communications of the ACM, Jan 1996, pp41-49.

Y Akao, Ed. Quality Function Deployment, Productivity Press, Cambridge, MA, 1990.

T Tran & JS Sherif, QFD: An Effective Technique for Requirements Acquisition and

Reuse, Proc. 2nd IEEE Int. Software Engineering Standards Symp., 1995.

(ISESS'95), pp 191200.

Designer as Apprentice: H Beyer & K Holtzblatt, "Apprenticing with the Customer: A Collaborative Approach to

Requirements Definition ," Communications of the ACM, May 1995.

Lecture 02 RE Process

Documents

Transcript of Lecture 02 RE Process