What the user asked for How the analyst saw it

How the system was designed As the programmer wrote it

What the user really wanted How it actually works

Requirements Engineering &

Project Planning Dr.$Raimundas$Matulevičius$

$University$of$Tartu$

rma@ut.ee)

•  Easterbrook S., Requirements Engineering course, University of Toronto • Hughes B., Cotterell M., Software Project Management, Fifth Edition, McGraw-Hill Higher education, 2009

Definition of RE

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

identifying and communicating the purpose of a software-intensive

system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs

of users, customers, and other constituencies affected by a software

system, and the capabilities and opportunities afforded by software-

intensive technologies

Definition of RE

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

identifying and communicating the purpose of a software-intensive

system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs

of users, customers, and other constituencies affected by a software

system, and the capabilities and opportunities afforded by software-

intensive technologies

Not a phase or stage!

Communication is as important as the analysis

Quality means fitness-for-purpose. Cannot say anything about quality unless you understand the

purpose

Designers need to know how and where

the system will be used

Requirements are partly about what

is needed…

…and partly about what is possible

Need to identify all the stakeholders - not just the customer and user

Requirements$Lifecycle$

Specification

Agreement

Representation

complete

fair

vague

personal view

common view

informal semi-formal formal

Source: Adapted from Pohl, CAISE 1993

5

Application Domain Machine Domain

D - domain properties

R - requirements

C - computers

P - programs

What are requirements?

•  Domain Properties / Expectations: –  things in the application domain that are true whether or not we ever build the

proposed system •  Requirements:

–  things in the application domain that we wish to be made true by delivering the proposed system

•  Many of which will involve phenomena the machine has no access to •  Specification:

–  is a description of the behaviours that the program must have in order to meet the requirements

•  Can only be written in terms of shared phenomena!

Requirements Elicitation

7

Requirements Elicitation •  Starting point

–  Some notion that there is a �problem� that needs solving •  e.g. dissatisfaction with the current state of affairs •  e.g. a new business opportunity •  e.g. a potential saving of cost, time, resource usage, etc.

–  A requirements analyst is an agent of change

•  The requirements analyst must: –  identify the �problem�/�opportunity�

•  Which problem needs to be solved? (identify problem Boundaries) •  Where is the problem? (understand the Context/Problem Domain) •  Whose problem is it? (identify Stakeholders) •  Why does it need solving? (identify the stakeholders��Goals) •  How might a software system help? (collect some Scenarios) •  When does it need solving? (identify Development Constraints) •  What might prevent us solving it? (identify Feasibility and Risk)

–  and become an expert in the problem domain •  although ignorance is important too -- �the intelligent ignoramus� 8

Example$•  Loan approval department in a large bank

–  The analyst is trying to elicit the rules and procedures for approving a loan

•  Why this might be difficult: –  Implicit knowledge:

•  There is no document in which the rules for approving loans are written down –  Conflicting information:

•  Different bank staff have different ideas about what the rules are –  Say-do problem:

•  The loan approval process described to you by the loan approval officers is quite different from your observations of what they actually do

–  Probe effect: •  The loan approval process used by the officers while you are observing is

different from the one they normally use –  Bias:

•  The loan approval officers fear that your job is to computerize their jobs out of existence, so they are deliberately emphasizing the need for case-by-case discretion (to convince you it has to be done by a human!)

9

Elicitation Techniques •  Traditional techniques

–  Reading existing documents –  Analyzing hard data –  Interviews

• Open-ended • Structured

–  Surveys / Questionnaires –  Meetings

•  Collaborative techniques –  Focus Groups

• Brainstorming • JAD/RAD workshops

–  Prototyping –  Participatory Design

•  Contextual (social) approaches –  Ethnographic techniques

• Participant Observation • Enthnomethodology

–  Discourse Analysis • Conversation Analysis • Speech Act Analysis

–  Sociotechnical Methods • Soft Systems Analysis

•  Cognitive techniques –  Task analysis –  Protocol analysis –  Knowledge Acquisition Techniques

• Card Sorting • Laddering • Repertory Grids • Proximity Scaling Techniques

10

Background Reading •  Sources of information:

–  company reports, organization charts, policy manuals, job descriptions, reports, documentation of existing systems, etc.

•  Advantages: –  Helps the analyst to get an understanding of the organization before

meeting the people who work there –  Helps to prepare for other types of fact finding

•  e.g. by being aware of the business objectives of the organization. –  may provide detailed requirements for the current system

•  Disadvantages: –  written documents often do not match up to reality –  Can be long-winded with much irrelevant detail

•  Appropriate for –  Whenever you not familiar with the organization being investigated

11

�Hard Data� and Sampling •  Hard data includes facts and figures…

–  Forms, Invoices, financial information,… –  Reports used for decision making,… –  Survey results, marketing data,…

•  Sampling –  Sampling used to select representative set from a population

•  Purposive Sampling - choose the parts you think are relevant without worrying about statistical issues

•  Simple Random Sampling - choose every kth element •  Stratified Random Sampling - identify strata and sample each •  Clustered Random Sampling - choose a representative subpopulation and sample it

–  Sample Size is important •  balance between cost of data collection/analysis and required significance

•  Process: –  Decide what data should be collected - e.g. banking transactions –  Determine the population - e.g. all transactions at 5 branches over one week –  Choose type of sample - e.g. simple random sampling –  Choose sample size - e.g. every 20th transaction 12

Example of hard data

•  Questions: – What does this data

tell you? – What would you do

with this data?

13

Interviews •  Types:

–  Structured - agenda of fairly open questions –  Open-ended - no pre-set agenda

•  Advantages –  Rich collection of information –  Good for uncovering opinions, feelings, goals, as well as hard facts –  Can probe in depth, & adapt follow-up questions to what the person

tells you

•  Disadvantages –  Large amount of qualitative data can be hard to analyze –  Hard to compare different respondents –  Interviewing is a difficult skill to master

Source: Adapted from Goguen and Linde, 1993, p154. 14

Interviewing Tips •  Starting off…

–  Begin the interview with an innocuous topic to set people at ease •  e.g. the weather, the score in last night�s hockey game •  e.g. comment on an object on the person�s desk: �My,… what a beautiful photograph! Did

you take that?�

•  Ask if you can record the interview –  Make sure the tape recorder is visible –  Say that they can turn it off at any time.

•  Ask easy questions first –  perhaps personal information

•  e.g. �How long have you worked in your present position?�

•  Follow up interesting leads –  e.g. if you hear something that indicates your plan of action may be wrong,

•  e.g.,�Could we pursue what you just said a little further?�

•  Ask open-ended questions towards the end •  e.g. �Is there anything else you would like to add?�

15

Questionnaires •  Advantages

–  Can quickly collect info from large numbers of people –  Can be administered remotely –  Can collect attitudes, beliefs, characteristics

•  Disadvantages –  Simplistic (presupposed) categories provide very little context

•  No room for users to convey their real needs •  Watch for:

–  Bias in sample selection –  Bias in self-selecting respondents –  Small sample size (lack of statistical significance) –  Open ended questions (very hard to analyze!) –  Leading questions (�have you stopped beating your wife?�) –  Appropriation (�What is this a picture of?�) –  Ambiguous questions (I.e. not everyone is answering the same question)

Source: Adapted from Goguen and Linde, 1993, p154.

Note: Q

uestionnaires MUST be

prototyped and tested!

16

Meetings •  Used for summarization and feedback

–  E.g. meet with stakeholders towards the end of each stage: •  to discuss the results of the information gathering stage •  to conclude on a set of requirements •  to agree on a design etc.

–  Use the meeting to confirm what has been learned, talk about findings •  Meetings are an important managerial tool

–  Used to move a project forward. –  Every meeting should have a clear objective:

•  E.g. presentation, problem solving, conflict resolution, progress analysis, gathering and merging of facts, training, planning,...

–  Plan the meeting carefully: •  Schedule the meeting and arrange for facilities •  Prepare an agenda and distribute it well in advance •  Keep track of time and agenda during the meeting •  Follow up with a written summary to be distributed to meeting participants •  Special rules apply for formal presentations, walkthroughs, brainstorming, etc.

Group Elicitation Techniques •  Types:

–  Focus Groups –  Brainstorming

•  Advantages –  More natural interaction between people than formal interview –  Can gauge reaction to stimulus materials (e.g. mock-ups, storyboards,

etc) •  Disadvantages

–  May create unnatural groups (uncomfortable for participants) –  Danger of Groupthink –  May only provide superficial responses to technical questions –  Requires a highly trained facilitator

•  Watch for –  sample bias –  dominance and submission 18

Joint/Rapid Application Development

•  JAD & RAD Principles: –  Group Dynamics - use workshops instead of interviews –  Visual Aids

•  Lots of visualization media, e.g. wall charts, large monitors, graphical interfaces –  Organized, Rational Process

•  Techniques such as brainstorming and top-down analysis –  WYSIWYG Documentation Approach

•  each JAD session results in a document which is easy to understand and is created and agreed upon during the session

•  Notes: –  Choose workshop participants carefully

•  they should be the best people possible representing various stakeholder groups

–  Workshop should last 3-5 days. •  Must turn a group of participants into a team - this takes 1-2 days. •  Session leader makes sure each step has been completed thoroughly. •  Session leader steps in when there are differences of opinion - �open issues�. •  Meeting room should be well-equipped for presentations, recording etc. 19

Participant Observation •  Approach

–  Observer spends time with the subjects •  Joining in long enough to become a member of the group •  Hence appropriate for longitudinal studies

•  Advantages –  Contextualized; –  Reveals details that other methods cannot

•  Disadvantages –  Extremely time consuming! –  Resulting �rich picture� is hard to analyze –  Cannot say much about the results of proposed changes

•  Watch for –  going native!

20

Combine Different Techniques Background reading (e.g., Internet?)

(Initial) Meeting

Hard Data analysis

Brainstorming

Interviews

Meeting

Joint/Rapid Development

Meeting

… 21

Combine Different Techniques

Hickey$A.$M.,$Davis$A.$M.:$ElicitaCon$Technique$SelecCon:$How$Do$Experts$Do$It.$Proceedings$of$the$11th$InternaConal$Requirement$Engineering$Conference$2003.$

22

•  You have understood – Why the system will be built, and

–  For whom it is useful. You have explained this in the Wiki.

– what is going to be built and have broken the functionality down into functional requirements

After reading the requirements,

I understand who will be the users of the application and what will the system do

for these users.

Functional requirements

23

Problem, Scope, Solution •  Identify the problem

–  what is the objective of the project? –  the �vision� of those who are pushing for it?

•  e.g., �Meeting scheduling is too costly right now�

•  Scope the problem –  given the vision, how much do we tackle?

•  e.g. �Build a system that schedules meetings�, …or… •  e.g. �Build a system that maintains people�s calendars� …or…

•  Identify solution scenarios –  given the problem, what is the appropriate business process for solving it?

•  e.g. �Anyone who wants to schedule a meeting goes to the secretary, gives details and the secretary handles the rest�, …or…

•  Scope the solution –  Given a business process, what parts should be automated, and how?

•  e.g. �Computer takes in scheduling request details, outputs a solution� …or… •  e.g. �Solution arrived at interactively by secretary and computer� …or… 24

Identifying the Problem •  Vague problem stated by the customer:

–  E.g. university textbook store: •  Manager wants to computerize the book order forms filled out by instructors;

–  E.g. A large insurance company: •  Claims manager wants to cut down the average time it takes to process an

insurance claim from 2 months to 2 weeks –  E.g. A telecommunications company:

•  CIO wants to integrate the billing system with customer record systems of several affiliates, so there is only one billing system...

•  Often you only see symptoms rather than causes: –  E.g. �Ontario patients needing X-ray scans have to wait for months� –  The long wait is the symptom, not the problem. The problem may be:

•  Shortage of X-ray machines; •  Shortage of trained staff; •  Shortage of doctors to process the data •  Inefficient scheduling procedures 25

•  Stakeholder analysis: –  Identify all the people who must be consulted during information

acquisition

•  Example stakeholders –  Users

•  concerned with the features and functionality of the new system –  Designers

•  want to build a perfect system, or reuse existing code –  Systems analysts

•  want to �get the requirements right� –  Business analysts

•  want to make sure �we are doing better than the competition� –  Technical authors

•  will prepare user manuals and other documentation for the new system –  The project manager

•  wants to complete the project on time, within budget, with all objectives met. –  �The customer�

•  Wants to get best value for money invested!

Stakeholders

26

Identifying Stakeholders� Goals

•  Approach –  Focus on why a system is required

•  Advantages –  Reasonably intuitive –  Explicit declaration of goals provides sound basis for conflict

resolution •  Disadvantages

–  Captures a static picture - what if goals change over time? –  Can regress forever up (or down) the goal hierarchy

Source: Adapted from Anton, 1996.

27

Example Goal Elaboration

MeeCng$be$scheduled$

Changes$$be$handled$

Date$and$locaCon$set$

APendees$know$details$

MeeCng$be$requested$

MeeCng$announced$$$APendee$

list$obtained$

room$availability$determined$

faciliCes$$booked$

$

aPendees�$preferences$

known$

AV$&$other$needs$defined$

APendance$confirmed$$

change$requests$accepted$

ParCcipants$noCfied$

Crucial$planning$decision$be$made$

Decision$be$made$faceTtoTface$

Agenda$be$defined$$

MeeCng$be$held$

Minutes$be$circulated$

Decision$be$made$by$email$discussion$

Or-decomposition

28

Goal Analysis •  Goal Elaboration:

–  �Why� questions explore higher goals (context)

–  �How� questions explore lower goals (operations)

–  �How else� questions explore alternatives

•  Relationships between goals: –  One goal helps achieve another (+) –  One goal hurts achievement of another (-) –  One goal makes another (++)

•  Achievement of goal A guarantees achievement of goal B

–  One goal breaks another (--) •  Achievement of goal A prevents achievement of

goal B

get$good$grade$

study$hard$

+$

earn$an$income$

get$full$Cme$job$

T$

++$

aPend$lectures$

TT$

+$

29

Source: Adapted from Dardenne, 1993.

Scenarios •  Scenarios

–  Specific sequence of interaction between actor and system –  Tend to be short (e.g between 3 and 7 steps) –  May be:

•  positive (i.e. required behavior) •  negative (i.e an undesirable interaction)

–  May be indicative (describe current system) or optative (how it should be) •  Advantages

–  Very natural: stakeholders tend to use them spontaneously •  e.g �suppose I�m admitted to hospital - what happens during my admission?� •  Typical answer: �You, or the person accompanying you would talk to the

person at the admissions desk. You have to show your ID card and explain who referred you to the hospital. Then you…� [and so on]

–  Short scenarios very good for quickly illustrating specific interactions •  Disadvantages

–  Lack of structure –  Hard to check for completeness 30

Example Scenario Title: Successful meeting scheduled using messaging option

Participants: Alice (initiator, not attending); Bob, Carlo, Daphne (attendees)

Action Goals satisfied Obstacles / Problems

Alice requests meeting, specifying participants, timeframe

Meeting requested;Attendee list obtained

What if selected timeframe is infeasible?

AS sends participant requests to Bob, Carlo and Daphne ? Did we miss a goal?

Bob reads message

Participants informed

Can�t detect when messages are read; what happens if Bob reads the message but doesn�t reply?Carlo reads message

Daphne reads message

Bob replies with preferences

Attendees preferences known

What if the preferences are mutually exclusive?Should we allow some to be higher priority?

Carlo replies with preferences

Daphne replies with preferences

AS schedules meeting Room availability determined; room booked

AS notifies Alice, Bob, Carlo, Daphne of time and location

Meeting announced;!Attendance Confirmed (?)

How do we know if they�ve all read the announcement? What if the schedule is no longer convenient for one of them?

•  You have listed the most important non-functional requirements. •  There is at least seven measurable non-functional requirements

present. You have noted the requirements down in the Wiki.

Reading the requirements, I understand

how you are going to measure whether the system satisfies a given requirement.

•  Non-functional requirement include the initial architectural choices listing what technologies you are going to use in order to complete the project.

Non-functional requirements

32

What are Non-functional Requirements? •  Functional vs. Non-Functional

–  Functional requirements describe what the system should do •  things that can be captured in use cases •  things that can be analyzed by drawing sequence diagrams, statecharts, etc. •  Functional requirements will probably trace to individual chunks of a program

–  Non-functional requirements are global constraints on a software system

•  e.g. development costs, operational costs, performance, reliability, maintainability, portability, robustness etc.

•  Often known as the �ilities� •  Usually cannot be implemented in a single module of a program

•  The challenge of NFRs –  Hard to model –  Usually stated informally, and so are:

•  often contradictory, •  difficult to enforce during development •  difficult to evaluate for the customer prior to delivery

–  Hard to make them measurable requirements •  We�d like to state them in a way that we can measure how well they�ve been met 33

Example NFRs •  Interface requirements

–  how will the new system interface with its environment?

• User interfaces and �user-friendliness� • Interfaces with other systems

•  Performance requirements –  time/space bounds

•  workloads, response time, throughput and available storage space •  e.g. �the system must handle 1,000 transactions per second"

–  reliability •  the availability of components •  integrity of information maintained and supplied to the system •  e.g. "system must have less than 1hr downtime per three months”

–  security • e.g. permissible information flows, or who can do what

•  Operating requirements –  physical constraints (size, weight), –  personnel availability & skill level –  accessibility for maintenance –  environmental conditions –  etc

•  Lifecycle requirements –  �Future-proofing�

•  Maintainability, Enhanceability, Portability •  expected market or product lifespan

–  limits on development •  e.g development time limitations, •  resource availability •  methodological standards

•  Economic requirements –  e.g. restrictions on immediate and/or long-

term costs.

Quantitative vs. Qualitative •  Quantitative Approaches

–  Find measurable scales for the quality attributes –  Calculate degree to which a design meets the quality

targets

•  Qualitative Approaches –  Study various relationships between quality goals –  Reason about trade-offs etc.

35

Goals as selection criteria minimize costs

serve more passengers

improve safety

maintain safe distance

reduce staffing

minimize operation costs

minimize development costs clearer

signalling

automate collision avoidance

automate braking

increase train speed

more frequent trains

add new tracks

maintain passenger comfort

buy new rolling stock hire more

operators

T$

T$ ++$ ++$

++$

T$

T$

T$

+$

T$T$

36

Fitness •  Software quality is all about fitness to purpose

•  Quality is not a measure of software in isolation

–  it measures the relationship between software and its application domain

•  cannot measure this until you place the software into its environment… •  …and the quality will be different in different environments!

–  during design, we need to predict how well the software will fit its purpose

•  we need good quality predictors (design analysis) –  during requirements analysis, we need to understand how fitness-for-

purpose will be measured •  What is the intended purpose? •  What quality factors will matter to the stakeholders? •  How should those factors be operationalized?

Source: Budgen, 1994, pp58-9

37

Making Requirements Measurable •  We have to turn our vague ideas about quality into measurables

The$Quality$Concepts$(abstract$noCons$of$quality$properCes)$

Measurable$Quan55es$(define$some$metrics)$

Counts$taken$from$Design$Representa5ons$(realizaCon$of$the$metrics)$

usability

minutes taken for some user task???

time taken to learn how to use?

complexity

count procedure calls???

information flow between modules?

reliability

run it and count crashes per hour???

mean time to failure?

examples...$

Source: Budgen, 1994, pp60-1

38

Example Metrics Quality Metric

Speed transactions/sec response time screen refresh time

Size Kbytes number of RAM chips

Ease of Use training time number of help frames

Reliability mean-time-to-failure, probability of unavailability rate of failure, availability

Robustness time to restart after failure percentage of events causing failure

Portability percentage of target-dependent statements number of target systems

39

Usability requirements

•  Ease of learning –  How easy is the system to learn for various groups of users?

•  Task efficiency –  How efficient is it for the

frequent user?

•  Ease of remembering –  How easy is to remember

for the occasional user? •  Subjective satisfaction

–  How satisfied is the user with the system?

•  Understandability –  How easy is it to understand what the system does?

Usability = Fit for use + Ease of use

Sa5sfac5on$

Response$5me$(sec)$

Ra5ng$ Quality$score$

<$2$ Exceeds$expectaCon$ 3$

2T5$ Within$the$target$range$ 2$

6T10$ Minimally$acceptable$ 1$

>10$ Unacceptable$ 0$

40

Usability requirements

•  Q1: It should be easy for novice users to do tasks Q and R.

•  Q2: Novice users should perform tasks Q and R in a short time.

•  Q3: Experienced users complete tasks Q, R, and S quicker than novice users

•  Q4: Recording breakfast shall be easy using keyboard

•  Problem counts –  Q1:

•  Task time –  Q2:

–  Q3:

•  Keystroke counts –  Q4:

41

Usability requirements

•  Q1: It should be easy for novice users to do tasks Q and R.

•  Q2: Novice users should perform tasks Q and R in a short time.

•  Q3: Experienced users complete tasks Q, R, and S quicker than novice users

•  Q4: Recording breakfast shall be easy using keyboard

•  Problem counts –  Q1: At most 1 of 20 novices shall

encounter critical problems during tasks Q and R.

•  Task time –  Q2: Novice users shall perform

tasks Q and R in 15 minutes. –  Q3: Experienced users complete

tasks Q, R and S in 2 minutes •  Keystroke counts

–  Q4: Recording breakfast shall be possible within 5 keystrokes per guest

42

Efficiency •  Efficiency - the capability of the software to provide the required performance

relative to the amount of resources used, under stated conditions

43

Efficiency

1: Product shall be able to process a lot of payment transactions in a short time even during peak load

2: Product shall be able to process 100 payment transactions per second in peak load.

•  Efficiency - the capability of the software to provide the required performance relative to the amount of resources used, under stated conditions

Which statement is objectively defined?

44

Efficiency

2: Scrolling one page up or down in a large document shall take an efficient time. Searching for a specific keyword shall a reasonable time

1: Scrolling one page up or down in a 200 page document shall take at most 1s. Searching for a specific keyword shall take at most 5s.

•  Efficiency - the capability of the software to provide the required performance relative to the amount of resources used, under stated conditions

Which statement is objectively defined?

45

Efficiency

1: A simple report shall take less a short time. None shall take the long waiting time

2: None shall take longer than the simple report preparation in the majority of the cases.

•  Efficiency - the capability of the software to provide the required performance relative to the amount of resources used, under stated conditions

Which statement is objectively defined?

46

Maintainability •  Maintenance performance

–  Q1: Supplier’s hotline shall analyse almost all reports in a short period –  Q2: When repairing a defect, a number of related non-repaired defects

should be very low •  Development process

–  Q3: Every program module must be assessed for maintainability according to orgnisation’s standards OST-1.12.x. Majority of the modules have to be “High maintainable” (as defined in the standard) and none “poor” (as defined in the standard)

–  Q4: Development must use regression test allowing full re-testing in a short period

•  Program complexity –  Q5: No method in any object may contain a lot of code lines

47

Maintainability •  Maintenance performance

–  Q1: Supplier’s hotline shall analyse 95% of reports within 2 work hours. –  Q2: When repairing a defect, related non-repaired defects shall be less than

0.5 coverage •  Development process

–  Q3: Every program module must be assessed for maintainability according to orgnisation’s standards OST-1.12.x. 70% of modules must obtain “High maintainable” (as defined in the standard) and none “poor” (as defined in the standard).

–  Q4: Development must use regression test allowing full re-testing in 12 hours.

•  Program complexity –  Q5: No method in any object may exceed 200 lines of code

Making Requirements Measurable •  Define �fit criteria� for each requirement

–  Give the �fit criteria� alongside the requirement –  e.g. for new ATM software

•  Requirement: �The software shall be intuitive and self-explanatory� •  Fit Criteria: �95% of existing bank customers shall be able to withdraw money and

deposit cheques within two minutes of encountering the product for the first time�

•  Choosing good fit criteria –  Stakeholders are rarely this specific –  The right criteria might not be obvious:

•  Things that are easy to measure aren�t necessarily what the stakeholders want •  Standard metrics aren�t necessary what stakeholders want

–  Stakeholders need to construct their own mappings from requirements to fit criteria

49

First version of the project plan is present in the Wiki/Issue tracker. It contains at minimum:

•  Roles in project. You have understood each team member roles and assigned responsibilities.

Project Plan

50

Team$Development$•  Team development

–  Forming •  get known and set up

rules about behaviour –  Storming:

•  establish leadership and operations

–  Norming •  feeling of group identity

–  Performing •  tasks at hand

–  Adjourning •  disband

•  Chair –  Must be good at running meetings, being calm,

strong but tolerant •  Plant

–  Good in generating ideas and potential solutions •  Monitor-evaluator

–  Good at evaluating ideas and potential solutions •  Shaper

–  A worrier that helps to direct the teams attention to the important issues

•  Team worker –  Skilled at creating a good working environment

•  Resource investigator –  Adept in finding resources

•  Completer-finisher –  Concerned with completing tasks

•  Company worker –  Team player, willing to undertake less attractive tasks

51

•  Team development –  Forming

•  get known and set up rules about behaviour

–  Storming: •  establish leadership and

operations –  Norming

•  feeling of group identity –  Performing

•  tasks at hand –  Adjourning

•  disband

•  Chair –  Must be good at running meetings, being calm,

strong but tolerant •  Plant

–  Good in generating ideas and potential solutions •  Monitor-evaluator

–  Good at evaluating ideas and potential solutions •  Shaper

–  A worrier that helps to direct the teams attention to the important issues

•  Team worker –  Skilled at creating a good working environment

•  Resource investigator –  Adept in finding resources

•  Completer-finisher –  Concerned with completing tasks

•  Company worker –  Team player, willing to undertake less attractive tasks

Team$Development$All for one and one for all !!!

52

First version of the project plan is present in the Wiki/Issue tracker. It contains at minimum:

•  Communication means. You have agreed both among yourselves and with the customer how and when and via which channels you are going to communicate.

Project Plan

53

CommunicaCon$Genres$

•  The$nature$of$the$informa5on$to$be$conveyed:$–  What$is$the$extent$and$complexity$of$the$informaCon$to$be$conveyed?$

•  A$phone$conversaCon$if$message$is$simple$–  Is$it$easy$to$understand?$Is$the$context$well$known$to$both$the$sender$and$

the$recipient?$•  Two$way$communicaCon$

–  Where$the$communicaCon$is$personally$sensiCve$•  FaceTtoTface$contacts$

•  At$different$stages$of$a$project$–$different$communica5on$genres$will$be$preferred$$

Same$place$ Different$places$

Same$5me$ MeeCngs,$Interviews$ Telephone,$instant$messaging$

Different$5mes$ NoCceboards,$pigeonTboards$ ETmail,$voicemail,$documents$

54

Situa5on$1$•  A developer can only complete her software component if another

developer finishes his component first, but he has not. The first developer is under a lot of pressure from the client to complete the work.

What would be the best mode of communication? 1.  Face to face meeting 2.  Meeting 3.  Telephone 4.  Call to a help desk

55

Situa5on$2$•  A developer needs clarification of what is meant by a particular

term used in a specification

What would be the best mode of communication? 1.  Face to face meeting 2.  Meeting 3.  Telephone 4.  Call to a help desk

56

Situa5on$3$•  The user of a system have found what appears to be a fault in a

software application that they use

What would be the best mode of communication? 1.  Face to face meeting 2.  Meeting 3.  Telephone 4.  Call to a help desk

57

CommunicaCon$Genres$

•  Early$stages$–$mee5ng(s)$–  Team$members$need$to$build$up$their$trust$and$confidence$in$their$coTworkers$

–  Decision$making$•  Intermediate$stages$(design)$–$teleconferencing$

–  AcCviCes$executed$in$parallel$–  Some$points$needs$to$be$clarified$$

•  Implementa5on$stages$N$emails$–  Everyone$knows$his$role,$work$can$progress$–  Face$to$face$meeCngs$–$helps$coordinaCon$and$maintain$moCvaCon$

58

CommunicaCon$plan$

•  What$–  Name$of$a$parCcular$

communicaCon$event$

•  Who/target$–  The$target$audience$

•  Purpose$–  What$the$communicaCon$is$

to$achieve$$

•  When/frequency$–  A$specific$date$–  A$frequency$

•  Type/method$–  Nature$of$communicaCon$

•  Responsibility$–  The$person$who$iniCates$the$

communicaCon$$

59

•  You have understood how you are going to work together and have explained this to me. I understand at minimum: –  How and using what materials the customer is going to

understand what you are going to build –  How do you determine that the customer is accepting your

solution proposal –  How you are internally going to build the accepted solution (who

assigns the tasks, who is going to implement it, will the tests be written, will code be reviewed, who is going to verify, who is doing the validation, etc)

–  When do you consider something ready to be published to the customer for review

–  How do you gather feedback from the customer and/or end users.

–  What is the definition of DONE on a task

Work Progress

60

Activity Planning

•  Schedule when to start and finish each activity –  Ensure that the appropriate resources will be available

precisely when required –  Avoid different activities competing for the same resources at

the same time –  Produce a detailed schedule showing which staff carry out

each activity –  Produce a detailed plan against which actual achievement

may be measured –  Produce a timed cash flow forecast –  Replan the project during its life to correct drift from the

target •  Each activity produces a deliverable

61

Objectives of activity planning •  Feasibility assessment

–  Is the project possible within required timescale and resource constraints?

•  Resource allocation –  What are the most effective ways to allocate resources to the project?

•  Detailed costing –  How much will the project cost and when is that expenditure likely to take

place?

•  Motivation –  Providing targets and being able to see achievements – perfect motivation

plan

•  Coordination –  When do the staff in different departments need to be available to work on a

particular task and when it could be transferred to other projects?

62

Project schedules •  What activities need to be carried out and in what order

they are to be done? •  Resource allocation •  Schedule production

–  Indicates planned start and finish dates –  Resource requirements for each activity

63

Defining activities •  Activity definition should meet these criteria

–  A project is composed of a number of interrelated activities –  A project may start when at least one of its activities is ready to

start –  A project will be completed when all activities have been

completed –  An activity must have a clearly defined start and a clearly defined

end-point producing a tangible deliverable –  If an activity requires a resource than this resource requirements

must be forecastable –  The duration of the activity should be forecastable – assuming

the normal circumstances –  Some activities might require that others are completed before

they can begin

64

Planning activities

Activity Duration (days) Precedents

A: Hardware selection 6

B: Software configuration 4

C: Install hardware 3 A

D: Data migration 4 B

E: Draft office procedures 3 B

F: Recruit staff 10

G: User training 3 E, F

H: Install and test 2 C, D

65

Activity Reporting template Activity ID Activity name Activities which need to be finished before this activity Resources needed to execute activity Activity start time Activity finish time Activity duration Activity description Assigned roles Activities that start after this activity is finished Deliverable /product produced Criteria which indicates that activity is finished // Criteria that defined the quality requirement of the deliverable or product produced Risk that could delay / cancel activity execution 66

Nature of Resources

•  Labour –  Members of the project

team

•  Equipment –  Workstations and other

communicating and office equipments

•  Material –  Items that are consumed

•  Space –  Office space

•  Services –  Some specialist services

•  telecommunicating

•  Time –  Offset against the other

primary resources

Resource – any item or person required for the execution of the project

•  You have created –  The list of all tasks you currently foresee need to be delivered in order to

complete the project. –  Tasks are planned into iterations or given priorities, assigned to person

responsible and contain initial estimation about the amount of work involved.

–  The descriptions of the tasks in the project plan is understandable.

•  At least tasks deliverable during the second iterations must be detailed in project plan. Further iterations might not be clear enough to break them down to tasks according to your current knowledge about requirements.

–  The tasks in the second iteration are defined at the proper level of granularity (90% of tasks take less than 16 hours, no task is larger than 40 hours).

(Project) Scope

68