4. requirement (scope) & risk management the life cycle of a large system integration project
TRANSCRIPT
4. REQUIREMENT (SCOPE) 4. REQUIREMENT (SCOPE) & RISK MANAGEMENT& RISK MANAGEMENT
4. REQUIREMENT (SCOPE) 4. REQUIREMENT (SCOPE) & RISK MANAGEMENT& RISK MANAGEMENT
The Life Cycle of A Large System Integration Project The Life Cycle of A Large System Integration Project The Life Cycle of A Large System Integration Project The Life Cycle of A Large System Integration Project
TYPES OF SOFTWARE APPLICATIONS
TYPES OF SOFTWARE APPLICATIONS
Information SystemDeveloped for use within a company, e.g., payroll system, ERP and AIMS, which are usually developed for the company or similar companies. Since each company has its own operation processes, rules and culture, even if there are products on the market, they have to be customizable. Without this capacity, their values would be very limited.
Commercial ProductsThis category of software, such as MS Word and PPT, is used by individuals and often referred to as independent software vendors (ISVs).
Embedded (or Customized)Software runs on computers embedded in other devices or machines, e.g., mobile phone, DVD player and automobile, called embedded applications.
REQUIREMENTS MANAGEMENTIN PROJECT LIFECYCLE
REQUIREMENTS MANAGEMENTIN PROJECT LIFECYCLE
Requirement Planning
Requirement Management
Presa
le PP
P
Plans
Requirem
ent Im
plementati
on InstallationA
nd T
esting
Desi
gn Acceptan
ce Delive
ry End
2 yr 2 mo 12 mo 3 mo2 mo 3 mo5 mo 1 mo
ACTUAL: Total of 30 months
Op
erationB
acku
p
M1Planning
M2Analysis
M5Testing
M6Delivery
M4Implementation
M3Design
WHY REQUIREMENT (1)WHY REQUIREMENT (1)STORY:
A famous tailor store received a letter from a customer, which states that she was too busy to come to the store personally and would like to order a cloth that is beautiful, sexy and warm but light to be used in her next trip to northern part of China, and which she once saw on a TV show. Her size was P (Pattie) and she was willing to pay a reasonable good price.
To do a good job on this order, the store manager decided to have a brainstorm session. In the session, one tailor said that the requirements were too vague and general, such as beautiful, sexy, warm and light and suggested not to take the order. Another said, “This is easy money. We simply make a nice orange feather jacket of size P, which is popular this year.” The manager thought that our store was famous because of its quality, service and honesty. However, it had never filled an order this way and it was really a challenge. He said “As stated in the letter, the requirements were not detail enough to match our committed standard: style, material, color, size and occasion. For the actual size has to be measured anyway, let’s give the customer a visit.” To be well prepared, the manager read the letter multiple times. He suddenly thought that the customer might be a foreigner because of her calligraphy. He sent an experienced tailor with sufficient English skill and asked him to bring several fashion magazines and sample materials with variety of colors.
WHY REQUIREMENT (2)WHY REQUIREMENT (2)
After the visit the tailor happily told the manager that the lady was an American and the letter was written under the help of her 8 years old daughter. She actually wanted to order for her next ski trip a black leather vest, which she saw in an advertisement on TV. After a warm and detailed discussion, she decided, under my suggestions, to order three pieces: a light blue leather vest, a pair of tightly fitted leather paints with the same color, and a silver short feather coat with matching light blue strips in the popular style of the year. I also suggested that she wear a white cashmere sweeter when skiing. It looked even nicer when she felt hot and took off the feather coat.
The lady was very happy when the order was delivered, and paid at 10% off the regular price !
WHY REQUIREMENT (3)WHY REQUIREMENT (3)
WHAT DO WE LEARN FROM THE STORY:
• Most time users know the objective of their orders, but not exactly what.
• The distance between customers and vendors.• Vendors must know their business and products very well.• Planning for requirement collection is important.• Requirements can only be elicited after collection and
analysis.• Requirements must be approved by the customers.
•What if the store fills the order according to the first tailor?
•What if the store fills the order according to the second tailor?
HIGH COST OF REQUIREMENTS ERRORS
HIGH COST OF REQUIREMENTS ERRORS
STAGE
Requirement
Design
Coding
Unit test
Acceptance
Maintenance
0.1 – 0.20.1 – 0.20.1 – 0.20.1 – 0.2
0.50.50.50.5
1111
2222
5555
20202020
Relative Cost to Repair
COST OF ERRORSCOST OF ERRORS
Defect Origins Delivered Defects Average Cost per Defect
Requirements
Design
Coding
Documentation
Others
Total
0.32
0.27
0.14
0.12
0.15
1
136
70
30
5
10
NA
What user sees, normalizedTo 1
What user sees, normalizedTo 1
Average manpower for a defect
Average manpower for a defect
Defect Summary
A requirement defect may involve multiple changes in multiple design
COST ASSOCIATE WITH A DEFECT BEFORE OPERATION
COST ASSOCIATE WITH A DEFECT BEFORE OPERATION
Customer sign off
Design Coding Unit Test
Regression Test
Internal Doc
User Doc
Other TOTAL
Coding 12 6 8 4 30
Design 19 18 8 11 8 6 70
Requirement
12 28 28 14 18 13 10 13 136
Note:• A requirement change may involve changes in multiple design,
each of which may further involve multiple changes of coding.• Cost for defect fixing is much more expensive and difficult to
manage.
Average manpower (man/hour) per defect
PROJECT WORKFLOW &REQUIREMENTS CHANGEPROJECT WORKFLOW &
REQUIREMENTS CHANGE
New Req
Airport Scale•Flight/year•Passengers/year
Airport Scale•Flight/year•Passengers/year
Business Objectives•Revenu•Service quality
Business Objectives•Revenu•Service quality
Business ModelBusiness Model
Operation Model ， Service ，Rule,Inter-operation
Operation Model ， Service ，Rule,Inter-operation
OrganizationOrganization
Operation flowOperation flow
Requirements Requirements
ComputerizeComputerize
New Req
EXAMPLE OF REQUIREMENT CHANGE
AT LATE STAGE
EXAMPLE OF REQUIREMENT CHANGE
AT LATE STAGECODE SHARING: Several airlines share one aircraft for a flight.
In competition, several airlines may operate their flights with the route (same origin and destination), which often causes low occupancy for all these flights. Code sharing is a business model, in which one airline is the master that physically operates the flight, but the tickets of the flight are sold by all shared airlines under individual airlines’ flight numbers.
An operation model has to be defined to support this business model. When a flight is code sharing, all resources are allocated for a single flight except for check-in counter. An airline may decide to do check-in only for its own passengers. The airport authority may decide all airlines in the code sharing use the same check-in counter to do check-in for all passengers of all airline in the code sharing.
This model would be realizable only if all relevant parts are able to support this operation model, e.g., FIDS, CKAS, GBAS, etc.
The customer wanted to add this new function when we were in system test phase.
TYPES OF REQUIREMENTS (1)TYPES OF REQUIREMENTS (1)
DesignDesignconstraintsconstraints
FunctionalFunctionalrequirementsrequirements
RequirementRequirementtypestypes
SoftwareSoftwarerequirementsrequirements
NonfunctionalNonfunctionalrequirementsrequirements
HardwareHardwarerequirementsrequirements
SOFTWARE REQUIREMENTSSOFTWARE REQUIREMENTS
DesignDesignconstraintsconstraints
SoftwareSoftwareFunctionalFunctional
requirementsrequirements
SoftwareSoftwareNonfunctionalNonfunctionalrequirementsrequirements
Usability: be more specific and measurableReliability:
Availability, Mean time between failure (MTBF), Mean time to repair (MTTR)AccuracyMaximum bugs or defect rateBugs per type (minor, significant, or critical)
Performance:Response timeThroughput: transaction per secondCapacity: number of customers or transactions
How to operate and how the system behaves and data associated
Impose limitation on the design of the system, when the developer normally has his/her choice, e.g., use ORACLE RDBMS, use VB, …
SOURCE OF REQUIREMENTSSOURCE OF REQUIREMENTS
Business Objectives•Revenue•Service quality•Flight/pear•Passengers/year
Business Objectives•Revenue•Service quality•Flight/pear•Passengers/year
Business ModelBusiness Model
Operation ModelOperation Model
Requirements Requirements
ComputerizeComputerize
Industry StandardIndustry Standard
Non-functionalNon-functional
Service,Management,Rule,Inter-operation with subsystems
Service,Management,Rule,Inter-operation with subsystems
TEMPLATE OF SRS (1)TEMPLATE OF SRS (1)
1. OVERVIEWIntroduction to the system to be built1.1 Current SystemBrief description of the current system if a system exists1.2 Limitations of the Current SystemList of limitations of the current system1.3 Proposed SystemOverview of the proposed system1.3.1 Objectives of the Proposed System
2. FUNCTIONAL REQUIREMENTSList of requirement related to the customer’s business 2.1 System Requirements2.2.1 Scope and Boundary2.1.2 Context Diagram2.2 Business Events2.2.1 External EventsList of external events are triggered by external entities, such as a client calling to place an order or a user enteringa command.2.2.2 Temporal EventsList of temporal events, which are triggered by time, e.g., producing a summary report every day at 9:00PM
2.3 Inputs and OutputsGive inputs and outputs for each business event2.4 RelationshipsSpecify relationship between inputs and outputs2.5 Precedence RelationshipsSpecify any precedence relationship between events2.6 Screens
3. EXTERNAL INTERFACE REQUIREMENTSThe system being developed might interface with many other existingautomated and non-automated systems. The description of the Subsystems, the relationships with the subsystems, and communication protocol and data are specified here. If a large number of subsystems isInvolved, separate documents shall be generated.
4. OPERATING ENVIRONMENT REQUIREMENTS4.1 Hardware4.2 Software4.3 Network4.4 Communication
TEMPLATE OF SRS (2)TEMPLATE OF SRS (2)
5. PERFORMANCE REQUIREMENTSAll performance requirements are specified here. Examplesinclude online response time, no of transactions per second, no of concurrent users, system throughput, quantity of data online, constraints on batch jobs, etc.
6. STANDARD REQUIREMENTSAll standards that the customer requires to be followed duringproject should be listed here. The actual standards can be listed in a separate documents.
6.1 User Interface6.2 Detailed Design6.3 Coding6.4 Documentation
SPECIAL USER REQUIREMENTS7.1 Security7.2 Audit Trail7.3 Reliability
7.4 Transaction Volume and Data Volumes7.5 Backup and Recovery7.6 Legal7.7 Data Migration7.8 Data Retention7.9 Installation7.10 User Training7.11 User Manual and Help7.12 Automated and Manual Function7.13 Features Not Required
9. CONSTANTS
10. PROTOTYPES
11. GLOSSARY OF TERMS & ACRONYMS
WHAT TO AVOID IN SRSWHAT TO AVOID IN SRS
Exclude Project Information:Schedule,Project plan,Staffing,Configuration managementBudgetTest
Exclude Design Information:
Example: “This application shall be implemented in VB”
If it is placed by an internal member for what ever the reasons, it should be take out from the SRS.
If it is placed by the user, it should be in design constraints, rather than in requirements.
PROJECTPROJECT
Write a SRS (Software Requirement Specification for a
GLUCOSE TEST DEVICE
2 persons per group
PROJECT aPROJECT a-- GLUCOSE TEST DEVICE --
Glucometer
Test Strip
TwoButtons
07/11/01 15:30
L
USB
TestResult
AC plug-in
A
Beeper
~
E
Date DateTime
Unit
UserBattery
ACError
ProgressiveBar
PROJECT bPROJECT b
Hardware Components
Sensor, A/D
Processor
Display
Buttons USB
Beeper Memory
Power Supplier
PROJECT cPROJECT c-- GLUCOSE TEST DEVICE --
Test Procedure
1. Insert a test strip (power on)2. The system is initialized3. Select user A or B
4. Feed the strip tip with blood sample (error if the amount is insufficient)
5. After 30 second, the test result is displayed
6. Pull out the strip and throw it away7. The system will shut down by itself 15
seconds after no button push
BeeperA beeper is equipped for giving user warnings and/or reminders
USBUser may upload test record history to PC
AC Plug The device is powered by battery or AC adaptor
Functions of DevicesScreenAs shown in the Figure, it can display date (year, month, day), progress-bar, Error status, user A/B,battery level, AC, test result, test unit, in designated area.
Other Requirements
• The device should operated between -10 C to 45 C
• The interface should be easy to use.
PROJECT dPROJECT d-- GLUCOSE TEST DEVICE --
Presentation
The SRS Start 6/12
Req. Collection 1 6/16
Req. Collection 2 6/17
SRS Due 6/30
Presentation 1 7/1
Presentation 2 7/2
Schedule
NINE QUALITY MEASURES (1)NINE QUALITY MEASURES (1)
1. Correct
2. Unambiguous
3. Complete
4. Consistent
5. Ranked for importance and stability
6. Verifiable
7. Modifiable
8. Traceable
9. Understandable
NINE QUALITY MEASURES (2)NINE QUALITY MEASURES (2)
Correct RequirementsAn SRS is correct iff every requirement stated therein is in area A. (Davis, 1993)
Omission of information in A
Undesirable inclusion of information in C introduced by enthusiastic marketing or technical people.
Example: “we are sure that user will really love this feature once they see it.”
A B C
Userneeds
SRS
Needs/requirements universe
NINE QUALITY MEASURES (2)NINE QUALITY MEASURES (2)
Unambiguous RequirementsAn requirement is unambiguous iff it can be subject to only one interpretation. (IEEE830-1993 4.3.2 1994)
Stakeholders (users, developers, etc.) may interpret a term or a phrase differently due to writing style and/or culture differences
PROCEDURE OF COOKING • The user open the microwave oven• Set up the time• Push the start button
• Hook to the power supplier• Open the microwave oven• Put the food in to the oven and close the door• Set up the timer, which will count down during cooking• Push the START button, it starts to cook if the door is closed and timer does not
equal to zero• The oven cooks the food and continuously display the count down.• If the user open the door before the timer equals to zero, the oven stops cooking
and the timer remain at the value when the door was opened• The user may resume cooking by closing the door and pushing the START
button, or stop cooking by pushing the CANCEL button
NINE QUALITY MEASURES (3)NINE QUALITY MEASURES (3)
Completeness of the Requirements SetA set of requirements is internally consistent iff no subsets of the requirement set are conflict with one another. (IEEE830-1993 4.3.3, 1994)
Judged by a competent reviewer or developer who has no special domain knowledge
Example: “The system shall accept a single numerical input and return the square root of that number.”
Range and Precision?
Consistency in the Requirements SetAn requirement is unambiguous iff it can be subject to only one interpretation. (IEEE830-1993 4.3.5, 1994)
Example: “Under A do B.” and “Under C do D.” What about C is inclusive within A? Even worse, if C and D are conflict with each other.
NINE QUALITY MEASURES (4)NINE QUALITY MEASURES (4)
Requirements Ranked for Importance and StabilityThe users, developers and other stakeholders have ranked the requirements by importance to the customer in terms of stability. (IEEE830-1993 4.3.5, 1994)
Importance and stability are likely associated with user’s perception of the world.
Verifiable RequirementsA requirement is verifiable iff there exists a finite and cost-effective process with which a person or a machine can test or prove. (IEEE830-1993 4.3.6, 1994)
Examples:“The system shall support up to 1,000 simultaneous users.”“The system shall respond to an arbitrary query in 500 milliseconds.”“The system shall be user-friendly.”“The system shall have stability, flexibility, reliability, and extensibility.”
NINE QUALITY MEASURES (5)NINE QUALITY MEASURES (5)
Modifiable Requirements SetA requirement set is modifiable iff its structure and style allow changes to be made easily, completely and consistently, while retaining its structure and style.. (IEEE830-1993 4.3.7, 1994)
The requirement set should have minimum redundancy with a proper table of contents, index, and cross referencing capabilities.
Traceable RequirementsA requirement is traceable iff each of its components is clear and there is a mechanism that makes it feasible to refer to in the future. (IEEE830-1993 4.3.8, 1994)
Understandable RequirementsBoth the user and developer communities are able to fully comprehend the individual requirements and the aggregate functionality implied by the set.
PROCESS FOR REQUIREMENTS (1)
PROCESS FOR REQUIREMENTS (1)
PlanPlanPlanPlan
Gather/ElicitGather/ElicitGather/ElicitGather/Elicit
AnalysisAnalysisAnalysisAnalysis
SRSSRSSRSSRS
Traceability Matrix Traceability Matrix Traceability Matrix Traceability Matrix
Change Change ControlControl
Change Change ControlControl DesignDesignDesignDesign TestTest
CasesCases
TestTestCasesCases
Sign-offSign-offSign-offSign-off
ReviewReviewReviewReview
PROCESS FOR REQUIREMENTS (2)
PROCESS FOR REQUIREMENTS (2)
Prepare for gathering & analysisPrepare for gathering & analysis
• Do background reading on technical/business concepts and and undergo training
• Become familiar with customer’s methodology and tools to be used
• Identify user groups and interviewees• Define requirement specification standards• Prepare questionnaires for eliciting information• Plan prototype• Identify methods for information gathering• Develop interview plan and review with customer
Gather requirementsGather requirements
• Establish objective and scope of the system• Gather functional requirements
Identify business eventsIdentify inputs and outputs for each business eventDetermine relationship between inputs and outputsDetermine precedence relationship among events
• Precedence relationships among events• Gather information on external interfaces• Gather operating environment requirements• Gather performance requirements• Gather industry standard requirements• Prepare and evaluate prototypes• Conduct feed back sessions
REQUIREMENT CHANGE CONTROL
REQUIREMENT CHANGE CONTROL
Log the changesLog the changesLog the changesLog the changes Impact analysisImpact analysisImpact analysisImpact analysis Estimate effortEstimate effortEstimate effortEstimate effort
Estimate schedule Estimate schedule Estimate schedule Estimate schedule Review impactReview impactwith seniorswith seniors
Review impactReview impactwith seniorswith seniors
PricePricenegotiationnegotiation
PricePricenegotiationnegotiation
Obtain Sign-off Obtain Sign-off from customerfrom customer
Obtain Sign-off Obtain Sign-off from customerfrom customer
REQUIREMENTS CHANGE TRACEABILITY
REQUIREMENTS CHANGE TRACEABILITY
Traceability MatrixTraceability MatrixValuable information for impact analysis when requirements change
To maintain a good and usable matrix, the following points should be followed:• Completeness needs to be checked against SRS, Design and Test docs.• All performance requirements must have test cases.• Like accounting systems, once recorded, cannot be deleted.• Cancelled and modified requirements must have new requirement #.• Need to be updated at many points (e.g., each review) in the lifecycle.
Traceability MatrixTraceability MatrixValuable information for impact analysis when requirements change
To maintain a good and usable matrix, the following points should be followed:• Completeness needs to be checked against SRS, Design and Test docs.• All performance requirements must have test cases.• Like accounting systems, once recorded, cannot be deleted.• Cancelled and modified requirements must have new requirement #.• Need to be updated at many points (e.g., each review) in the lifecycle.
Req# Date Description HLD doc Ref#
Functions Changes New Reqmt#
Unit test case
Integration test
case
Accep-tance test case
1.1.2 4/3/2005
Connect subsystems using multi-thread
4.3.2 One subsystem at a time
Two/three subsystems
E eliminated
C cancelled
M modified
New #
New #
#1
#12 #47
#11
#11
Note that other attributes, such as risk, cost, difficulty could be enormously useful.
CONCLUSIONCONCLUSION
1.1. Requirements errors are likely to be the Requirements errors are likely to be the most common class of errorsmost common class of errors
2.2. Requirements errors are likely to be the Requirements errors are likely to be the most expensive errors to fix at the later most expensive errors to fix at the later stage of the projectstage of the project
3.3. Requirement management should cover Requirement management should cover the lifecycle of a software projectthe lifecycle of a software project
1.1. Requirements errors are likely to be the Requirements errors are likely to be the most common class of errorsmost common class of errors
2.2. Requirements errors are likely to be the Requirements errors are likely to be the most expensive errors to fix at the later most expensive errors to fix at the later stage of the projectstage of the project
3.3. Requirement management should cover Requirement management should cover the lifecycle of a software projectthe lifecycle of a software project
RISK MANAGEMENTRISK MANAGEMENT
What Are Risks?Risks are those unexpected events that cause problems-sometimes severe problems-which threaten the success of IT projects or even the business.
What Can Happen Without Risk Management?Baring Bank, one of the older merchant banks in London, founded in 1765 and operated over 230 years before its collapse in 1995. It survived wars, economic depressions and turbulence but could not sustain the billions of dollars in loss cause by a single trader based in Singapore. Baring Bank was sold for one pound sterling, approximately $1.65 US.
Why?The bank did not have sufficient risk management procedures in place to halt the decline.
RISK MANAGEMENT IN PROJECT LIFECYCLERISK MANAGEMENT
IN PROJECT LIFECYCLE
Risk Management
Presa
le PP
P
Plans
Requirem
ent Im
plementati
on InstallationA
nd T
esting
Desi
gn Acceptan
ce Delive
ry End
2 yr 2 mo 12 mo 3 mo2 mo 3 mo5 mo 1 mo
ACTUAL: Total of 30 months
M1Planning
M2Requirement
M4Installation
M5Delivery
M3High Level Design
Op
eration
Back
up
TYPE OF RISKSTYPE OF RISKS
External RisksOutside the control of the program/project manager and, in most cases, the corporation.
Cost RisksMany of these risks are directly or indirectly under the control program/project managers.
Operational RisksSuch risks characterized by an inability to implement large-scale change effectively can result in failure to realize the intended or expected benefit of the project.
Schedule RisksMissing or delaying a market opportunity for a product or service.
Technology RisksFailure to meet systems target functionality or performance expectations.
EXAMPLES OF RISKS IEXAMPLES OF RISKS I
External RisksMarketplace rapid development and abrupt change of directionGovernment regulatory changesIndustry new standardsCorporate strategy and priority changesDisasters such as fire, flood, earthquake, tsunami
Cost RisksCost overruns by project teams or subcontractors, vendorsScope creep, expansion and change that has not been managedPoor estimating or errors that result in unforeseen costsOverrun of budget and schedule
Schedule RisksInaccurate estimating, resulting in errorsIncreased effort to solve technical and operational problemsResource shortfallsLoss of staff to other higher priority projects
EXAMPLES OF RISKS IIEXAMPLES OF RISKS II
Operational RisksInadequate resolution of priorities or conflict.Failure to designate authority of key people.Insufficient communication lack of communication plan.Size of transaction volumes – too great or too small.Rollout and implementation risks – too much or too soon.
Technology RisksProblems with immature technology.Use of wrong tools.Software that is untested or fail to work properly.No requirement change management.Failure to understand or account for product complexity.Performance issues – poor response times, bugs, errors.
RISK MEASUREMENTRISK MEASUREMENT
RISK LIKEHOOD VALUE
Very unlikely to occur 1
Some what unlikely 2
Equal chance 3
Highly possible 4
Nearly certain 5
RISK SEVERITY VALUE
Minor impact on cost, schedule, etc. 1
Moderate impact 2
Significant impact 3
Very significant impact 4
Catastrophic, disastrous impact, failure 5
RISK CONTROLLABILITY VALUE
Avoidable 1
Highly controllable 2
Moderately controllable 3
Largely uncontrollable 4
Highly uncontrollable, failure 5
RISK MANAGEMENT PROCESSRISK MANAGEMENT PROCESS
• Identifying the risks
• Determining the scope of risks
• Assigning persons in charge
• Monitoring risk list constantly(insert, update, delete)
• Developing a contingency plan, which can be initiated when a risk is threatening or a risk event occurs, like insurance which you may never need them.
• Keep upper management informed of the high risk list.
RISK MANAGEMENT DOCUMENTRISK MANAGEMENT DOCUMENT
No DescriptionLast Update
Date
Severity
Likeliho
od
SUM
Control
Level Status Person in Charge Contingency Plan
1 Order entry system not delivered on time
8/12/2002 4 5 9 5 Change request pending
James Laurence
Build bridge to existing system
2 Skilled personnel having earlier leaving date
5/15/2002 2 4 6 3 Complete
Skilled personnel has decided not to leave
Amy Wu Hire experienced personnel
3 User training for new billing system not complete
8/12/2002 3 3 6 2 In process Eric Johnson Use external experts to do jumpstart training
Sample Risk Tracking Document