8/12/2019 Requiriments specifiction
1/111
8/12/2019 Requiriments specifiction
2/111
Non-functional requirement
types
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
8/12/2019 Requiriments specifiction
3/111
Requirements measures
8/12/2019 Requiriments specifiction
4/111
Requirements measures
Prope rty Measure
Speed Processed transactions/secondUser/Event response timeScreen refresh t ime
Size K Bytes
Number of RAM chipsEase of use Training t ime
Number of help frames
Reliability Mean time to failureProbability of unavailabilityRate o f failure o ccurrence
AvailabilityRobustness Time to restart after failure
Percentage of events causing failureProbabilit y of dat a corruption on failure
Port abilit y Percent age of t arget dependent statementsNumber of t arget syst ems
8/12/2019 Requiriments specifiction
5/111
8/12/2019 Requiriments specifiction
6/111
8/12/2019 Requiriments specifiction
7/111
Requirements and design
In practice, requirements and design are
inseparable
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
8/12/2019 Requiriments specifiction
8/111
Relationships between user
needs, concerns and NFRs
8/12/2019 Requiriments specifiction
9/111
Relationships between user
needs, concerns and NFRs
Users need Users concern Non-functional
requirement
Function 1. Ease of use
2. Unauthorised access
3. Likelihood of failure
1. Usability
2. Security
3. Reliability
Performance 1. Resource utilisation
2. Performance verification
3. Ease of interfacing
1. Efficiency
2.
Verifiability
3. Interoperability
Change 1. Ease of repair2. Ease of change
3. Ease of transport ?
4. Ease of expanding or upgrading
capacity or performance ?
1. Maintainability2. Flexibility
3. Portability
4. Expandability
8/12/2019 Requiriments specifiction
10/111
8/12/2019 Requiriments specifiction
11/111
8/12/2019 Requiriments specifiction
12/111
Problems with natural language
8/12/2019 Requiriments specifiction
13/111
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 expressedtogether
8/12/2019 Requiriments specifiction
14/111
Alternatives to NL specification
8/12/2019 Requiriments specifiction
15/111
Alternatives to NL specification
Notation DescriptionStructurednaturallanguage
This approach depends on defining standardforms or templates to express the requirementsspecification.
Designdescription
languages
This approach uses a language like aprogramming language but with more abstract
features to specify the requirements by definingan operational model of the system.
Graphicalnotations
A graphical language, supplemented by textannotations is used to define the functionalrequirements for the system.
Mathematical
specifications
These are notations based on mathematical
concepts such as finite-state machines or sets.These unambiguous specifications reduce thearguments between customer and contractorabout system functionality.
8/12/2019 Requiriments specifiction
16/111
What is Requirement Document
8/12/2019 Requiriments specifiction
17/111
8/12/2019 Requiriments specifiction
18/111
Users of a requirements document
8/12/2019 Requiriments specifiction
19/111
8/12/2019 Requiriments specifiction
20/111
8/12/2019 Requiriments specifiction
21/111
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
8/12/2019 Requiriments specifiction
22/111
8/12/2019 Requiriments specifiction
23/111
8/12/2019 Requiriments specifiction
24/111
8/12/2019 Requiriments specifiction
25/111
Purpose (continued)
1. It provides feedback to the customer.2. It decomposes the problem into component parts.
3. It serves as an input to the design specification.
4. It serves as a product validation check.
8/12/2019 Requiriments specifiction
26/111
8/12/2019 Requiriments specifiction
27/111
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.
8/12/2019 Requiriments specifiction
28/111
8/12/2019 Requiriments specifiction
29/111
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 auser.
This can be extended to become a description of how
to carry out these required tasks with the finished
system.
8/12/2019 Requiriments specifiction
30/111
IEEE Std 830-1998 Characteristics of
a good SRS
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Ranked for
importance and/or
stability
6. Verifiable
7. Modifiable
8. Traceable
IEEE Std 830 1998 P t f
8/12/2019 Requiriments specifiction
31/111
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)
S 830 1998 f
8/12/2019 Requiriments specifiction
32/111
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
8/12/2019 Requiriments specifiction
33/111
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
8/12/2019 Requiriments specifiction
34/111
IEEE Std 830 1998: Parts of an
8/12/2019 Requiriments specifiction
35/111
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 P t f
8/12/2019 Requiriments specifiction
36/111
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 P t f
8/12/2019 Requiriments specifiction
37/111
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
8/12/2019 Requiriments specifiction
38/111
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
8/12/2019 Requiriments specifiction
39/111
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
8/12/2019 Requiriments specifiction
40/111
IEEE Std 830-1998: Parts of an
SRS
Specific requirements (continued) Organizing the specific requirements System mode
User class
Objects Feature
Stimulus
Response
Functional hierarchyAdditional comments
IEEE Std 830 1998: Parts of an
8/12/2019 Requiriments specifiction
41/111
IEEE Std 830-1998: Parts of an
SRS
Supporting Information Table of contents
Index
Appendixes
8/12/2019 Requiriments specifiction
42/111
Requirements Engineering
Feasibility
Study
Requirements
Elicitation andAnalysis
Requirements
Specification
Feasibility
Report
System
Models
SRS
Requirements
Definition
Document (RDD)
Requirements
Definition
User Manual
Test Plan
V&V
*Software Project
Management
Plan
8/12/2019 Requiriments specifiction
43/111
Requirements Engineering
Feasibility
Study
Requirements
Elicitation andAnalysis
Requirements
Specification
Feasibility
Report
System
Models
SRS
Requirements
Definition
Document (RDD)
Requirements
Definition
User Manual
Test Plan
V&V
*Software Project
Management
Plan
8/12/2019 Requiriments specifiction
44/111
Requirements Engineering
Feasibility
Study
Requirements
Elicitation andAnalysis
Requirements
Specification
Feasibility
Report
System
Models
SRS
Requirements
Definition
Document (RDD)
Requirements
Definition
User Manual
Test Plan
V&V
*Software Project
Management
Plan
Phases of the project life
8/12/2019 Requiriments specifiction
45/111
Phases of the project life
cycle
8/12/2019 Requiriments specifiction
46/111
Feasibility Study
8/12/2019 Requiriments specifiction
47/111
8/12/2019 Requiriments specifiction
48/111
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 onetechnical
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?
F ibilit R t
8/12/2019 Requiriments specifiction
49/111
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 wel l wr i t ten, well presented document.
T f F ibili
8/12/2019 Requiriments specifiction
50/111
Types of Feasibility
Economic feasibility
Technical feasibility
Operational feasibility
Schedule feasibility
Legal and contractual feasibility
Political feasibility
E i F ibilit
8/12/2019 Requiriments specifiction
51/111
Economic Feasibility
Cost-benefit analysisidentify all the financialbenefits and costs associated with a project
Tangible vs. intangible benefits
Tangible vs. intangible costs
One-time vs. recurring costs
T h i l F ibilit
8/12/2019 Requiriments specifiction
52/111
Technical Feasibility
Assessing the organizations ability to construct
the proposed system
Takes into account various project risk factors
8/12/2019 Requiriments specifiction
53/111
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 thesuccess of the project?
Political Will the project have user and management support?
Will there be resistance?
8/12/2019 Requiriments specifiction
54/111
SOFTWARE PROJECTMANAGEMENT
S ft P j t t
8/12/2019 Requiriments specifiction
55/111
Software Project management
Software Project Management includes
Planning
OrganizingMonitoring
& Controlling Software Projects.
Issues to be handled under
8/12/2019 Requiriments specifiction
56/111
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 thesoftware 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?
8/12/2019 Requiriments specifiction
57/111
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 becontrolled?
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?
8/12/2019 Requiriments specifiction
58/111
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
8/12/2019 Requiriments specifiction
59/111
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 developingand procuring the software.
Project management is needed because
software development is always subject to
budget and schedule constraints that are setby the organisation developing the software.
8/12/2019 Requiriments specifiction
60/111
Why Software Project Management is
8/12/2019 Requiriments specifiction
61/111
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.
8/12/2019 Requiriments specifiction
62/111
The 4 Ps
Peoplethe most important element of asuccessful project
Product the software to be built
Process the set of framework activitiesand software engineering tasks to get the
job done
Projectall work required to make the
product a reality
62
8/12/2019 Requiriments specifiction
63/111
Peop le management capabi l ity
8/12/2019 Requiriments specifiction
64/111
Peop le management capabi l ity
maturi ty 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 ofmaturity in the people management area have
a higher likelihood of implementing effective
software engineering practices.
8/12/2019 Requiriments specifiction
65/111
The Product
Before a project can be planned, product
objectives and scope should be established.
Alternative solutions should be considered,
and technical and management constraintsshould 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.
8/12/2019 Requiriments specifiction
66/111
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, workproducts, 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.
8/12/2019 Requiriments specifiction
67/111
S S
8/12/2019 Requiriments specifiction
68/111
Who are the Stakeholders in SPM
Senio r managerswho define the business issuesthat often have significant influence on the project.
Project (technical) managers who must plan,
motivate, organize, and control the practitioners
who do software work.
Pract i t ioners who deliver the technical skills that
are necessary to engineer a product or application.
Customers who specify the requirements for thesoftware to be engineered and other stakeholders
who have a peripheral interest in the outcome.
End-userswho interact with the software once it is
released for production use.68
Wh t i MOI d l f l d hi
8/12/2019 Requiriments specifiction
69/111
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 existingprocesses (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.
8/12/2019 Requiriments specifiction
70/111
T f S ft T
8/12/2019 Requiriments specifiction
71/111
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 individualsis horizontal. Vertical communication along the
control hierarchy also occurs.
T f S ft T
8/12/2019 Requiriments specifiction
72/111
Types of Software Team
Controlled Centralized (CC). Top-levelproblem solving and internal team
coordination are managed by a team leader.
Communication between the leader and teammembers is vertical.
What are the Project coordination
8/12/2019 Requiriments specifiction
73/111
Formal, impersonal approaches includesoftware engineering documents and
deliverables (including source code), technical
memos, project milestones, schedules, andproject control tools, change requests and
related documentation, error tracking reports,
and repository data.
Formal, interpersonal procedures focus onquality assurance activities applied to software
engineering work products. These include
status review meetings and design and code
What are the Project coordination
techniques
8/12/2019 Requiriments specifiction
74/111
Motivation behind the selection of
8/12/2019 Requiriments specifiction
75/111
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 (teamlifetime)
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
The de ree of sociabilit communication75
8/12/2019 Requiriments specifiction
76/111
Wh t i th P d t S
8/12/2019 Requiriments specifiction
77/111
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 dataobjects 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 beaddressed?
Software project scope must be unambiguous
and understandable at the management and
technical levels.77
What is Problem Decomposition
8/12/2019 Requiriments specifiction
78/111
What is Problem Decomposition
Sometimes called part i t ion ingor prob lem
elaborat ion
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
defined78
The Process
8/12/2019 Requiriments specifiction
79/111
The Process
Once a process framework has beenestablished
Consider project characteristics
Determine the degree of rigor required Define a task set for each software engineering
activity
Task set =
Software engineering tasksWork products
Quality assurance points
Milestones79
The Project get into trouble
8/12/2019 Requiriments specifiction
80/111
j g
when
Software people dont understand their customersneeds.
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
lessons learned.80
8/12/2019 Requiriments specifiction
81/111
THE W5HH PRINCIPLE: A way of
8/12/2019 Requiriments specifiction
82/111
y
analysis
It includes a series of questions that lead to adefinition 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?
How much of each resource (e.g., people,82
Wh SPM i diff t
8/12/2019 Requiriments specifiction
83/111
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 asmechanical, electrical engineering, etc.
The software development process is not
standardised. Many software projects are never-to -be-
repeated' projects
What are the Management activities
8/12/2019 Requiriments specifiction
84/111
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
8/12/2019 Requiriments specifiction
85/111
Why Project planning is important
Probably the most time-consuming projectmanagement activity
Continuous activity from initial concept through
to system delivery. Plans must be regularlyrevised 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
8/12/2019 Requiriments specifiction
86/111
Project plan structure
8/12/2019 Requiriments specifiction
87/111
Project plan structure
Introduction
Project organisation
Risk analysis
Hardware and software resource requirements
Work breakdown
Project schedule
Monitoring and reporting mechanisms
Activity organization
8/12/2019 Requiriments specifiction
88/111
Activity organization
Activities in a project should be organised toproduce tangible outputs for management to
judge progress
Milestonesare the end-point of a processactivity
Deliverablesare project results delivered to
customers
The waterfall process allows for the
straightforward definition of progress
milestones
Milestones in the SE process
8/12/2019 Requiriments specifiction
89/111
Milestones in the SE process
Evaluationreport
Prototype
development
Requirementsdefinition
Requirements
analysis
Feasibilityreport
Feasibility
study
Architecturaldesign
Design
study
Requirementsspecification
Requirements
specification
ACTIVITIES
MILESTONES
Project scheduling
8/12/2019 Requiriments specifiction
90/111
Project scheduling
Split project into tasks and estimate time andresources 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
8/12/2019 Requiriments specifiction
91/111
Scheduling problems; why it
8/12/2019 Requiriments specifiction
92/111
occurs.
Estimating the difficulty of problems and hencethe 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. Alwaysallow contingency in planning
Bar charts and activity networks
8/12/2019 Requiriments specifiction
93/111
Bar charts and activity networks
Graphical notations used to illustrate theproject 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
8/12/2019 Requiriments specifiction
94/111
Task durations and dependencies
Task Duration (days) Dependenci esT1 8
T2 15
T3 15 T1 (M1)
T4 10T5 10 T2, T4 (M2)
T6 5 T1, T2 (M3)
T7 20 T1 (M1)
T8 25 T4 (M5)
T9 15 T3, T6 (M4)
T10 15 T5, T7 (M7)
T11 7 T9 (M6)
T12 10 T11 (M8)
Activity network
8/12/2019 Requiriments specifiction
95/111
Activity network
start
T2
M3T6
Finish
T10
M7T5
T7
M2T4
M5
T8
4/7/99
8 days
14/7/99 15 days
4/8/99
15 days
25/8/99
7 days
5/9/99
10 days
19/9/99
15 days
11/8/99
25 days
10 days
20 days
5 days25/7/99
15 days
25/7/99
18/7/99
10 days
T1
M1 T3
T9
M6
T11
M8
T12
M4
Activity timeline
8/12/2019 Requiriments specifiction
96/111
Activity timeline
4/ 7 11/ 7 18 / 7 25 / 7 1/ 8 8/ 8 15 / 8 22 / 8 29 / 8 5/ 9 12 / 9 19 / 9
T4
T1
T2
M1
T7
T3
M5T8
M3
M2
T6
T5
M4
T9
M7
T1 0
M6
T1 1
M8
T1 2
Sta rt
Fin ish
Staff allocation
8/12/2019 Requiriments specifiction
97/111
Staff allocation
4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
T4
T8 T11
T12
T1
T3
T9
T2
T6 T10
T7
T5
Fred
Jane
Anne
Mary
Jim
Risk management
8/12/2019 Requiriments specifiction
98/111
Risk management
Risk management is concerned with identifyingrisks and drawing up plans to minimise theireffect on a project.
A risk is a probability that some adversecircumstance will occur.Project risks affect schedule or resources
Product risks affect the quality or performance of thesoftware being developed
Business risks affect the organisation developing orprocuring the software
Software risks
8/12/2019 Requiriments specifiction
99/111
Software risksRisk Risk type Description
Staff turnover Project Experienced staff will leave the
project before it is finished.
Management change Project There will be a change of organisational management with
different priorities.
Hardware unavailability Project Hardware which is essential for the
project will not be delivered on
schedule.
Requirements change Project andproduct There will be a larger number ofchanges to the requirements than
anticipated.
Specificat ion delays Project and
product
Specifications of essential interfaces
are not available on schedule
Size underestimate Project and
product
The size of the system has been
underestimated.
CASE tool under-performance
Product CASE tools which support theproject do not perform as anticipated
T echnology change Business The underlying technology on which
the system is built is superseded by
new technology.
Product competition Business A competitive product is marketed
before the syst em is complet ed.
The Risk Management Process
8/12/2019 Requiriments specifiction
100/111
The Risk Management Process
Risk identification Identify project, product and business risks
Risk analysis
Assess the likelihood and consequences of theserisks
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
8/12/2019 Requiriments specifiction
101/111
The risk management process
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
8/12/2019 Requiriments specifiction
102/111
8/12/2019 Requiriments specifiction
103/111
Risk analysis
8/12/2019 Requiriments specifiction
104/111
Risk analysis
Assess probability and seriousness of eachrisk
Probability may be
very low
low
moderate
high or very high
Risk effects might be catastrophic
serious
Tolerable
Risk analysis
8/12/2019 Requiriments specifiction
105/111
Risk analysis
Risk Probability Effects
Organisational financial problems force reductionsin the project budget.
Low Catastrophic
It is impossible to recruit staff with the skill srequired for the project.
High Catastrophic
Key staff are ill at cr itical t imes in the project. Moderate Serious
Software components w hich should be reusedcontain defects w hich limit their functionality.
Moderate Serious
Changes to requirements w hich require majordesign rework are proposed. Moderate Serious
The organisation is restructured so that differentmanagement are responsible for the project.
High Serious
The database used in the system cannot process asmany transactions per second as expected.
Moderate Serious
The time required to develop the software isunderestimated.
High Serious
CASE tools cannot be integrated. High TolerableCustomers fail to understand the impact ofrequirements changes.
Moderate Tolerable
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underes timated. Moderate TolerableThe size of the software is underestimated. High TolerableThe code generated by CASE tools is inefficient. Moderate Insignificant
Risk planning
8/12/2019 Requiriments specifiction
106/111
s p a g
Consider each risk and develop a strategy tomanage that risk
Avoidance strategiesThe probability that the risk will arise is reduced
Minimisation strategiesThe impact of the risk on the project or product will
be reduced
Contingency plansIf the risk arises, contingency plans are plans to
deal with that risk
8/12/2019 Requiriments specifiction
107/111
Risk monitoring
8/12/2019 Requiriments specifiction
108/111
g
Assess each identified risks regularly todecide whether or not it is becoming less or
more probable
Also assess whether the effects of the riskhave changed
Each key risk should be discussed at
management progress meetings
Risk factors
8/12/2019 Requiriments specifiction
109/111
Risk type Potential indicatorsTechnology Late delivery of hardware or support software, many
reported technology problems
People Poor staff morale, poor relationships amongst team
member, job availabilit y
Organisational organisational gossip, lack of action by seniormanagement
Tools reluctance by team members to use tools, complaintsabout CASE tools, demands for higher-powered
workstations
Requirements many requirements change requests, customercomplaints
Estimation failure to meet agreed schedule, failure to clearreported defects
Key points
8/12/2019 Requiriments specifiction
110/111
y p
Good project management is essential for projectsuccess.
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 processeswhich continue throughout the course of a
project.
Key points
8/12/2019 Requiriments specifiction
111/111
y p
A project milestone is a predictable statewhere
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 projectand planning to ensure that these risks do not
d l i j h
Top Related