The Life Cycle of A Large System Integration

The Life Cycle of A Large System Integration Project 4. REQUIREMENT (SCOPE) & RISK MANAGEMENT

TYPES OF SOFTWARE APPLICATIONS Information System Developed 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 Products This 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 MANAGEMENT IN PROJECT LIFECYCLE Requirement Planning Requirement Management 2 yr 2 mo 12 mo M 6 Delivery End Operation Backup ACTUAL: Total of 30 months M 5 Testing Delivery M 4 Implementation 3 mo 1 mo Acceptance M 3 Design 5 mo Installation And Testing M 2 Analysis 3 mo Implementation Design Requirement PPP Plans Presale M 1 Planning 2 mo

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) 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) • What if the store fills the order according to the first tailor? • What if the store fills the order according to the second tailor? 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.

HIGH COST OF REQUIREMENTS ERRORS STAGE 0. 1 – 0. 2 Requirement 0. 5 Design 1 Coding 2 Unit test 5 Acceptance 20 Maintenance Relative Cost to Repair

COST OF ERRORS What user sees, normalized To 1 Defect Origins Requirements Design Coding Documentation Others Total Average manpower for a defect Delivered Defects Average Cost per Defect 0. 32 0. 27 0. 14 0. 12 0. 15 1 136 70 30 5 10 NA Defect Summary A requirement defect may involve multiple changes in multiple design

COST ASSOCIATE WITH A DEFECT BEFORE OPERATION Average manpower (man/hour) per defect Custome r sign off Design Coding Unit Test Regression Test Internal Doc 12 6 8 4 19 18 8 11 8 6 28 28 14 18 13 10 Coding Design Requir ement 12 User Doc Other TOTAL 30 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. 70 13 136

PROJECT WORKFLOW & REQUIREMENTS CHANGE New Req Airport Scale • Flight/year • Passengers/year Business Objectives • Revenu • Service quality Business Model New Req Operation Model，Service， Rule, Inter-operation Requirements Computerize Organization Operation flow

EXAMPLE OF REQUIREMENT CHANGE AT LATE STAGE CODE 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) Requirement types Hardware requirements Software requirements Functional requirements Design constraints Nonfunctional requirements

SOFTWARE REQUIREMENTS Software Functional requirements Software Nonfunctional requirements Design constraints How to operate and how the system behaves and data associated Usability: be more specific and measurable Reliability: Availability, Mean time between failure (MTBF), Mean time to repair (MTTR) Accuracy Maximum bugs or defect rate Bugs per type (minor, significant, or critical) Performance: Response time Throughput: transaction per second Capacity: number of customers or transactions 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 REQUIREMENTS Business Objectives Business Model • Revenue • Service quality • Flight/pear • Passengers/year Operation Model Service, Management, Rule, Inter-operation with subsystems Industry Standard Requirements Non-functional Computerize

TEMPLATE OF SRS (1) 1. OVERVIEW 2. 3 Inputs and Outputs Introduction to the system to be built Give inputs and outputs for each business event 1. 1 2. 4 Current System Relationships Brief description of the current system if a system exists Specify relationship between inputs and outputs 1. 2 2. 5 Limitations of the Current System Precedence Relationships List of limitations of the current system Specify any precedence relationship between events 1. 3 2. 6 Screens 3. EXTERNAL INTERFACE REQUIREMENTS Proposed System Overview of the proposed system 1. 3. 1 Objectives of the Proposed System 2. FUNCTIONAL REQUIREMENTS List of requirement related to the customer’s business 2. 1. 2 2. 2. 1 System Requirements Scope and Boundary Context Diagram Business Events External Events List of external events are triggered by external entities, such as a client calling to place an order or a user entering a command. 2. 2. 2 Temporal Events List of temporal events, which are triggered by time, e. g. , producing a summary report every day at 9: 00 PM The system being developed might interface with many other existing automated 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 is Involved, separate documents shall be generated. 4. 4. 1 4. 2 4. 3 4. 4 OPERATING ENVIRONMENT REQUIREMENTS Hardware Software Network Communication

TEMPLATE OF SRS (2) 5. PERFORMANCE REQUIREMENTS All performance requirements are specified here. Examples include 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 REQUIREMENTS All standards that the customer requires to be followed during project should be listed here. The actual standards can be listed in a separate documents. 6. 1 6. 2 6. 3 6. 4 User Interface Detailed Design Coding Documentation SPECIAL USER REQUIREMENTS 7. 1 Security 7. 2 Audit Trail 7. 3 Reliability 7. 4 7. 5 7. 6 7. 7 7. 8 7. 9 7. 10 7. 11 7. 12 7. 13 Transaction Volume and Data Volumes Backup and Recovery Legal Data Migration Data Retention Installation User Training User Manual and Help Automated and Manual Function Features Not Required 9. CONSTANTS 10. PROTOTYPES 11. GLOSSARY OF TERMS & ACRONYMS

WHAT TO AVOID IN SRS Exclude Project Information: Schedule, Project plan, Staffing, Configuration management Budget Test 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.

PROJECT Write a SRS (Software Requirement Specification for a GLUCOSE TEST DEVICE 2 persons per group

PROJECT a -- GLUCOSE TEST DEVICE -Test Strip Beeper AC Error Battery User E ~ A Unit Test Result L 07/11/01 15: 30 Progressive Bar Date Two Buttons Date Time Glucometer USB AC plug-in

PROJECT b Hardware Components Sensor, A/D USB Power Supplier Buttons Processor Beeper Memory Display

PROJECT c -- GLUCOSE TEST DEVICE -Test Procedure 1. 2. Insert a test strip (power on) The system is initialized 3. Select user A or B 4. Feed the strip tip with blood sample (error if the amount is insufficient) After 30 second, the test result is displayed Pull out the strip and throw it away The system will shut down by itself 15 seconds after no button push 5. 6. 7. Beeper A beeper is equipped for giving user warnings and/or reminders USB User may upload test record history to PC AC Plug The device is powered by battery or AC adaptor Other Requirements Functions of Devices Screen As 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. • The device should operated between -10 C to 45 C • The interface should be easy to use.

PROJECT d -- GLUCOSE TEST DEVICE -- Presentation Schedule 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

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) Correct Requirements An 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. ” User needs A B C SRS Needs/requirements universe

NINE QUALITY MEASURES (2) Unambiguous Requirements An requirement is unambiguous iff it can be subject to only one interpretation. (IEEE 830 -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) Completeness of the Requirements Set A set of requirements is internally consistent iff no subsets of the requirement set are conflict with one another. (IEEE 8301993 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 Set An requirement is unambiguous iff it can be subject to only one interpretation. (IEEE 830 -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) Requirements Ranked for Importance and Stability The users, developers and other stakeholders have ranked the requirements by importance to the customer in terms of stability. (IEEE 830 -1993 4. 3. 5, 1994) Importance and stability are likely associated with user’s perception of the world. Verifiable Requirements A requirement is verifiable iff there exists a finite and costeffective process with which a person or a machine can test or prove. (IEEE 830 -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) Modifiable Requirements Set A requirement set is modifiable iff its structure and style allow changes to be made easily, completely and consistently, while retaining its structure and style. . (IEEE 830 -1993 4. 3. 7, 1994) The requirement set should have minimum redundancy with a proper table of contents, index, and cross referencing capabilities. Traceable Requirements A 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. (IEEE 830 -1993 4. 3. 8, 1994) Understandable Requirements Both 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) Traceability Matrix Plan Gather/Elicit Change Control Analysis Sign-off SRS Review Design Test Cases

PROCESS FOR REQUIREMENTS (2) Prepare for gathering & analysis • • Do background reading on technical/business concepts and undergo training Become familiar with customer’s methodology and tools to be used Gather requirements Identify user groups and interviewees Define requirement specification standards • Establish objective Prepare questionnaires for eliciting informationand scope of the system • Gather functional requirements Plan prototype Identify business events Identify methods for information gathering Identify inputs and Develop interview plan and review with customer outputs for each business event Determine relationship between inputs and outputs Determine 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 Log the changes Impact analysis Estimate effort Price negotiation Review impact with seniors Estimate schedule Obtain Sign-off from customer

REQUIREMENTS CHANGE TRACEABILITY Req# Date 1. 1. 2 4/3/20 05 Description Connect subsystems using multithread HLD doc Ref# 4. 3. 2 Functions Changes One subsystem at a time E eliminated C cancelled M modified New Reqmt# Unit test case Integrat ion test case #1 #11 New # Two/three subsystems #12 #47 Traceability Matrix Valuable information for impact analysis when requirements change To maintain a good and usable matrix, the following points should be followed: • • • Accep -tance test case 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. Note that other attributes, such as risk, cost, difficulty could be enormously useful. #11

CONCLUSION 1. Requirements errors are likely to be the most common class of errors 2. Requirements errors are likely to be the most expensive errors to fix at the later stage of the project 3. Requirement management should cover the lifecycle of a software project

RISK 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 LIFECYCLE Risk Management 2 yr 2 mo 12 mo 5 mo M 5 Delivery End Operation Backup ACTUAL: Total of 30 months M 4 Installation Delivery M 3 High Level Design 3 mo 1 mo Acceptance Installation And Testing M 2 Requirement 3 mo Implementation Design Requirement PPP Plans Presale M 1 Planning 2 mo

TYPE OF RISKS External Risks Outside the control of the program/project manager and, in most cases, the corporation. Cost Risks Many of these risks are directly or indirectly under the control program/project managers. Schedule Risks Missing or delaying a market opportunity for a product or service. Technology Risks Failure to meet systems target functionality or performance expectations. Operational Risks Such 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.

EXAMPLES OF RISKS I External Risks Marketplace rapid development and abrupt change of direction Government regulatory changes Industry new standards Corporate strategy and priority changes Disasters such as fire, flood, earthquake, tsunami Cost Risks Cost overruns by project teams or subcontractors, vendors Scope creep, expansion and change that has not been managed Poor estimating or errors that result in unforeseen costs Overrun of budget and schedule Schedule Risks Inaccurate estimating, resulting in errors Increased effort to solve technical and operational problems Resource shortfalls Loss of staff to other higher priority projects

EXAMPLES OF RISKS II Technology Risks Problems 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. Operational Risks Inadequate 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.

RISK 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 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 DOCUMENT Sample Risk Tracking Document No Description Severity Likelihood SUM Control Level 1 Order entry system not delivered on time 8/12/2002 4 5 9 5 Change request pending 2 Skilled personnel having earlier leaving date 5/15/2002 2 4 6 3 Complete Amy Wu Skilled personnel has decided not to leave Hire experienced personnel 3 User training for new billing system not complete 8/12/2002 3 3 6 2 In process Use external experts to do jumpstart training Last Update Date Status Person in Charge James Laurence Eric Johnson Contingency Plan Build bridge to existing system