Management of Projects

Transcription

1 of Projects Giuseppe Lami Page 1

2 Course Outline! Part 1: The Project (PM) Framework! Part 2: The PM as a Process! Part 3: Techniques, Methods and Tools Supporting the PM! Part 4: Requirements Engineering vs. Project Page 2

3 Part 1: The Project Framework Page 3

4 The Project Framework What is a project?! a project is a temporary endeavor undertaken to create a unique product or service. A project has the characteristic to be a progressive elaboration [IEEE ] Every project has a definite beginning and a definite end A project shall: -proceed in steps; continuing steadily by increments -Worked out with care and detail; developed thoroughly Projects involve doing something that has not been done before. A product can be unique even if the category to which it belongs is large Page 4

5 The Project Framework What is Project?! PM is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements.! The PM is accomplished through the use of activities as: initiating, planning, executing, controlling and closing! The PM involves managing the works of the project tasking into account: " Competing demands for: scope, time, cost, risk and quality " Stakeholders with differing needs and expactations " Identified requirements Page 5

6 The Project Framework Related Endeaviors! Programs: " A program is a group of projects managed in a coordinated way to obtain benefits not available from managing them individually.! Sub-projects: " Projects are frequently divide into more manageable components or sub-projects " Sub-project are often contracted to an external enterprise or functional unit. Page 6

7 The Project Framework Project Phases and the Project Life Cycle! Projects are unique undertakings and involve a degree of incertainty! Projects are usually divided into phases to improve management control and provide links to the ongoing operations of the performing organization. Each phase is marked by the completion of one or more deliverables.! A deliverable is a tangible, verifiable work product.! Collectively, the project phases are know as the project life cycle Page 7

8 The Project Framework Project Stakeholders! Project Manager: responsible for managing the project! Customer: who will use the project s product! Performing Organization: the enterprise whose employees are most directly involved in doing the work of the project! Project Team members: the group that is performing the work of the project! Sponsor: who (internally or externally respect the performing organization) provides the financial resources. Page 8

9 The Project Framework Organizational Influence! Projects are typically part of an organization larger than the project.! The key aspects that are likely to influence the project: " Organizational systems: project-based (i.e. whose operations consists primarly of projects) vs. non-project-based organizations! Project-based tend to have management systems in place to facilitate project management! Non-project-based often lack management systems designed to support project needs efficiently and effectively " Organizational cultures and styles (policies, procedures, shared beliefs,..) " Organizational structure Page 9

10 The Project Framework Organizational Influence (cont.d) The key aspects that are likely to influence the project: " Organizational structure Projected organization Matrix organization Functional organization Page 10

11 The Project Framework Key General Skills! Leading " Establish direction " Aligning people " Motivating and inspiring! Communicating " Written and oral, listening and speaking, internal and external, formal and informal, vertical and horizontal! Negotiating! Problem Solving " As a combination of problem definition and decisionmaking! Influencing the Organization Page 11

12 Part 2: The PM as a Process Page 12

13 The PM as a Process What is a process?! a set of activities, which transform inputs in outputs [ISO12207]! How to identify a Process " Purpose: the high-level measurable objectives of performing and the likely outcomes of effective implementation of the process " Outcomes: observable results of the successful implementation of the process " Input/Output work products: input/output artifacts associated with the execution of the process Page 13

14 The PM as a Process Process defintion: An example! Process Name: System Testing " Purpose: to ensure that the implementation of each system requirement is tested for compliance and that the system is ready for delivery " Outcomes: 1. A strategy is developed to test the system according to the priorities of and categorization the system requirements 2. A test specification for system test is developed that demonstrates compliance with the system requirements 3. The system is verified using the test cases 4. Results of system testing are recorded 5. Consistency and bilateral traceability are established between system req.s and test specification including test cases 6. A regression test strategy is developed " Input/Output work products:! Input: system requirements,! Output: system test cases, system test report, Page 14

15 The PM as a Process Process defintion: Project! Process Name: Project " Purpose: to identify, establish, plan, co-ordinate, and monitor the activities, tasks, and resources necessary for a project to produce a product and/or service, in the context of the project s requirements and constraints. " Outcomes: 1. The scope of the work for the project is defined 2. The feasibility of achieving the goals of the project with available resources and constraints is evaluated 3. The tasks and resources necessary to complete the work are sized and estimated 4. Interfaces between elements in the project are developed, and with other project organizational units, are identified and monitored 5. Plans for the execution of the project are developed, implemented and maintained 6. Progress of the project is monitored and reported 7. Actions to correct deviations from the plan and to prevent recurrence of problems identified in the project are taken when project goals are not achieved 8. At the closure of the project all the relevant information is reported and made available " WP input: estimations, performance records, quality records " WP output: Project Plan, Change requests Page 15

16 The PM as a Process PM Process main phases! From the previous Project definition the following main phases can be identified: " Initiation " Planning " Execution " Controlling " Closing a phase corresponds to a set of practices to be performed in order to achieve the process purposes Page 16

17 The PM as a Process Connections among PM process phases Initiating phase Planning phase Controlling phase Executing phase Closing phase Page 17

18 The PM as a Process PM Knowledge Areas: overview! Project can be considered composed of the following Knowledge Areas (KA) - Project Integration - Project Scope - Project Time - Project Cost - Project Quality - Project Human Res. Man. - Project Communications Man. - Project Risk - Project Procurement! a Knowledge Area describes the project management knowledge and practice in terms of their component activities. Page 18

19 The PM as a Process PM Process Areas: Project Integration Man.! This KA describes the activities required to ensure that various elements of the project are properly coordinated. It consists of the following practices: project plan development, project plan execution, and integrated change control Project Integrating Integration Phase - Project Plan Development - Project Plan Execution - Integrated Change Control Page 19

20 The PM as a Process PM Process Areas: Project Scope Man.! This KA describes the activities required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. It consists of the following practices: initiation, scope planning, scope definition, scope verification, and scope change control Project Scope Phase Scope - Initiation - Scope Planning - Scope Definition - Scope Verification - Scope Change Control Page 20

21 The PM as a Process PM Process Areas: Project Time Man.! This KA describes the activities required to ensure timely completion of the project. It consists of the following practices: activity definition, activity sequencing, activity duration estimating, schedule development, and schedule control Project Time - Activity Definiton - Activity Sequencing - Activity Duration Estim. - Schedule Development - Schedule Control Page 21

22 The PM as a Process PM Process Areas: Project Cost Man.! This KA describes the activities required to ensure that the project is completed within the approved budget. It consists of the following practices: resources planning, cost estimating, cost budgeting, and cost control Project Cost - Resource Planning - Cost estimating - Cost budgeting - Cost control Page 22

23 The PM as a Process PM Process Areas: Project Quality Man.! This KA describes the activities required to ensure that the project will satisfy the needs for which it was undertaken. It consists of the following practices: quality planning, quality assurance, and quality control Project Quality - Quality Planning - Quality Assurance - Quality control Page 23

24 The PM as a Process PM Process Areas: Project Human Resources! This KA describes the activities required to make the most effective use of the people involved with the project. It consists of the following practices: organizational planning, staff acquisition, and team development Project Human Resource - Organizational Planning - Staff Acquisition - Team Development Page 24

25 The PM as a Process PM Process Areas: Project Communications! This KA describes the activities required to ensure timely and appropriate generation, collection, dissemination, storage, and ultimate disposition of project information. It consists of the following practices: communications planning, information distribution, performance reporting, and administrative closure. Project Communications - Communications Planning - Information Distribution - Performance Reporting - Administrative Closure Page 25

26 The PM as a Process PM Process Areas: Project Risk! This KA describes the activities concerned with identifying, analyzing and responding to project risks. It consists of the following practices: risk management planning, risk identification, quantitative risk analysis, qualitative risk analysis, risk response planning and risk monitoring and control. Project Risk - Risk Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning - Risk Monitoring and Control Page 26

27 The PM as a Process PM Definition by KAs and Phases! In the following each PM Process Phase will be defined by the related KAs practices.! The relationship among the KAs practices will be indicated as well. Initiating phase Planning phase Controlling phase Executing phase Closing phase Page 27

28 The PM as a Process PM: Project Initiation Phase Initiating Phase SCOPE Initiation To the Planning Phase Page 28

29 The PM as a Process PM: Project Planning Phase -Core practices: have clear dependencies that require them to be performed in essentially the same order on most projects -Facilitating practicies: interactions with the other activities are more dependent on the nature of the project Planning Processes Scope Time Activity Scope planning definition Scope Scope definition Cost Resource planning Core practices Facilitating practices Quality Human Quality Resources planning Organizational planning Communication Risk Communications Risk planning identification Time Time Activity Schedule sequencing development Time Activity duration estimating Cost Integration Project plan Cost estimating development Risk Cost Cost budgeting Risk management planning Human Procurement Procurement Resources Procurement Solicitation Staff plannng plannng acquisition Risk Risk Risk Qualitative risk Quantitative Risk response analysis risk analysis planning Page 29

30 The PM as a Process PM: Project Executing Phase Integration Project plan execution Facilitating Processes From Planning Phase From Controlling Phase Procurement Solicitation Quality Quality Assurance Procurement Source selection Human Resources Team develop. Communications Information distribution To Controlling Phase Procurement Source selection Page 30

31 The PM as a Process PM: Project Controlling Phase Integration Integrated change control Communications Perfromance reporting Facilitating Processes To Planning Phase From Executing Phase Scope Scope verification Cost Cost Control Scope Scope change control Quality Quality control Time Schedule control Risk Risk monitoring and control To Executing Phase To Closing Phase Page 31

32 The PM as a Process PM: Project Closure Phase From Controlling Phase Procurement Contact closeout Communications Administrative closure Page 32

33 Part 3: Techniques and Tools Supporting PM Page 33

34 Techniques and Tools for PM! Project is a complex and varied process needing the support of (automatic) tools and specific techniques.! In the following the most popular and relevant tools and techniques for PM are described and cross mapped with the KPs and Phases.! Principal techniques for PM: " Project Planning Methodologies " Project management information systems " Work breakdown structure template " Configuration " Performance measurement " Work authorization system " Status review meeting " Precedence diagramming method " Check-lists Page 34

35 Techniques and Tools for PM: Project Planning Methodologies " structured approach used to guide the project team during development of the project plan. It may be as simple as standard forms and templates (whether paper or electronic, formal or informal) or as complex as a series of required simulations (e.g., Monte Carlo analysis of schedule risk). Most project planning methodologies make use of a combination of hard tools, such as project management software, and soft tools, such as facilitated startup meetings.! Popular commercial tools: MS Project (to define and maintain the scheduling of the project s activities and the people allocation) Page 35

36 Techniques and Tools for PM: Project Information Systems (PMIS) " A PMIS consists of the tools and techniques used to support all aspects of the project from initiating through closing, and can include both manual and automated systems. The key functions are:! gather, integrate, and disseminate the outputs of project management processes.! provide on-demand project s status reports;! Support the project schedule and control " Data (derived from different sources as: previous project, company-level measurement, ) are captured, stored and made available in several views by the PMIS. The point is to find a trade-off between the amount of data and the useful information (so much data, so little information) " Popular commercial tools: MS Sharepoint, PrimaVera ( Page 36

37 Techniques and Tools for PM: Work Breakdown Structure (WBS) Template (I/II) " A WBS is a deliverable-oriented grouping of project components that organizes and defines the total scope of the project. As with the scope statement, the WBS is often used to develop or confirm a common understanding of project scope. " Each descending level represents an increasingly detailed description of the project deliverables. " The WBS should not be confused with the method of presentation drawing an unstructured activity list in chart form does not make it a WBS. Each item in the WBS is generally assigned a unique identifier; these identifiers can provide a structure for a hierarchical summation of costs and resources. The items at the lowest level of the WBS may be referred to as work packages, especially in organizations that follow earned value management practices. These work packages may in turn be further decomposed in a subproject work breakdown structure. Work component descriptions are often collected in a WBS dictionary. A WBS dictionary will typically include work package descriptions, as well as other planning information such as schedule dates, cost budgets, and staff assignments. Page 37

38 Techniques and Tools for PM: Work Breakdown Structure (WBS) Template (II/II) " A WBS from a previous project can often be used as a template for a new project. Although each project is unique, WBSs can often be reused since most projects will resemble another project to some extent. For example, most projects within a given organization will have the same or similar project life cycles, and will thus have the same or similar deliverables required from each phase. Project Task 1 Task 2. Sub-task 1.1 Sub-task 1.2. Work Package Work Package Exemplar WBS Schema Page 38

39 Techniques and Tools for PM: Configuration! Configuration management (CM) is any documented procedure used to apply technical and administrative direction and surveillance to: " Identify and document the functional and physical characteristics of an item or system. " Control any changes to such characteristics. " Record and report the change and its implementation status. " Audit the items and system to verify conformance to requirements. In many application areas, CM is used to ensure that the description of the project s product is correct and complete.! The bigger and more complex the system being delivered then the greater the need to exercise such control.! Popular commercial tools: Clear Case (IBM/Rational), CM Synergy (Telelogic), Serena (Serena Software), Page 39

40 Techniques and Tools for PM: Performance Measurement! Performance measurement techniques help to assess the magnitude of any variations that do occur in a project. An important part of schedule control is to decide if the schedule variation requires corrective action.! For example, a major delay on a non-critical activity may have little effect on the overall project, while a much shorter delay on a critical or near-critical activity may require immediate action.! Performance can be made using (in conjunction) several techniques: " Performance reviews: are meetings held to assess project status and/or progress. Performance reviews are typically used in conjunction with one or more of the performance-reporting techniques described below. " Variance analysis: it involves comparing actual project results to planned or expected results. Cost and schedule variances are the most frequently analyzed, but variances from plan in the areas of scope, resource, quality, and risk are often of equal or greater importance. " Trend analysis: it involves examining project results over time to determine if performance is improving or deteriorating. " Earned value analysis: it is the most commonly used method of performance measurement. It integrates scope, cost (or resource), and schedule measures to help the project management team assess project performance. Page 40

41 Techniques and Tools for PM: Work Authorization System! A work authorization system is a formal procedure for sanctioning project work to ensure that work is done at the right time and in the proper sequence. The design of a work authorization system should balance the value of the control provided with the cost of that control. For example, on many smaller projects, verbal authorizations will be adequate.! The work authorization system will typically be in the form of a list of formally adopted and well-documented procedures. Work authorization procedures specifically detail who may authorize work to be completed and how those authorizations may be obtained. These procedures will include which documents must be completed prior to work being initialized, and whether there are any other prerequisites to work being performed at any particular level during the project.! The work authorization system is used by the project manager and his or her designees in order to approve all project work throughout the course of the current project management venture. Page 41

42 Techniques and Tools for PM: Status Review Meeting! Status review meetings are regularly scheduled meetings held to exchange information about the project. On most projects, status review meetings will be held at various frequencies and on different levels (e.g., the project management team may meet weekly by itself and monthly with the customer).! Meeting attendance is formally identified.! Meeting Agenda is defined and distributed to all affected parties! Meeting minutes, containing, at least, the open issues identified as well as the responsibility allocation to close them, are produced and made available to all affected parties. Page 42

43 Techniques and Tools for PM: Status Review Meeting! Status review meetings are regularly scheduled meetings held to exchange information about the project. On most projects, status review meetings will be held at various frequencies and on different levels (e.g., the project management team may meet weekly by itself and monthly with the customer).! Meeting attendance is formally identified.! Meeting Agenda is defined and distributed to all affected parties! Meeting minutes, containing, at least, the open issues identified as well as the responsibility allocation to close them, are produced and made available to all affected parties. Page 43

44 Techniques and Tools for PM: Preceence Diagramming Method! It is a method of constructing a project network diagram that uses boxes or rectangles (nodes) to represent the activities and connects them with arrows that show the dependencies. This technique is also called activity-on-node (AON) and is the method used by most project management software packages. It includes four types of dependencies or precedence relationships: " Finish-to-start: the initiation of the work of the successor depends upon the completion of the work of the predecessor. It is the most commonly used type of logical relationship " Finish-to-finish: the completion of the work of the successor depends upon the completion of the work of the predecessor. " Start-to-start: the initiation of the work of the successor depends upon the initiation of the work of the predecessor. " Start-to-finish: the completion of the successor is dependent upon the initiation of the predecessor. Page 44

45 Techniques and Tools for PM: Check List! Checklists are structured tools used to verify that a set of required steps has been performed. Checklists may be simple or complex. They are usually phrased as imperatives ( Do this! ) or interrogatories ( Have you done this? ). Many organizations have standardized checklists available to ensure consistency in frequently performed tasks. In some application areas, checklists are also available from professional associations or commercial service providers.! Checklists can be developed and used for risk identification, in this case they can be developed based on historical information and knowledge that has been accumulated from previous similar projects and from other sources of information. " One advantage of using a checklist is that risk identification is quick and simple. " One disadvantage is that it is impossible to build an exhaustive checklist of risks, and the user may be effectively limited to the categories in the list.! It is important to review the checklist as a formal step of every projectclosing procedure to improve the list of potential risks, to improve the description of risks. Page 45

46 Techniques vs. KPA Project Integration KPA " Project Planning Methodologies " Project management information systems " Work breakdown structure template " Configuration " Performance measurement " Work authorization system " Status review meeting " Precedence diagramming method " Check-lists Project Integrating Integration Phase - Project Plan Development - Project Plan Execution - Integrated Change Control Page 46

47 Techniques vs. KPA Project Scope KPA " Project Planning Methodologies " Project management information systems " Work breakdown structure template " Configuration " Performance measurement " Work authorization system " Status review meeting " Precedence diagramming method " Check-lists Scope Phase - Initiation - Scope Planning - Scope Definition - Scope Verification - Scope Change Control Page 47

48 Techniques vs. KPA Project Time KPA " Project Planning Methodologies " Project management information systems " Work breakdown structure template " Configuration " Performance measurement " Work authorization system " Status review meeting " Precedence diagramming method " Check-lists Project Time - Activity Definiton - Activity Sequencing - Activity Duration Estim. - Schedule Development - Schedule Control Page 48

49 Techniques vs. KPA Project Cost KPA " Project Planning Methodologies " Project management information systems " Work breakdown structure template " Configuration " Performance measurement " Work authorization system " Status review meeting " Precedence diagramming method " Check-lists Project Cost - Resource Planning - Cost estimating - Cost budgeting - Cost control Page 49

50 Techniques vs. KPA Project Communications KPA " Project Planning Methodologies " Project management information systems " Work breakdown structure template " Configuration " Performance measurement " Work authorization system " Status review meeting " Precedence diagramming method " Check-lists Project Communications - Communications Planning - Information Distribution - Performance Reporting - Administrative Closure Page 50

51 Techniques vs. KPA Project Risk KPA " Project Planning Methodologies " Project management information systems " Work breakdown structure template " Configuration " Performance measurement " Work authorization system " Status review meeting " Precedence diagramming method " Check-lists Project Risk - Risk Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning - Risk Monitoring and Control Page 51

52 Part 4: Requirements Engineering vs. Project The hardest single part of building a software system is deciding what to build. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later [Brooks 87] Page 52

53 Requirements Engineering! What is are Requirements: " descriptions of how the system should behave, or of a system property or attribute. " A feature that the system must have or a constraint it must satisfy to be accepted by the client [Bruegge, Dutoit] " 1) a condition or capability needed by a user to solve a problem or achieve an objective 2) 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 documents, A documented representation of a condition or capability as in 1) or2). [IEEE ]! Requirements Engineering (RE) is a process.! The RE process is a structured set of activities which are followed to derive, validate and maintain a system requirements document Page 53

54 Requirements Engineering (cont.)! RE activities: " Requirements Elicitation " Requirements Analysis and Negotiation " Specification " Quality analysis " Prioritization " Requirements Change Page 54

55 Requirements Elicitation! Definition: " the process of seeking, uncovering, acquiring, and elaborating requirements for computer based systems [Zowghi 2005] " Using systematic techniques to proactively identify and document customer and end-user needs [CMMI] " The process of discovering the requirements for a system by communication with customers, system users and other who have a stake in the system [Sommeriville 2000] Page 55

56 Requirements Elicitation (cont.)! The purpose of the Requirements elicitation process is to gather, process, and track evolving customer needs and requirements throughout the life of the product and/or service so as to establish a requirements baseline that serves as the basis for defining the needed work products.! As a result of successful implementation of this process: " continuing communication with the customer is established; " agreed customer requirements are defined and baselined; " a change mechanism is established to evaluate and incorporate changes to customer requirements into the baselined requirements based on changing customer needs; " a mechanism is established for continuous monitoring of customer needs; " a mechanism is established for ensuring that customers can easily determine the status and disposition of their requests; and " changes arising from changing technology and customer needs are identified, the associated risks assessed and their impact managed. Page 56

57 Requirements Elicitation Techniques! Interviews! Questionnaires! Introspection! Card sorting! Brainstorming! JAD (Joint Application Development)! Requirements workshop! Ethnography! Prototyping! Goal-based approaches! Scenarios/Use Case! Viewpoint Page 57

58 Requirements Elicitation vs. Project Project Human Resource - Organizational Planning - Staff Acquisition - Team Development Scope Phase - Initiation - Scope Planning - Scope Definition - Scope Verification - Scope Change Control Project Quality - Quality Planning - Quality Assurance - Quality control Project Risk - Risk Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning - Risk Monitoring and Control Project Time - Activity Definiton - Activity Sequencing - Activity Duration Estim. - Schedule Development - Schedule Control Requirements Elicitation Project Communications - Communications Planning - Information Distribution - Performance Reporting - Administrative Closure Project Cost - Resource Planning - Cost estimating - Cost budgeting - Cost control Project Integrating Integration Phase - Project Plan Development - Project Plan Execution - Integrated Change Control Page 58

59 Requirements Analysis and Negotiation! After an initial set of requirements has been gathered and organized, it should be analyzed for conflicts, overlaps, omissions and inconsistencies. " Analysis: the process of evaluating value/cost of different requirements, identifying dependencies between requirements, etc.! Then, system stakeholders negotiate to agree on a set of system requirements " Negotiation: the process of resolving conflicts between requirements, deciding which to accept, setting priorities Page 59

60 Requirements Analysis and Negotiation (cont.)! Analysis: " The analysis should aim at rating each alternative or requirements in terms of! Benefit! Penalty! Cost! Risk " The interaction between different requirements should be analysed (what impact on other parts of the system will be when a particular alternative is selected, ) " Check lists based on the experience make the analysis systematic " Analysis supports Negotation Page 60

61 Requirements Analysis and Negotiation (cont.)! Negotiation goals: " To make the conflicts explicit " To make explicit, for any conflict, the relevant alternatives, the argumentations, and the underlying rationales " To facilitate in that right decisions (i.e. decisions made rationally and based on the evaluation of alternatives) are made! Negotiation should be supported by negotiation meetings planned and involving all relevant stakeholders Page 61

62 Req.s Analysis and Negotiation vs. Project Project Human Resource - Organizational Planning - Staff Acquisition - Team Development Scope Phase - Initiation - Scope Planning - Scope Definition - Scope Verification - Scope Change Control Project Quality - Quality Planning - Quality Assurance - Quality control Project Risk - Risk Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning - Risk Monitoring and Control Req.s Analysis & Negotiation Project Integrating Integration Phase - Project Plan Development - Project Plan Execution - Integrated Change Control Project Time - Activity Definiton - Activity Sequencing - Activity Duration Estim. - Schedule Development - Schedule Control Project Communications - Communications Planning - Information Distribution - Performance Reporting - Administrative Closure Project Cost - Resource Planning - Cost estimating - Cost budgeting - Cost control Page 62

63 Requirement Specification! Requirements shall be documented in order to be used by the affected people. Many way to document requirements exist. The initial mean for specifying requirements is Natural Language (NL) even when formal methods are used.! The use of standard templates and simple language, supplementing NL with diagrams and other specialized notations (mathematical formulae, decision tables, design notations,..) improves the requirements specifications Page 63

64 Requirement Specification (cont.)! System modeling is a mean to adding detailed information to requirements.! Abstract models should represent the system s environment (other systems which are interfaced and business processes that may use the system) and a system architecture s model (decomposition of sub-systems, sub-systems communications) Page 64

65 Requirements Specification vs. Project Project Human Resource - Organizational Planning - Staff Acquisition - Team Development Scope Phase - Initiation - Scope Planning - Scope Definition - Scope Verification - Scope Change Control Project Quality - Quality Planning - Quality Assurance - Quality control Project Risk - Risk Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning - Risk Monitoring and Control Requirements Specification Project Integrating Integration Phase - Project Plan Development - Project Plan Execution - Integrated Change Control Project Time - Activity Definiton - Activity Sequencing - Activity Duration Estim. - Schedule Development - Schedule Control Project Communications - Communications Planning - Information Distribution - Performance Reporting - Administrative Closure Project Cost - Resource Planning - Cost estimating - Cost budgeting - Cost control Page 65

66 Requirements Quality Analysis! The quality requirements specification document shall be checked for omissions, conflicts and ambiguities.! Quality analysis Techniques " Manual (formal inspections) " Tool-based! The use of formal notations instead of NL to specify requirements makes quality analysis easier and more automatic! Requirements Quality characteristics " Correctness " Un-ambiguity " Completeness " Consistency " Importance " Stability " Verifiability " Modifiability " Traceability " Understandability " Feasibility " Detail level Page 66

67 Requirements Quality Analysis vs. Project Project Human Resource - Organizational Planning - Staff Acquisition - Team Development Scope Phase - Initiation - Scope Planning - Scope Definition - Scope Verification - Scope Change Control Project Quality - Quality Planning - Quality Assurance - Quality control Project Risk - Risk Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning - Risk Monitoring and Control Project Time - Activity Definiton - Activity Sequencing - Activity Duration Estim. - Schedule Development - Schedule Control Requirements Quality Analysis Project Communications - Communications Planning - Information Distribution - Performance Reporting - Administrative Closure Project Cost - Resource Planning - Cost estimating - Cost budgeting - Cost control Project Integrating Integration Phase - Project Plan Development - Project Plan Execution - Integrated Change Control Page 67

68 Requirements Prioritization! Prioritization aims at determining which candidate requirements should be included in a certain release.! The need to prioritize requirements is due to: " Customer (usually) ask too much " Balance time-to-market with amount of functionality " Project constraints! Prioritization criteria: " Importance for the customer (value) " Cost " Risk Page 68

69 Requirements Prioritization (cont.)! A technique for requirements prioritization is the Cost-Value Approach It can be used to evaluate return on investment " Assess each requirement s importance to the project as a whole " Assess the relative cost of each requirement " Compute the cost-value trade-off:! Other Requirements Prioritization techniques: " Quality Function Deployment (QFD) " Planning Game " Binary Search Tree " 100-point method Page 69

70 Requirements Prioritization vs. Project Project Human Resource - Organizational Planning - Staff Acquisition - Team Development Scope Phase - Initiation - Scope Planning - Scope Definition - Scope Verification - Scope Change Control Project Quality - Quality Planning - Quality Assurance - Quality control Project Risk - Risk Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning - Risk Monitoring and Control Project Time - Activity Definiton - Activity Sequencing - Activity Duration Estim. - Schedule Development - Schedule Control Requirements Prioritization Project Communications - Communications Planning - Information Distribution - Performance Reporting - Administrative Closure Project Cost - Resource Planning - Cost estimating - Cost budgeting - Cost control Project Integrating Integration Phase - Project Plan Development - Project Plan Execution - Integrated Change Control Page 70

71 Requirements Change! Due to the customer, or to errors, misunderstanding or technical constraints at design or development time, requirements may change several times in a project.! Change management implies having policies to manage the following: " Changes sources " Requirements documents " Relationships between requirements " Relationships between requirements documents and other project documents Page 71

72 Requirements Change (cont.)! Change sources: " change sources (e.g. the customer, developers, testers, ) shall be continuously monitored and a continuous communication channel shall be established and maintained! Requirements documents: " Requirements documents shall be maintained updated and their availability to the affected parties shall be assured! Relationship between different requirements " The relationships between requirements shall be established and maintained in order to establish the change impact and act to propagate changes. Traceability techniques and tools address such a point! Relationship between requirements and other project s document " The change impact shall be established also addressing other project s documents and the change shall be propagated to other documents if case Page 72

73 Req.s Change vs. Project Project Human Resource - Organizational Planning - Staff Acquisition - Team Development Scope Phase - Initiation - Scope Planning - Scope Definition - Scope Verification - Scope Change Control Project Quality - Quality Planning - Quality Assurance - Quality control Project Risk - Risk Planning - Risk Identification - Qualitative Risk Analysis - Quantitative Risk Analysis - Risk Response Planning - Risk Monitoring and Control Project Time - Activity Definiton - Activity Sequencing - Activity Duration Estim. - Schedule Development - Schedule Control Req.s Change Project Communications - Communications Planning - Information Distribution - Performance Reporting - Administrative Closure Project Cost - Resource Planning - Cost estimating - Cost budgeting - Cost control Project Integrating Integration Phase - Project Plan Development - Project Plan Execution - Integrated Change Control Page 73

74 RE for Critical Systems! Critical systems needs additional care in performing requirements engineering related activities. In the following a list of practices required in the case of critical systems in order to enhance the confidence in requirements: " Create safety requirements checklists " Involve external reviewers in requirements inspections " Identify and analyze hazards " Derive safety requirements from hazard analysis " Cross-check operational and functional requirements against safety requirements " Use formal specifications to specify the system " Collect incident experience and learn form it Page 74