1

Elicitation IIElicitation II

2

Non-Functional Requirements Knowledge Base

• Taxonomies proposed in the literature

• Guide the Elicitation Process

NFRs KB Elicitation

3

Software Quality Characteristics Tree Software Quality Characteristics Tree [Boehm 76][Boehm 76]

General utilityGeneral utility

As-is utilityAs-is utility

maintenabilitymaintenability

PortabilityPortability Device-independence

Self-containedness

Accuracy

Completeness

Robustness/integrity

Consistency

Accountability

Device efficiency

Acessibility

Communicativiness

Self-descriptiveness

Structuredness

Conciseness

Legibility

Augmentability

ReliabilityReliability

EfficiencyEfficiency

Human Human engineeringengineering

TestabilityTestability

UnderstandabilityUnderstandability

ModifiabilityModifiability

4

Types of Non-Functional Requirements [Sommerville 92]Types of Non-Functional Requirements [Sommerville 92]

Non-FunctionalNon-FunctionalRequirementsRequirements

ProcessRequirements

ProductRequirements

ExternalRequirements

DeliveryRequirements

UsabilityRequiremen

ts

EfficiencyRequiremen

ts

ReliabilityRequiremen

ts

PortabilityRequiremen

ts

Implementation

Requirements

StandardsRequirements

SpaceRequirements

CostRequirements

Interoperability

Requirements

LegislativeRequirements

PerformanceRequirements

5

NFR KB

• +– Knowledge Reuse– Antecipate implementation aspects– COnflict Identification

• -– Cost for building the KB– Gives the wrong impression it is complete

6

Active Participation of Actors

• +– Join clients and users– Validation

• -– Training– Appears to be efficient

7

Reverse Engineering

• +– Information availability (Code)– Reuse

• -– Information discontinuity– Very detailed Information

8

Reusing

• Define what will be reused• Define where to search for the object to reuse• Is the object stored using reusing principles ?• Shall have efficient ways to recover the reusing

component• Developers shall be motivated to produce reusable

objects and components• Selection of tools and COTS

9

Tools Selection

• Requirements for Selecting– Functional Requirements (FRs)

– Non-Functional Requirements (NFRs)

– Supplier

– Availability

– Supported Methodologies

– Training

– Integration

– Cost, cost, cost

10

Selecting Tools

• Build a Matrix – Identify functions (FRs)– Identify Characteristics (NFR)

• Process for eliciting matrix elements– Suppliers Documentation– Eliciting with clients (interviews etc)

11

Tool Selection

Evaluation• Evaluate Functions

– Grading• 0,1,2 (ternary scale)

• Other scales - Ex: bad enough, good

• To each function evaluate usability, integration, understandability documentation and reliability

12

Evaluation• Manual verification or use a tool• Evaluate to each package

– portability– evolution– platform– Compliance with standards– Number of allowed users

13

• grading– Final marks ( 1 .. * participants)– Compare results– Function Total– Property Total

14

COTS

Black Box

Input Output

15

COTS

• Ready to use Software

• “off the shelf”

• Find it at stores

• Instead of adapting the software to the company, the company has to adapt itself to the software

16

COTS

• +– Cost– Fast– Technical Support (not necessarily)– User Groups– Training (Be careful on costs here)

17

Selection Process

• Study the Market (What is available)

• Select

• Adapt

• Integrate

• Update

18

Requirements for Selection

• Supplier’s Reputation and maturity

• Guaranties given by the suppliers for support

• Supplier’s stability

• Possibility of changing the product in future versions

19

Factors Influencing Selection

• Time to get to a final selection of products

• Number of possible COTS

• Availability of a User Group

• Resources available for evaluation and selection activities

• Has this product been used before ?

20

Challenges

• How to estimate quality of support on a long term basis?

• How to evaluate costs associated with the acquisition of certain COTS?

• What about Maintenance?

21

Challenges

• How to verify if the product complies with other standards?

• How to describe and qualify qualit aspects (NFRs) in COTS?

22

Reuse

• +– productivity– quality

• -– Level of abstraction (requirements)– Possibility of a real reuse

23

Which technique to use?

• Depends on the situation

• Análise the context

• Respect limitations

24

Example• Health Care Domain

– Questionnaires • Less than 10% returned• Vast majority just partially filled• Nurses and Physicians usually work in a 12 hour

shift

– Enterviews• Lack of turtworthiness • Formality • Open-ended get better response• List of topics

25

Example

• Health Care domain– Protocol Analysis

• Almost impossible (privacy, inconvineit)

• Imagine a Heart Attack !!!!

– JAD• Usually to solve conflicts

• Etical questions a concern

• competitivity

26

Exemple

• Health Care domain– Vídeo and Audio (transcriptions)

• Legal questions make it hard to be used

– Use Case and Scenarios• Well accepted

• Scenarios are more wellcomed

– Observation• Confirm results

27

Comunicating

• Presentation

• Understanding

• Languages

• Level of Abstraction

• Feedback

28

PresentationPresentation

The way the information is shown. Different ways may help or prejudice one to understand the information

Distribuição de Vendas

0%5%

10%15%20%25%30%35%40%45%

Produto A Produto B Produto C Produto D

Pe

rce

ntu

al

Product A 15%Product B 40%Product C 20%Product D 25%

Sales DistributionSales Distribution

Product A Product B Product C Product D

29

LanguageThe language is the reflection of a society’s culture. To

understand something that is important to a certain society we have to understand its language. We must understand the language before we elicit the needs

Examples

Zip a file, Review Patient’s Report, ILS

30

Level of abstraction

The communication can be noisy if the participants are talking using different levels of abstraction. Typical conflict when you place generalist and specialists together

Example

We should conquer new Markets (VP Sales)X

We should distribute Salesmen (Sales Manager)

31

Feedback Feedback

We should demand the receiver of an information to return the information back to the source until the source answers positvly. Summarize, rephrase, confirm

?

a

a

32

Communication• Precision Models

– Reference Standards• Results ( What are the goals of this meeting?)

• Retrocession ( Summarize what has been discussed up to now)

• If (If you were the user, how should you do?)

– Procedures• Evidence (How the result was obtained?)

• Relevance (Thanks, the question seems ok, but how is it related to the problem at hand?)

– Pointers• Could you be more specific?

• To what are you referring?

33

Precision Models(neuro linguistic programming)

What is the order for the following sequence?

8,5,4,9,1,7,6,10,3,2

34

Precision Models(neuro linguistic programming)

Alphabethic Context Dependent

Almost emptyAlmost fullSomething to drink

Can you give me this information untill Friday? What should we do to have this information before Saturday?

35

Precision Models

Determination / Establishing the Context:

• If:– The policy doesn’t allow…, but suppose…

What would we do? (On the edge)

– If in six months …. (time)– Could you act as a user? What the user would

answer? (Actor)

36

Precision Models

• Determination / Establishing the Context:

• If:– Imagine the main user/stakeholder enters your

room and ask for one more alternative. What would you say? (environment)

– Suppose you have the information how would you use it? (Information)

37

Heuristics for communication

• A good figure is worth 1000 words• Communication should flow in both

directions• Avoid Noisy• Avoid metaphors with your area of

communication • Identify different viewpoints• Learn with humility

38

General Heuristics

• Ask what? How ? Why?

• Who should we talk to? Why?

• What to study? Why?

• Where to begin?

• How to represent? To Whom? How?

• Always Review?

39

Social Aspects

• Ecology of the system:– Metaphor of the phisical industrial plant –

Before choosing a place and a operational procedure we must evaluate the disturbances this industrial plant could bring to the envirnment once it is operational

40

Social Aspects

• London Ambulance Service:System developed almost withou consulting the

Users– The proposd system would significantly impact the way

the staff carried out their tasks, however regarding the several ambulance teams there was only a few questions about the “new proposed way of doing things”

41

Social Perspective

• London Ambulance Service :– “The general attitude towards the information

system was incredibly positive. Everyone recognized that computers in this area is primordial to enhance efficience. However, there is a feeling, also unanime, the the actual system and the way it was introduced was the future way. There is no TRUST in the system which resulted in an expectitave of failure instead of success from the staff viewpoint”

42

Social Aspects

• London Ambulance Service :USe the sytem to change job practices

– “The new system would eliminate these practices, the management used to think”

– “The result is that the staff saw the changes/ New procedures as a “Straitjacket” in which they were trying to find some flexibility

43

Social Aspects

• London Ambulance Service:Conclusion from the investigation:

The upper management was naive to believe a system could, by its own power, bring changes to human traditional practices. Experiments in many different environments prove that information systems are not capable to influence changes this way. They can only help on the process and any attempt to force these changes is likely to fail.

44

Social Aspects

• Broder View:– sociology– Gorups with the same concerns– grupos of power– Policies and Politics

45

Social Aspects

• Ortogonal to everything we saw for elicitation

• Focus is on the social aspects not technology

• Demands more resources• Contrary to the common thinking from

commertial packages such as ERP• Important because is long term focused