4. REQUIREMENT (SCOPE) & RISK MANAGEMENT

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

2. 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.

3. Requirement Planning Requirement Management 2 yr 2 mo 12 mo 2 mo 3 mo 5 mo 3 mo 1 mo Presale PPP Plans Requirement Design Implementation Installation And Testing Acceptance Delivery End Operation Backup ACTUAL: Total of 30 months M1 Planning M2 Analysis M3 Design M4 Implementation M5 Testing M6 Delivery REQUIREMENTS MANAGEMENTIN PROJECT LIFECYCLE

4. 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. WHY REQUIREMENT (1) 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.

5. 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 !

6. 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.

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

8. COST OF ERRORS What user sees, normalized To 1 Average manpower for a defect Defect Summary A requirement defect may involve multiple changes in multiple design

9. COST ASSOCIATE WITH A DEFECT BEFORE OPERATION Average manpower (man/hour) per defect • 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.

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

11. EXAMPLE OF REQUIREMENT CHANGEAT 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.

12. TYPES OF REQUIREMENTS (1) Requirement types Hardware requirements Software requirements Design constraints Functional requirements Nonfunctional requirements

13. SOFTWARE REQUIREMENTS Software Functional requirements How to operate and how the system behaves and data associated Software Nonfunctional requirements 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 Design constraints Impose limitation on the design of the system, when the developer normally has his/her choice, e.g., use ORACLE RDBMS, use VB, …

14. SOURCE OF REQUIREMENTS • Business Objectives • Revenue • Service quality • Flight/pear • Passengers/year Business Model Operation Model Service,Management,Rule, Inter-operation with subsystems Industry Standard Requirements Non-functional Computerize

15. TEMPLATE OF SRS (1) 1. OVERVIEW Introduction to the system to be built 1.1 Current System Brief description of the current system if a system exists 1.2 Limitations of the Current System List of limitations of the current system 1.3 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 System Requirements 2.2.1 Scope and Boundary 2.1.2 Context Diagram 2.2 Business Events 2.2.1 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:00PM 2.3 Inputs and Outputs Give inputs and outputs for each business event 2.4 Relationships Specify relationship between inputs and outputs 2.5 Precedence Relationships Specify any precedence relationship between events 2.6 Screens 3. EXTERNAL INTERFACE REQUIREMENTS 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. OPERATING ENVIRONMENT REQUIREMENTS 4.1 Hardware 4.2 Software 4.3 Network 4.4 Communication

16. 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 User Interface • 6.2 Detailed Design • 6.3 Coding • 6.4 Documentation • SPECIAL USER REQUIREMENTS • 7.1 Security • 7.2 Audit Trail • 7.3 Reliability • 7.4 Transaction Volume and Data Volumes • 7.5 Backup and Recovery • 7.6 Legal • 7.7 Data Migration • 7.8 Data Retention • 7.9 Installation • 7.10 User Training • 7.11 User Manual and Help • 7.12 Automated and Manual Function • 7.13 Features Not Required • 9. CONSTANTS • 10. PROTOTYPES • 11. GLOSSARY OF TERMS & ACRONYMS

17. 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.

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

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

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

21. -- GLUCOSE TEST DEVICE -- PROJECT c • Test Procedure • Insert a test strip (power on) • The system is initialized • Select user A or B • 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 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 • The device should operated between -10 C to 45 C • The interface should be easy to use. 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.

22. PROJECT d -- GLUCOSE TEST DEVICE -- Presentation The SRS Schedule

23. NINE QUALITY MEASURES (1) • Correct • Unambiguous • Complete • Consistent • Ranked for importance and stability • Verifiable • Modifiable • Traceable • Understandable

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

25. Unambiguous Requirements An 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 NINE QUALITY MEASURES (2) • 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

26. Completeness of the Requirements Set A 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? NINE QUALITY MEASURES (3) Consistency in the Requirements Set An 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.

27. 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. (IEEE830-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 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.”

28. 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.. (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 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. (IEEE830-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.

29. Traceability Matrix Gather/Elicit Change Control Design Test Cases Analysis Sign-off SRS Review PROCESS FOR REQUIREMENTS (1) Plan

30. PROCESS FOR REQUIREMENTS (2) • Prepare 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 requirements • Establish objective and scope of the system • Gather functional requirements • Identify business events • Identify inputs and 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

31. REQUIREMENT CHANGE CONTROL Log the changes Impact analysis Estimate effort Price negotiation Review impact with seniors Estimate schedule Obtain Sign-off from customer

32. REQUIREMENTS CHANGE TRACEABILITY • Traceability Matrix • Valuable 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. Note that other attributes, such as risk, cost, difficulty could be enormously useful.

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

34. 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.

35. Risk Management 2 yr 2 mo 12 mo 2 mo 3 mo 5 mo 3 mo 1 mo Presale PPP Plans Requirement Design Implementation Installation And Testing Acceptance Delivery End Operation Backup M1 Planning M2 Requirement M3 High Level Design M4 Installation M5 Delivery ACTUAL: Total of 30 months RISK MANAGEMENT IN PROJECT LIFECYCLE

36. 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.

37. 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

38. 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.

39. RISK MEASUREMENT

40. 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.

41. RISK MANAGEMENT DOCUMENT Sample Risk Tracking Document