requirements engineering - joensuucs.joensuu.fi/pages/tenhunen/reqeng/lnotes/re_1-4.pdf · 2010. 1....

Requirements Engineering

Vesa TenhunenUniversity of JoensuuDept. of Computer Science & Statistics29.10.2008

http://cs.joensuu.fi/pages/tenhunen/reqeng/


Requirements Engineering, 175412, 5 cu "Vaatimusten käsittely" in Finnish A Master's level course in Software Engineering

compulsory to every MSc student in SE optional to all the others (including IMPIT students)

Prerequisites basic knowledge about software engineering (e.g. passed courses

like "Ohjelmistotuotanto" or "Järjestelmäkehitys")


Lectures Wednesdays 1214 in T/D106 Thursdays 1214 in T/D106 12 lectures (24 hours)

Lecture notes no paper versions – downloadable PDF files from course homepage

Supplementary reading delivered during lectures, related questions will appear in the

exercises and the exam


Literature: Bray, Ian K., An Introduction to Requirements Engineering (Addison

Wesley 2002) Kovitz, Benjamin L., Practical Software Requirements (Manning

Publications Company 1999) Lauesen, S., Software Requirements (AddisonWesley 2002) Leffingwell, D. & Widrig, D., Managing Software Requirements

(AddisonWesley 2003)


Exercise sessions group 1: Mondays 1618 in T/B181 group 2: Tuesdays 1618 in T/B181 6 sessions (12 hours)

Exercise tasks tasks are published weekly on course homepage to pass the course, you must do at least one third of the tasks and

mark them as done in the exercise sessions no points for emailed tasks! bonus points awarded for tasks exceeding the minimum of 1/3

(max. 10 % of the maximum exam points)


Assignment compulsory part of the course scope ca. 2 cu can be done individually or in pairs (max. 2 students) more information later

Exam on Thursday, December 11th at 12:0014:00 in T/2D106


Grading exam: 2/3 of the grade assignment: 1/3 of the grade exercise bonus points (for those exceeding 1/3 of the tasks) scale: 50 % = 1, 60 % = 2, 70 % = 3, 80 % = 4, 90 % = 5

Enrollment for the course everyone present should have already done that if not, use WebOodi and do it before the next lecture

Course homepage: http://www.joensuu.fi/tkt/ Studies Courses Requirements engineering direct link: http://cs.joensuu.fi/pages/tenhunen/reqeng/


Goals: basic concepts significance processes classifications methods modelling testing

Contents

1. Introduction 2. Requirements 3. Processes and Models 4. Requirements Elicitation 5. Requirements Analysis and Modelling 6. Requirements Documentation 7. Requirements Validation and Negotiation 8. Requirements Management 9. Testing10. Tools

Introduction

Standish Group (www.standishgroup.com) has tracked IT projects since 1994

Three categories for project outcome:1. succeeded: project is finished within schedule and budget, and all

required features and functions are implemented2. challenged: project is finished and product works, but schedule

and/or budget is exceeded and some functions are not implemented3. failed: project is canceled or product is not implemented

Introduction

Project outcomes in 2001 according to Standish Group's CHAOS report:

(http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf)

FailedSucceededChallenged

28 %

23 %

49 %

Introduction

The development of project outcomes 19942000:

(http://www.standishgroup.com/sample_research/PDFpages/extreme_chaos.pdf)

2000

1998

1996

1994

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

28%

26%

27%

16%

23%

28%

40%

31%

49%

46%

33%

53%

ChallengedFailedSucceeded

Introduction

Major factors contributing to project success:

Executive Support

User Involvement

Experienced Project Manager

Clear Business Objectives

Minimized Scope

Standard Software Infrastructure

Firm Basic Requirements

Formal Methodology

Reliable Estimates

Other

0 2 4 6 8 10 12 14 16 18 20

18

16

14

12

10

8

6

6

5

5

Introduction

Major factors contributing to project failure:

Incomplete Requirements

Lack of User Involvement

Lack of Resources

Unrealistic Expectations

Lack of Executive Support

Changing Reqs. & Specs

Lack of Planning

Didn't Need Any Longer

Lack of IT Management

Technology Illiteracy

Other

0 2 4 6 8 10 12 14

13.1

12.4

10.6

9.9

9.3

8.7

8.1

7.5

6.3

4.3

9.9

Introduction

Requirements have been and still are the main source of errors in software projects

(Source of errors on a US Air Force project; Sheldon, F. et al., Reliability Measurement from Theory to Practice, IEEE Software 9, 1992)

Logic Design 28Other 7

Documentation 2

Requirements 41

Human 5Environment 5

Data 6

Interface 6

Introduction

Specification

Design

Development

Testing

Delivery

Maintenance

0,1-0,2

0,5

1

2

5

20

Relative price of fixing a requirement error in different phases

Contents


Requirements

What is a requirement?1. A condition or capability needed by a user to solve a problem

or to achieve an objective2. A condition or capability that must be met or possessed by a

system or system component to satisfy a contract, standard, specification or other formally imposed document

3. A documented representation of a condition or capability as in 1 or 2

(IEEE Standard Glossary of Software Engineering Technology)

Requirements

Examples of requirements: a system for university students (like WebOodi) "The students shall use the system to enroll for the courses." "Each user has his or her own user name and password which shall

be used to log into the system." "The system shall read the information about the current courses

from the database XYZ." "New students shall be able to use all the student related functions of

the system after one hour of training."

Requirements

Customer understands the business domain, developers understand SE domain

Requirements (and requirements engineering) are a way to bridge the gap between these

Business Domain Software Engineering Domain

Requirements

Requirements can be either functional or nonfunctional1. Functional requirements

describe the system's functionality can be modelled as use cases

2. Nonfunctional requirements describe the system's properties

performance, usability, security, maintainability etc.

Requirements

Functional requirement answers to question WHAT, not HOW Functional user requirements can be highlevel descriptions of

what the system should do Functional system requirements describe in detail all the

system's services

Requirements

”The User can browse the whole warehouse catalogue and select whatever subpart she wants.”

”Each product has a unique identification (PRODUCT_ID), and the User can attach it to the permanent memory of her user account.”

Get productinformation

Browsecatalogue

Findproduct

Seeadditional

information

<<extend>>

<<extend>>

<<extend>>

User

Requirements

Nonfunctional requirement describes a system's property or constraint e.g. requirements for reliability, response time, storage e.g. speed of data transfer devices, presentation form of system data

Not directly related to system's functionality Nonfunctional requirements can be more critical than

functional: if they are not implemented, the system may be useless

Requirements

Nonfunctional requirements can be divided into different classes product requirements

define that the delivered product must work in some certain way (e.g. reliability, performance, time to recover from error etc.)

organisational requirements define the practices and methods used in supplier's organisation (e.g.

process standards in use, requirements for implementation etc.) external requirements

arise from factors outside of product or its implementation process (e.g. legal issues, compatibility etc.)

Requirements

Classifications of nonfunctional requirementsNon-functionalRequirements

ProductRequirements

OrganisationalRequirements

ExternalRequirements

ReliabilityRequirements

TransferabilityRequirements

CompatibilityRequirements

EthicalRequirements

UsabilityRequirements

EfficiencyRequirements

DeliveryRequirements

ImplementationRequirements

Standards'Requirements

LegislationalRequirements

PerformanceRequirements

SizeRequirements

PrivacyRequirements

SafetyRequirements

Requirements

Metrics for nonfunctional requirementsAttribute MetricSpeed # of performed events / second

Response timeScreen rewrites / second

Size Megabytes# of ROM chips

Ease of use Time for training# of help screens

Reliability MTBFFrequency of errorsUptime

Robustness Mean time to recover from failurePercentage of events leading to failureProbability of data corruption

Transferability Percentage of platformdependant statements# of target systems

Requirements

Requirements engineering can be defined as:

"the process of finding out, analysing, documenting and checking the requirements of the system"

(Sommerville 2007)

"a systematic way to eliciting, organizing and documenting the requirements of the system, and a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system"

(Leffingwell & Widrig 2003)

Requirements

Requirements engineering (RE) is a set of activities concerned with

identifying and communicating the purpose of a softwareintensive

system, and the contexts in which it will be used. Thus RE acts as a

bridge between the real world needs of users, customers and other

constituencies affected by a software system, and the capabilities and

opportunities afforded by softwareintensive technologies.

It isn't just a phase or stage

Communication is as important as

analysis

Designers need to know how and

where the system will be used

Quality means fitforpurpose; you can't say anything about quality unless you understand the purpose

All stakeholders need to be identified, not just the user and customer

Requirements are partly about

what's needed...

... and partly about what is possible

Requirements

Maybe you won't need requirements engineering... ...if you have two persons working with ten requirements

But how about... ...ten persons working with 200 requirements? ...200 persons with 1.000 requirements? ...building an Airbus A320 with 300.000 requirements?

How to organise, prioritise, control access to and provide resources for all the requirements?

➔A set of organised and systematic processes and techniques is needed

Requirements

RE consists of two parts: requirements development (RD), consisting of

eliciting, analysing, modelling, documenting, agreeing on, and reviewing of requirements

requirements management (RM), consisting of maintenance, change control, and traceability of requirements

Requirements

The boundary between RD and RM

Marketing, Customers, ManagementRequirements

Analyse,Document,

Review,Negotiate

RequirementsChange Process

MarketingCustomersManagement

ProjectEnvironment

Baselined Requirements

current baseline revised baseline

RD

RM

Source: Wiegers, K.E.: Software Requirements 1999″ ″

Requirementschanges

Projectchanges

Contents


Processes and Models

Requirements engineering is one process among other software engineering processes

Waterfall model makes requirements fixed in an early stage

In spiral model risks are notified and implementation proceeds incrementally

Iterative model is a combination of waterfall and spiral models; the lifecycle phases are repeated

Because the requirements change as the project advances, the requirements must be managed


Requirements engineering is a process: inputs are repeatedly transformed into desired outputs and results

Benefits of a mature process are e.g. better management of complex projects improved quality and customer satisfaction keeping project within budget and schedule complying to standards and guidelines is easier

RE is a design process: it requires creativity, multidisciplinary cooperation, knowledge of techniques and knowledge and experience about the application domain


RE as a process – inputs and outputs

Existing informationabout systems

Stakeholders'needs

Organisation'sstandards

Regulations

Knowledge aboutapplication domain

Systemspecifications

Negotiatedrequirements

Systemmodels

Requirementsengineering

process


Examples of inputs: requirements for an online bookstore existing information about system: “The system shall work with all

web browsers supporting javascript.” stakeholders' needs: “The customer shall be able to review her

purchases and to see their status in different phases of delivery.” organisation's standards: “System platform shall be the latest

versions of SUSE LINUX Enterprise Server and Apache HTTP Server that are approved by the IT department.”

regulations: “All customer information shall be stored and managed according to law of protection of personal data (523/1999).”

knowledge of application domain: “Each book shall be identified with a unique 10digit ISBN code.”


RE processes have large variability between different organisations due to technical maturity commitment organisational culture application domain customersupplier relationship etc.

There is no single ideal or correct RE process Process model is a simplified description of a process made

from a particular point of view


Waterfall modelPerceived

need

Requirement

Design

Implementation

Testing

Operation


Vmodel

Requirementspecification

Systemspecification

Technicaldesign

Productdesign

Moduledesign

Coding

Unittesting

Integrationtesting

Systemtesting

Systemreview

Acceptancetesting andoperation


Prototyping

Designprototype

RequirementsImplementation

prototype

OperationTestingImplementationDesignDocumentationrequirements

Testprototype


Spiral model


Iterative model

Elaboration Construction TransitionInception

Architeration

Prelimiteration

Deviteration

Deviteration

Transiteration

. . . . . . . . . . . .

Release Release Release Release Release Release Release Release


Activities in an iterative modelElaboration Construction TransitionInception

Requirements

Analysis & Design

Implementation

Test

Deployment

Configuration &change management

Project management

Initial Elab 1 Elab 2Const

1Const

2Const

NTran

1Tran

2


START

Requirements elicitation

Requirements validation

Requirements analysisand negotiation

Requirements documentation

Informal requirements

Requirements specification draft

Agreedrequirements

Requirementsspecification

and validationreport


Actors in RE process (or any other process) are persons who, in one way or another, participate in implementing the process

Actors are not defined as individuals but as roles In RE the actors are

participants in the problem to be solved participants in the solution

Role diagrams state which actors take part in which activity


Rapid Application Development – role diagram for prototyping

Understandproblem

Establishoutline

requirements

Selectprototyping

system

Developprototype

Evaluateprototype

Req.engineerDomain expert

End user

Req.engineerEnd user

SoftwareengineerProject

manager

Req.engineerSoftwareengineer

End userDomain expertReq.engineer

Softwareengineer

Actions

Roles


Requirements engineering has been defined in different kind of standards (ISO) and process improvement models (CMMI and SPICE)

ISO IEC 90003 2004 identify and meet customer requirements establish methods that can be used to identify customerrelated

requirements and to authorise and track changes in them evaluate risks related to requirements etc.


CMMI (Capability Maturity Model Integration) is a de facto standard in assessing maturity of software organisations

LEVEL 1 – Initial LEVEL 3 – Defined (continued) N/A Organizational Project FocusLEVEL 2 – Managed Organizational Process Definition Requirements Management Organizational Training Project Planning Integrated Project Management Project Monitoring and Control Risk Management Supplier Agreement Management Integrated Teaming Measurement and Analysis Integrated Supplier Management Process and Product Quality Assurance Decision Analysis and Resolution Configuration Management Organizational Environment for IntegrationLEVEL 3 – Defined LEVEL 4 – Quantitatively Managed Requirements Development Organizational Process Performance Technical Solution Quantitative Project Management Product Integration LEVEL 5 – Optimizing Verification Organizational Innovation and Deployment Validation Causal Analysis and Resolution


Requirement management processes on CMMI level 2: obtain an understanding of requirements obtain commitment to requirements manage requirements changes maintain bidirectional traceability of requirements identify inconsistencies between project work and requirements


Requirement development processes on CMMI level 3: develop customer requirements

elicit needs develop the customer requirements

develop product requirements establish product and product component requirements allocate product component requirements identify interface requirements

analyse and validate requirements establish operational concepts and scenarios establish a definition of required functionality analyze requirements analyze requirements to achieve balance validate requirements


Connections between requirements development, management and other process areas in CMMI

Riskmanagement

Configurationmanagement

Projectplanning

Requirementsdevelopment

Requirementsmanagement

Productintegration

Verification

TechnicalsolutionValidation

Projectmonitoring and

control


ISO/IEC 15504 aka SPICE (Software Process Improvement and Capability dEtermination) is an international standard for process improvement and capability assessmentlevel 5: optimizinglevel 4: predictablelevel 3: establishedlevel 2: managedlevel 1: performedlevel 0: incomplete

5

4

3

2

1

0


In SPICE, the processes are classified into nine process areasI PRIMARY II SUPPORTING III ORGANISATIONALAcquisition (ACQ) Support (SUP) Management (MAN)

ACQ.1 Acquisition Preparation SUP.1 Quality Assurance MAN.1 Organizational AlignmentACQ.2 Supplier Selection SUP.2 Verification MAN.2 Organization ManagementACQ.3 Contract Agreement SUP.3 Validation MAN.3 Project ManagementACQ.4 Supplier Monitoring SUP.4 Joint Reviews MAN.4 Quality ManagementACQ.5 Customer Acceptance SUP.5 Audit MAN.5 Risk Management

Engineering (ENG) SUP.6 Product Evaluation MAN.6 MeasurementENG.1 Requirements Elicitation SUP.7 Documentation Process Improvement (PIM)ENG.2 System Reqs. Analysis SUP.8 Configuration Management PIM.1 Process EstablishmentENG.3 System Architectural Design SUP.9 Problem Resolution Management PIM.2 Process AssessmentENG.4 SW Requirements Analysis SUP.10 Change Request Management PIM.3 Process ImprovementENG.5 SW Design Resource & Infrastructure (RIN)ENG.6 SW Construction RIN.1 Human Resource MgmtENG.7 SW Integration RIN.2 TrainingENG.8 SW Testing RIN.3 Knowledge ManagementENG.9 System Integration RIN.4 InfrastructureENG.10 System Testing Reuse (REU)ENG.11 SW Installation REU.1 Asset ManagementENG.12 SW & System Maintenance REU.2 Reuse Program Mgmt.

Supply (SPL) REU.3 Domain EngineeringSPL.1 Supplier TenderingSPL.2 Product ReleaseSPL.3 Product Acceptance Support

Operation (OPE)OPE.1 Operational UseOPE.2 Customer Support


IEEE STD 8301998 IEEE Recommended Practice for Software Requirements

Specifications content and qualities of good software requirements specification,

sample outlines not ideal, but gives some advice on how to write requirements the specifications vary a lot depending on type of the system being

specified

RE Road Map

PPRROOBBLLEEMM

DDOOMAMAIINN

Problem domain is the home of users and other stakeholders who have technical or business needs requiring to be solved

RE Road Map

Needs

PPRROOBBLLEEMM

DDOOMAMAIINN

Stakeholder needs must be collected by studying the problem domain

RE Road Map

Features

A feature is a service provided by the system that fulfills one or more stakeholder needs

PPRROOBBLLEEMM

DDOOMAMAIINNNeeds

RE Road Map

Needs

Features

Softwarerequirements

Requirement is a precise and detailed description of a feature for implementing the system

PPRROOBBLLEEMM

DDOOMAMAIINN

RE Road Map

Needs

Features


SOLUTIONDOMAIN

}

}}

Solution domain is a description of the system, represented by features and requirements that will drive its design and implementation

PPRROOBBLLEEMM

DDOOMAMAIINN

PPRROOBBLLEEMM

DDOOMAMAIINN

RE Road Map

Data collection

Needs

Features


Test cases

Trac

eabi

lity

}

}}Solution

domain PRODUCTTO BEBUILT

Contents


Requirements Elicitation

Test cases

Trac

eabi

lity

}

}}Solution


Features


PPRROOBBLLEEMM

DDOOMAMAIINN Data collection

Needs


Problem analysis is used to gain understanding of the problem so that a system providing the solution can be build

The actual customer needs can be dug out with problem collection

The required system features can be derived from analysis of needs

The features wanted are described as requirements


Requirement can also be defined more like a system's feature than a user's need: The requirements are [...] descriptions of what should be

implemented. They are descriptions of how the system should function [...] They can be constraints for system's development process. (Sommerville & Sawyer 1997)

What: a feature the system must have for solving an existing problem

How: product parameters functional and nonfunctional requirements

Constraints: process parameters


To find out requirements for a system, several things must be determined first, including system's scope and goals roles of different stakeholders and users tasks and responsibilities of the persons in different roles stakeholder needs and their prioritisation workflow, practices of use structure of the processed data

Requirements ElicitationProblem Analysis

Problem analysis is a process to find out and to gain understanding of the real problems and user's needs, and to find solutions to them

PPRROOBBLLEEMM

DDOOMAMAIINN

Domain of possible solutions


"A problem can be defined as the difference between things as perceived and things as desired."

(Gause & Weinberg 1989) If a user perceives something as a problem, then it is a

problem! There are, however, many different ways to address the

problem – we do not always need to build a new system If we do, our aim is to define and implement a new system that

narrows the difference between "perceived" and "desired"


A problem must be described, conceptualized and made sure that everybody see it similarly

Finding root causes leads often to better understanding of the real problem

Causes of the problem and their relationships must be understood WHAT is the cause WHY the cause exists WHERE the cause appears WHEN the cause appears WHO confronts the cause HOW the cause affects the problem

Requirements ElicitationPhases of Problem Analysis

There is no point in trying to create a solution before the problem is understood well enough

Phases of problem analysis (Leffingwell & Widrig 2003):1. Gain agreement on the problem definition2. Identify the problem's root causes3. Identify the users and other stakeholders4. Define the system's scope5. Identify the solution's primary constraints


1. Gain agreement on the problem definition

What is the problem Describe the problem

To whom does it affect Identify and define the stakeholders

What/where does it affect Describe the problem's effects

Solution's benefits List the benefits that the solution will provide

... ...


2. Identify the root causes

Fishbone diagram

Problem

Cause 1 Cause 2 Cause 3

Cause 4 Cause 5 Cause 60

5

10

15

20

25

30

35

40

45

50

Cause 1Cause 2Cause 3Cause 4Cause 5Cause 6

Pareto diagram


3. Identify the users and other stakeholders identify all the stakeholders – not just customers – and understand

their different views and needs end users of the system those who use the results provided by the system those who are responsible for the system's maintenance “roundabout” users – outside agencies, customer's customers etc.


4. Define the system's scope

Othersystems

Internet

Newsoftwaresystem


5. Identify the solution's primary constraints customers subcontractors competitors authorities technology economics system platform ... §§ §§§§ §§

€€€ $$$

€€€ $$$


After a careful problem analysis, the project team can be reasonably confident that it has understood well both the problem to be solved and the root causes

behind it identified thoroughly all stakeholders (whose ”judgment” tells in the

end whether the system is successful or not) understood the scope and where the solution's boundaries are most

likely to be found understood both the constraints and liberties for solving the problem

Requirements ElicitationResolving Customer Needs

Resolving customer's needs or requirement elicitation is usually a difficult task domain information can be fragmented

no clear, single document contradictory sources

tacit knowledge hard to formalize commonly used "selfevident" knowledge

difficulties in observation those who know are often busy observing work practices will change them

distortions company culture, personal relations etc. influence on what is told users may not want to tell everything

Requirements ElicitationAn Example

Problem domain: loan department of a large bank. Supplier's representative tries to resolve the rules and actions involved in granting a loan

Possible difficulties: implicit knowledge – not all the rules can be found in documents controversial knowledge – users have various interpretations of rules controversy between words and deeds – users don't do their work as

they (or their superiors) describe observation effect – users change their habits when watched distortion – users may fear for their jobs, so they show only tasks

requiring manual input


There are many methods and techniques to resolve customer needs

Different methods are appropriate in different situations and they usually complement each other

An appropriate set of methods must be selected for each project


Traditional methods: check lists inspection of documents collecting "hard data" interviews

open closed

questionnaires meetings


Collaboration techniques: limited topic workshops brainstrorming sessions JAD/RAD workshops prototyping participatory design

Cognitive techniques: knowledge acquisition techniques protocol analysis task analysis


Contextual methods: ethnographical techniques

observation ethnomethodology

discourse analysis analysing uses of written, spoken or signed language

sociotechnical methods soft systems methodology


Presentation methods: goaloriented method: starts with writing down

organisation's goals requirements defining how the new system leads to attaining goals obstacles indicating when a goal is impossible to attain constrains indicating when a goal is possible to attain

and continues with creating a more finegrained goal hierarchy; result is a description of why the requirements are what they are


Presentation methods (cont.): use cases and scenarios simulation

especially appropriate when the customer representatives are inexperienced (ie. the customer hasn't previously had a comparable system)

prototypes must be thought out beforehand what is wanted to find out with

prototype and how it is measured after prototype is finished prototypes can be classified as explanatory experimental and evolving

Requirements ElicitationTraditional Methods

Inspection of documents sources: reports, organisation charts, procedure guidelines, task

descriptions, documentation of existing systems, etc. helps to get information about the customer before meeting users and

stakeholders, helps in preparing other methods of information gathering, may tell the detailed requirements of the current system

written documents are not necessarily ”true”, they may contain a lot of irrelevant information

method is suitable in situations where the supplier is not familiar with the customer and its organisation


Collecting "hard data" recognising hard data repositories

indicators, economical information, reports used in decision making, survey results, marketing information, etc.

selecting a representative sample no use to go through all information, but the sample must be large

enough pros and cons similar to document inspection, but cost of data

analysis may be higher


Interviews one of the most important and most commonly used methods wellsuited for defining problem domain and eliciting user need

understanding real problems bringing forth possible solutions viewpoint of users, customers and other stakeholders

interviews must be conducted properly thorough preparations right questions for right persons accurate recording of answers recapitulation KERTAUS in the end to ensure understanding

open or closed


Questionnaires fast and easy method problems: small number of answers and lack of communication can be used before interviews to find suitable interviewees or

afterwards in complementing interviews no substitute for interviews!

Meetings used in summaries and to give and to receive feedback e.g. meeting of participants in the end of different project phases

discussion of results decision about requirements agreeing on planning, etc.

Requirements ElicitationCollaboration Techniques

Workshops efficient way to collect requirements key stakeholders meet and talk about the system max. length of the workshop is one day requires and skilled and experienced facilitator problems and solutions are generated with brainstorming


Joint/Rapid Application Development workshops a 35 days long workshop instead of interviews, usage of a lot of visual tools systematic and rational approach: requirements elicitation and

analysis process is defined with brainstorming sessions and topdown analysis

clear documents every JAD session produces a document and its content is agreed upon

during the same session


Prototyping possibility to demonstrate something in an early state instant feedback for solution proposals better estimates for budget and schedule better detection of unknown and undefined requirements disposable prototype (discarded after feedback) or development

prototype (its development is continued until finished product) problem: customer may get an impression of development taks being

easy and fast

Requirements ElicitationCognitive Techniques

Knowledge elicitation techniques aimed to discover expert knowledge and expertise

Protocol analysis eliciting knowledge about work practices based on thinking aloud and description of thoughts direct relation with actual work – easy to spot problems with current

system self reflection is unreliable and lacks a social dimension

Requirements ElicitationContextual Approaches

”Ethnographic” techniques participating observer becomes a part of customer's organisation can reveal al lot of information that is impossible to gain with any

other technique extremely time consuming, the constructed ”big picture” may be

difficult to analyse Ethnometodology

subdomain of anthropology: finding different behavioural patterns with similar purpose and meaning

tightly controlled research methods, used to gain knowledge of social situations

Requirements ElicitationProblems

There are many problems and difficulties customer knows what she wants, but cannot express it customer doesn't really know what she wants customer thinks she knows what she wants (until she gets what she

said she wants) supplier thinks she knows the customer's needs better than the

customer Users are experts in their work Usually users know better what they do not want – let them tell

about that

Requirements ElicitationProblems

What is not commonly regarded as requirements? system's structure implementation techniques development methods development environments implementation languages criteria for reuse

Customer shouldn't be allowed to set constrains to any of these

Requirements ElicitationInterviews

Interview is a simple and direct technique and it can be used in most situations

Two options closed (or structured) interview: questions made in advance; a clear

purpose; heavy workload; more information gathered, yet some things can remain uncovered

open interview: more like a facetoface conversation; no premeditated questions (or just few); suitable in charting basic information; doesn't produce systematic data

The effect of interviewer's biases and prejudices can be circumvented with contextfree questions


Steps in conducting an interview: prepare questions in advance and review their suitability (C) familiarise yourself beforehand with interviewee's and her

organisation's background (start interview with confirming them) use recorder or write down the answers review your list of questions time to time (C) let the interviewee answer in her own time and with her own words make a recap in the end, or a few times before, of the most important

things and confirm you got them correctly make a summary of the three most important needs that came up

during the interview

(C) = closed interview


It doesn't take many interviews to find out the most critical needs provided that stakeholder analysis is conducted properly

The summary of the three most important needs starts usually to show some common themes after a few interviews 10 interviewees x 3 needs != 30 requirements

Summaries of these most important needs is a starting point for building a requirements repository

Requirements ElicitationRequirements Workshop

Workshop is on of the most efficient ways to elicit requirements if you have resources only for one method, use this

Workshop gathers together all stakeholders' key personnel for a short time (max. one day), during which they concentrate only on requirements

Efficiency can be improved by appointing a requirements engineering expert as a workshop facilitator (who is otherwise not involved in the project)

The most important part of workshop is brainstorming session


Benefits of wellorganised workshops improves team spirit and commitment to project all the stakeholders get a chance to voice their opinions helps the stakeholders and developers gain a common understanding

about system's purpose can expose problems and offer solutions to them in work methods

that could interfere with project results are available right after the workshop

Problems of workshops relies a lot on the facilitator heated arguments and other misbehaviour possible distortions in the results


Preparing a workshop: selling the idea making sure the right stakeholders will participate meticulously taking care of arrangements preparing and distributing the material beforehand

project information innovation enticing reading

appointing an outsider facilitator (if possible) creating an agenda and schedule


Conducting a workshop: new ideas during brainstorming sessions

no critique, no (lengthy) conversations discussion, evaluation and pruning of ideas after brainstorming

debates,votes prioritisation of ideas facilitator keeps things rolling and adheres to the schedule in the end of the day, the found requirements are collected and

delivered to the development team If it's not possible to physically get everyone together,

brainstorming can be arranged online

Requirements ElicitationStoryboard

Storyboard (kuvakäsikirjoitus) gives an opportunity to get feedback and reactions from customer in an early phase

Storyboard can be passive, pen and paper, screen shots, PowerPoint slides

active animation, "PowerPointware"

or interactive demonstration

Requirements ElicitationStoryboard

Storyboard is a very cheap and flexible technique Suitable for situations where customer isn't sure what she

wants For every function/action/task, three things must be described

in storyboards who are the actors

users, systems or equipment what happens to them

behaviour of actors when interacting with the system how it happens

events, states, state changes

Requirements ElicitationFeatures

Test cases

}

}}Solution



PPRROOBBLLEEMM

DDOOMAMAIINN Data collection

Needs

Trac

eabi

lity Features


Features at general level are derived from the needs collected from users and other stakeholders

Features are highlevel descriptions of system's functions It is necessary to keep features separate from needs

often users talk about features when they describe their needs Difference must be kept in mind while eliciting requirements

if the need behind a feature is not understood or recognised, implementing the feature may not fulfil user's need


Examples of features

Application Domain (Functional) FeatureElevator control: Manual control of doors in emergency

Warehouse inventory: Show real time status of all items

Defect tracking: Show trend data for quality tracking

Salaries: Show only selected fields in reports

Lightning control: Random lightning while building is empty

Launching nuclear missile: Launch requires two separate confirmations

Word processing software: Compatibility with Windows XP


Usually 25100 features is enough recommended to keep the number below 50 if there seems to be more, describe features on a higher level of

abstraction Relatively small and limited number of features is a sufficient

basis for product description communication with stakeholders scope management project management


Features are described with attributes helps to track, identify, prioritise and classify features

Recommended attributes: status

for tracking and monitoring progress during development; e.g. proposed / approved / finished

priority/benefit for scope management; e.g. critical / important / useful

effort for budget and schedule estimations, e.g. number of person months, or

low / medium / high


risk probability of feature's undesirable effects; e.g. low / medium / high

stability probability that the feature will change; e.g. low / medium / high

target release in which product version a feature will appear for the first time; e.g.

version 1.0 assigned to

who is responsible for feature's implementation cause

for tracking the source of a requirement; e.g. page and chapter number in product description, line number in customer interview transcript

requirements engineering - joensuucs.joensuu.fi/pages/tenhunen/reqeng/lnotes/re_1-4.pdf · 2010. 1....

Documents