Types of requirement

User requirements System requirements Domain requirements Functional requirements Non-functional requirements

Non-functional requirement types

Non-functional requir ements

Product requir ements

Or ganizational requir ements

External requirements

Ef ficiency requir ements

Reliability requir ements

Portability requirements

Interoperability requirements

Ethical requirements

Usability requirements

Delivery requirements

Implementation requir ements

Standards requirements

Legislative requirements

Performance requirements

Space requir ements

Privacy requirements

Safety requirements

Requirements measures

Requirements measures
Prope rty Speed Size Ease of use Reliability Measure Processed transactions/second User/Event response time Screen refresh t ime K Byt es Number of RAM chips Training t ime Number of help frames Mean time t o failure Probabilit y of unavailability Rate of failure occurrence Availabilit y Time to restart after failure Percent age of events causing failure Probabilit y of dat a corruption on failure Percent age of t arget dependent statements Number of t arget syst ems

Robustness Port abilit y

Relationship & Difference Between Requirement and Design

Requirements vs. Design

Requirements
Describe what will be delivered Primary goal of analysis: UNDERSTANDING

Design
Describe how it will be done Primary goal of design: OPTIMIZATION

There is more than one solution

Customer interested

There is only one (final) solution

Customer not interested (Most of the time) except for external

Requirements and design

In practice, inseparable requirements and design are

A system architecture may be designed to structure the requirements The system may inter-operate with other systems that generate design requirements The use of a specific design may be a domain requirement

Relationships between user needs, concerns and NFRs

Relationships between user needs, concerns and NFRs

Users need Function Performance Users concern 1. Ease of use 2. Unauthorised access 3. Likelihood of failure 1. Resource utilisation 2. Performance verification 3. Ease of interfacing 1. Ease of repair 2. Ease of change 3. Ease of transport ? 4. Ease of expanding or upgrading capacity or performance ? Non-functional requirement 1. Usability 2. Security 3. Reliability 1. Efficiency 2. Verifiability 3. Interoperability 1. Maintainability 2. Flexibility 3. Portability 4. Expandability

Change

How to write requirements:

Guidelines for writing requirements

Invent a standard format and use it for all requirements Use language in a consistent way. Use

shall for mandatory requirements, should for desirable requirements

Use text highlighting to identify key parts of the requirement

Problems with natural language

Problems with natural language

Lack of clarity
Precision is difficult without making the document difficult to read

Requirements confusion
Functional and non-functional requirements tend to be mixed-up

Requirements combination
Several different requirements may be expressed together

Alternatives to NL specification

Alternatives to NL specification
Notation Structured natural language Design description languages Graphical notations Mathematical specifications Description This approach depends on defining standard forms or templates to express the requirements specification. This approach uses a language like a programming language but with more abstract features to specify the requirements by defining an operational model of the system. A graphical language, supplemented by text annotations is used to define the functional requirements for the system. These are notations based on mathematical concepts such as finite-state machines or sets. These unambiguous specifications reduce the arguments between customer and contractor about system functionality.

What is Requirement Document

The requirements document

The requirements document is the official statement of what is required of the system developers Should include both a definition specification of requirements and a

It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

Users of a requirements document

System customers

Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements Use the requirements document to plan a bid for the system and to plan the system development process

Managers

System engineers

Use the requirements to understand what system is to be developed

System test engineers

Use the requirements to develop validation tests for the system

System maintenance engineers

Use the requirements to help understand the system and the relationships between its parts

Users of a requirement s document

Requirements document requirements

Requirements document requirements

Specify external system behaviour Specify implementation constraints Easy to change Serve as reference tool for maintenance Record forethought about the life cycle of the system i.e. predict changes Characterise responses to unexpected events

Software Requirements Specification (SRS)

What is an SRS? What is the purpose of an SRS?
Who reads the SRS? Who writes the SRS?

What information is put into an SRS?

What do you need to do for phase 1?

What is an SRS?
It is a document that you prepare:
after customer gives you their system specifications before you design the system

What is the purpose of an SRS?

The SRS precisely defines the software product that will be built. [readyset.tigris.org/nonav/templates/srs.html] The SRS is your response to the customers System Specification ... and tells a potential customer how you intend to solve their problem. [CSE442 project description] The [SRS] specifies the requirements and the methods to be used to ensure that each requirement has been met.

Purpose (continued)
1. 2. 3. 4. It provides feedback to the customer. It decomposes the problem into component parts. It serves as an input to the design specification. It serves as a product validation check.

Who reads the SRS?

The purpose of an SRS is to communicate with the customer:
The SRS must make clear to the customer whether you have understood their system specification correctly and completely. SRS is written in plain language (not a formal language).

Who reads (continued)

The purpose of an SRS is to communicate with the designers:
The SRS must be detailed enough that the designers can construct a design for the system from this document.

Who writes the SRS?

Developers
Architects Programmers

Technical writers Customer may be involved

Basis for User Manual

The SRS can serve as the basis for a User Manual for the software:
Use case descriptions in SRS describe required functionality of the system, from the perspective of a user. This can be extended to become a description of how to carry out these required tasks with the finished system.

IEEE Std 830-1998 Characteristics of a good SRS

1. 2. 3. 4. 5. Correct Unambiguous Complete Consistent Ranked for importance and/or stability 6. Verifiable 7. Modifiable 8. Traceable

IEEE Std 830-1998: Parts of an SRS

Introduction
Purpose
purpose of SRS intended audience for SRS

Scope
identify software to be produced by name explain what software will (not) do describe application of software (benefits, objectives)

IEEE Std 830-1998: Parts of an SRS

Introduction (continued)
Definitions/acronyms/abbreviations References
list documents referenced by name and source

Overview
brief description of rest of SRS organization of SRS

IEEE Std 830-1998: Parts of an SRS

Overall description
Product perspective (related products?)
block diagram constraints
system interfaces identify functionality that fulfills each system requirement user interfaces hardware interfaces software interfaces how software interacts with supporting software (purpose, message content and format) required versions

IEEE Std 830-1998: Parts of an SRS

Overall description (continued)
Product perspective
constraints
communications interfaces network protocols memory requirements/limits on primary and secondary memory operations modes of operation interactive vs. unattended operation backup & recovery site adaptation requirement

IEEE Std 830-1998: Parts of an SRS

Overall description (continued)
Product functions
summary of major functions sw will perform

Intended user characteristics

educational level experience technical expertise

IEEE Std 830-1998: Parts of an SRS

Overall description (continued)

Constraints (limitations of developer options)

regulatory policies hardware limitations (e.g. signal timing requirements) interfaces to other applications parallel operation audit functions control functions higher-order language requirements reliability requirements criticality of the application safety and security considertations

IEEE Std 830-1998: Parts of an SRS

Overall description (continued)
Assumptions and dependencies
e.g. specific OS available on HW

Apportioning of requirements
requirements that may be delayed to future versions

IEEE Std 830-1998: Parts of an SRS

Specific requirements
External interfaces Functions Performance requirements Logical database requirements Design constraints
Standards compliance

IEEE Std 830-1998: Parts of an SRS

Specific requirements (continued)
Software system attributes
Reliability Availability Security Maintainability Portability

IEEE Std 830-1998: Parts of an SRS

Specific requirements (continued)
Organizing the specific requirements
System mode User class Objects Feature Stimulus Response Functional hierarchy

Additional comments

IEEE Std 830-1998: Parts of an SRS

Supporting Information
Table of contents Index Appendixes

Requirements Engineering
Requirements Definition

Feasibility Study Requirements Elicitation and Analysis

Requirements Specification

Feasibility Report

System Models
SRS

V&V

Requirements Definition Document (RDD)

*Software Project Management Plan

User Manual Test Plan

Requirements Engineering
Requirements Definition

Feasibility Study
Requirements Elicitation and Analysis

Feasibility Report

Requirements Specification System Models SRS V&V

Requirements Definition Document (RDD)

*Software Project Management Plan

User Manual Test Plan

Requirements Engineering
Requirements Definition

Feasibility Study
Requirements Elicitation and Analysis

Feasibility Report

Requirements Specification System Models SRS V&V

Requirements Definition Document (RDD)

*Software Project Management Plan

User Manual Test Plan

Phases of the project life cycle

Feasibility Study

Feasibility Study
A feasibility study is a study made before committing to a project. A feasibility study leads to a decision: go ahead do not go ahead think again

In production projects, the feasibility study often leads to a budget request. A feasibility study may be in the form of a proposal.

Contents of Feasibility Study

Client: Who is this project for? Scope: What are the boundaries of the project? Benefits: What are the benefits? Can they be quantified? Technical: Is the project possible. Is there at least one technical way to carry out the project? Resources: What are the estimates of staff, time, equipment, etc?

Alternatives: What are the options if the project is not begun?

Feasibility Report
A written document

For a general audience: client, financial management, technical management, etc.

Short enough that everybody reads it.

Long enough that no important topics are skipped.

Details are often included in supporting documents.

It should be a well written, well presented document.

Types of Feasibility
Economic feasibility Technical feasibility Operational feasibility Schedule feasibility Legal and contractual feasibility Political feasibility

Economic Feasibility
Cost-benefit analysis identify all the financial benefits and costs associated with a project Tangible vs. intangible benefits Tangible vs. intangible costs One-time vs. recurring costs

Technical Feasibility
Assessing the organizations ability to construct the proposed system Takes into account various project risk factors

Other Feasibility Concerns

Operational
Will the system achieve the objectives of the project?

Schedule
Can the project be accomplished in a reasonable time frame? Project management critical path scheduling can help answer this concern.

Legal/Contractual
Are there regulations or legal obligations that affect the success of the project?

Political
Will the project have user and management support? Will there be resistance?

SOFTWARE PROJECT MANAGEMENT

Software Project management

Software Project Management includes
Planning Organizing Monitoring & Controlling Software Projects.

Issues to be handled under SPM

How must the people, process, and problem be managed during a software project? What are software metrics and how can they be used to manage a software project and the software process? How does a software team generate reliable estimates of effort, cost, and project duration? What techniques can be used to formally assess the risks that can have an impact on project success?

Issues to be handled under SPM

How does a software project manager select the set of software engineering work tasks? How is a project schedule created? How is quality defined so that it can be controlled? What is software quality assurance? Why are formal technical reviews so important? How is change managed during the development of computer software and after delivery to the customer?

Definition of Project Management

Project management involves the planning, organizing, monitoring, and control of the people, process, and events that occur as software evolves from a preliminary concept to an operational implementation.

What is Software project management

Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software. Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software.

Who does Software Project Management

Everyone manages to some extent, but the scope of management activities varies with the person doing it. A software engineer manages his day-to-day activities, planning, monitoring, and controlling technical tasks. Project managers plan, monitor, and control the work of a team of software engineers. Senior managers coordinate the interface between the business and the software professionals

Why Software Project Management is important Building computer software is a complex undertaking, particularly if it involves many people working over a relatively long time.

The 4 Ps
People the most important element of a successful project Product the software to be built Process the set of framework activities and software engineering tasks to get the job done Project all work required to make the product a reality

62

The People
The people factor is so important that the Software Engineering Institute has developed a people management capability maturity model (PM-CMM), to enhance the readiness of software organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and retain the talent needed to improve their software development capability

People management capability maturity model (PM-CMM)

The people management maturity model defines the following key practice areas for software people: recruiting, selection, performance management, training, compensation, career development, organization and work design, and team/culture development. Organizations that achieve high levels of maturity in the people management area have a higher likelihood of implementing effective software engineering practices.

The Product
Before a project can be planned, product objectives and scope should be established. Alternative solutions should be considered, and technical and management constraints should be identified. Without this information, it is impossible to define reasonable (and accurate) estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks, or a manageable project schedule that provides a meaningful indication of progress.

The Process
A software process provides the framework from which a comprehensive plan for software development can be established. A number of different task setstasks, milestones, work products, and quality assurance points enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team.

The Project
In 1998, industry data indicated that 26 percent of software projects failed outright and 46 percent experienced cost and schedule overruns. In order to avoid project failure, a software project manager and the software engineers who build the product must avoid a set of common warning signs, understand the critical success factors that lead to good project management, and develop a commonsense approach for planning, monitoring and

Who are the Stakeholders in SPM

Senior managers who define the business issues that often have significant influence on the project. Project (technical) managers who must plan, motivate, organize, and control the practitioners who do software work. Practitioners who deliver the technical skills that are necessary to engineer a product or application. Customers who specify the requirements for the software to be engineered and other stakeholders who have a peripheral interest in the outcome. End-users who interact with the software once it is 68 released for production use.

What is MOI model of leadership

Motivation. The ability to encourage (by push or pull) technical people to produce to their best ability. Organization. The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. Ideas or innovation. The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

Types of Software Team

Mantei [MAN81] suggests three generic team organizations: Democratic decentralized (DD). This software engineering team has no permanent leader. Rather, "task coordinators are appointed for short durations and then replaced by others who may coordinate different tasks. Decisions on problems and approach are made by group consensus. Communication among team members is horizontal.

Types of Software Team

Controlled decentralized (CD). This software engineering team has a defined leader who coordinates specific tasks and secondary leaders that have responsibility for subtasks.
Problem solving remains a group activity, but implementation of solutions is partitioned among subgroups by the team leader. Communication among subgroups and individuals is horizontal. Vertical communication along the control hierarchy also occurs.

Types of Software Team

Controlled Centralized (CC). Top-level problem solving and internal team coordination are managed by a team leader. Communication between the leader and team members is vertical.

What are the Project coordination techniques

Formal, impersonal approaches include software engineering documents and deliverables (including source code), technical memos, project milestones, schedules, and project control tools, change requests and related documentation, error tracking reports, and repository data. Formal, interpersonal procedures focus on quality assurance activities applied to software engineering work products. These include status review meetings and design and code

What are the Project coordination techniques

Informal, interpersonal procedures include group meetings for information dissemination and problem solving sessions for development staff. Electronic communication encompasses electronic mail, electronic bulletin boards, and by extension, video-based conferencing systems. Interpersonal networking includes informal discussions with team members and those outside the project who may have experience

Motivation behind the selection of Software Teams

The difficulty of the problem to be solved The size of the resultant program(s) in lines of code or function points The time that the team will stay together (team lifetime) The degree to which the problem can be modularized The required quality and reliability of the system to be built The rigidity of the delivery date 75 The degree of sociability (communication)

Types of Organizational Structure

Closed structures a team along a traditional hierarchy of authority Random structures a team loosely and depends on individual initiative of the team members Open attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm Synchronous relies on the natural partitioning of a problem and organizes team members to work on pieces of the problem with little active communication among themselves
76

suggested by Constantine [CON93]

What is the Product Scope.

Scope
Context. How does the software to be built fit into a larger system, product, or business context and what constraints are imposed as a result of the context? Information objectives. What customer-visible data objects are produced as output from the software? What data objects are required for input? Function and performance. What function does the software perform to transform input data into output? Are any special performance characteristics to be addressed?

Software project scope must be unambiguous and understandable at the management and 77 technical levels.

What is Problem Decomposition

Sometimes called partitioning or problem elaboration Once scope is defined
It is decomposed into constituent functions It is decomposed into user-visible data objects or It is decomposed into a set of problem classes

Decomposition process continues until all functions or problem classes have been defined
78

The Process
Once a process framework has been established
Consider project characteristics Determine the degree of rigor required Define a task set for each software engineering activity
Task set =

Software engineering tasks Work products Quality assurance points 79 Milestones

The Project get into trouble when

Software people dont understand their customers needs. The product scope is poorly defined. Changes are managed poorly. The chosen technology changes. Business needs change [or are ill-defined]. Deadlines are unrealistic. Users are resistant. Sponsorship is lost [or was never properly obtained]. The project team lacks people with appropriate skills. Managers [and practitioners] avoid best practices and 80 lessons learned.

Common-Sense Approach to Projects

Start on the right foot. Maintain momentum. Track progress. Make smart decisions. Conduct a postmortem analysis.

81

THE W5HH PRINCIPLE: A way of analysis

It includes a series of questions that lead to a definition of key project characteristics and the resultant project plan: Why is the system being developed? What will be done? When will it be accomplished? Who is responsible? Where are they organizationally located? How will the job be done technically and managerially? 82 How much of each resource (e.g., people,

Why SPM is different...

The product is intangible. The product is uniquely flexible. Software engineering is not recognized as an engineering discipline with the sound status as mechanical, electrical engineering, etc. The software development process is not standardised. Many software projects are never-to -berepeated' projects

What are the Management activities

Proposal writing Project planning and scheduling Project costing Project monitoring and reviews Personnel selection and evaluation Report writing and presentations

Why Project planning is important

Probably the most time-consuming project management activity Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available. Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget

Types of project plan

Pl an Qualit y plan Des cripti on Describes the qualit y procedures and standards that will be used in a project. Validation plan Describes t he approach, resources and schedule used for syst em validation. Configuration Describes t he configurat ion management management plan procedures and struct ures to be used. Maint enance plan Predicts t he maint enance requirement s of t he syst em, maint enance cost s and effort required. St aff development plan. Describes how t he skills and experience of t he project team members will be developed.

Project plan structure

Introduction Project organisation Risk analysis Hardware and software resource requirements Work breakdown Project schedule Monitoring and reporting mechanisms

Activity organization
Activities in a project should be organised to produce tangible outputs for management to judge progress Milestones are the end-point of a process activity Deliverables are project results delivered to customers The waterfall process allows for the straightforward definition of progress milestones

Milestones in the SE process

ACT IVITIES Feasibility study Requir ements analysis Prototype development Design study Requir ements specification

Feasibility report

Requir ements definition

Evaluation report MILESTONES

Architectural design

Requir ements specification

Project scheduling
Split project into tasks and estimate time and resources required to complete each task Organize tasks concurrently to make optimal use of workforce Minimize task dependencies to avoid delays caused by one task waiting for another to complete Dependent on project managers intuition and experience

The project scheduling process

Identify activities

Identify activity dependencies

Estimate resources for activities

Allocate people to activities

Create project charts

Software requirements

Activity charts and bar charts

Scheduling problems; why it occurs.

Estimating the difficulty of problems and hence the cost of developing a solution is hard Productivity is not proportional to the number of people working on a task Adding people to a late project makes it later because of communication overheads The unexpected always happens. Always allow contingency in planning

Bar charts and activity networks

Graphical notations used to illustrate the project schedule Show project breakdown into tasks.
Tasks should not be too small. They should take about a week or two

Activity charts show task dependencies and the critical path Bar charts show schedule against calendar time

Task durations and dependencies

Task T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duration (days) 8 15 15 10 10 5 20 25 15 15 7 10 Dependencies T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)

Activity network
14/7/99 8 days T1 4/7/99 start 15 days T2 10 days T4 18/7/99 M5 25 days T8 19/9/99 Finish 25/7/99 M2 T7 10 days T5 11/8/99 M7 15 days T10 M1 15 days T3 5 days T6 20 days 4/8/99 M4 15 days T9 25/7/99 M3 25/8/99 M6 7 days T11 5/9/99 M8 10 days T12

Activity timeline
4/ 7 T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T1 0 M6 T1 1 M8 T1 2 Fi n is h 11/ 7 St art 18 / 7 25 / 7 1/ 8 8/ 8 15 / 8 22 / 8 29 / 8 5/ 9 12 / 9 19 / 9

Staff allocation
4/7 Fred T4 T8 Jane T1 T3 T9 Anne T2 T6 Jim Mary T7 T5 T10 T11 T12 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Risk management
Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project. A risk is a probability that some adverse circumstance will occur.
Project risks affect schedule or resources Product risks affect the quality or performance of the software being developed Business risks affect the organisation developing or procuring the software

Software risks
Risk Staff turnover Management change Hardware unavailability Requirements change Specification delays Size underestimate CASE tool underperformance T echnology change Product competition Risk type Project Project Project Project and product Project and product Project and product Product Business Business Description Experienced staff will leave the project before it is finished. There will be a change of organisational management with different priorities. Hardware which is essential for the project will not be delivered on schedule. There will be a larger number of changes to the requirements than anticipated. Specifications of essential interfaces are not available on schedule The size of the system has been underestimated. CASE tools which support the project do not perform as anticipated The underlying technology on which the system is built is superseded by new technology. A competitive product is marketed before the system is completed.

The Risk Management Process

Risk identification
Identify project, product and business risks

Risk analysis
Assess the likelihood and consequences of these risks

Risk planning
Draw up plans to avoid or minimise the effects of the risk

Risk monitoring
Monitor the risks throughout the project

The risk management process

Risk identification

Risk analysis

Risk planning

Risk monitoring

List of potential risks

Prioritised risk list

Risk avoidance and contingency plans

Risk assessment

Risk identification
Technology risks People risks Organisational risks Requirements risks Estimation risks

Risks and risk types

Risk type Technology Possible risks The database used in the system cannot process as many transactions per second as expected. Software components which should be reused contain defects which limit their functionality. It is impossible to recruit staff with the skill s required. Key staff are ill and unavailable at critical times. Required training for staff is not available. The organisation is restructured so that different management are responsible for the project. Organisational financial problems force reductions in the project budget. The code generated by CASE tools is inefficient. CASE tools cannot be integrated. Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes. The time required to develop the software is underestimated. The rate of defect repair is underestimated. The size of the software is underestimated.

People Organisational

Tools Requirements

Estimation

Risk analysis
Assess probability and seriousness of each risk Probability may be
very low low moderate high or very high

Risk effects might be

catastrophic serious Tolerable

Risk analysis
Risk Organisational financial problems force reductions in the project budget. It is impossible to recruit staff with the skill s required for the project. Key staff are ill at critical times in the project. Software components which should be reused contain defects which limit their functionalit y. Changes to requirements which require major design rework are proposed. The organisation is restructured so that different management are responsible for the project. The database used in the system cannot process as many transactions per second as expected. The time required to develop the software is underestimated. CASE tools cannot be integrated. Customers fail to understand the impact of requirements changes. Required training for staff is not available. The rate of defect repair is underestimated. The size of the software is underestimated. The code generated by CASE tools is inefficient. Probability Effects Low Catastrophic High Moderate Moderate Moderate High Moderate High High Moderate Moderate Moderate High Moderate Catastrophic Serious Serious Serious Serious Serious Serious Tolerable Tolerable Tolerable Tolerable Tolerable Insignificant

Risk planning
Consider each risk and develop a strategy to manage that risk Avoidance strategies
The probability that the risk will arise is reduced

Minimisation strategies
The impact of the risk on the project or product will be reduced

Contingency plans
If the risk arises, contingency plans are plans to deal with that risk

Risk management strategies

Risk Organisational financial problems Recruitment problems Staff illness Defective components Requirements changes Organisational restructuring Database performance Underestimated development time Strategy Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business. Alert customer of potential difficulties and the possibility of delays, investigate buying-in components. Reorganise team so that there is more overlap of work and people therefore understand each others jobs. Replace potentially defective components with bought-in components of known reliability. Derive traceabili ty information to assess requirements change impact, maximise information hiding in the design. Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business. Investigate the possibilit y of buying a higher-performance database. Investigate buying in components, investigate use of a program generator.

Risk monitoring
Assess each identified risks regularly to decide whether or not it is becoming less or more probable Also assess whether the effects of the risk have changed Each key risk should be discussed at management progress meetings

Risk factors
Risk type Technology People Organisational Tools Requirements Estimation Potential indicators Late delivery of hardware or support software, many reported technology problems Poor staff morale, poor relationships amongst team member, job availabilit y organisational gossip, lack of action by senior management reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations many requirements change requests, customer complaints failure to meet agreed schedule, failure to clear reported defects

Key points
Good project management is essential for project success. The intangible nature of software causes problems for management. Managers have diverse roles but their most significant activities are planning, estimating and scheduling. Planning and estimating are iterative processes which continue throughout the course of a project.

Key points
A project milestone is a predictable state where some formal report of progress is presented to management. Risks may be project risks, product risks or business risks Risk management is concerned with identifying risks which may affect the project and planning to ensure that these risks do not develop into major threats