The Systems Proposal What the book calls the “Updated Baseline Project Plan” - no standard name for it Presents the different options to the customer along with all the information they will need to make a decision Deliverable 3 - must present at least three significantly different alternatives, one of which is the recommended solution

The Systems Proposal (cont.) Introduction –Project Overview - updated, summarized version of the organizational description, the problem statement, and the scope statement –Recommendation - brief description of the recommended solution and why it is more feasible than the alternatives (summary of feasibility analysis)

The Systems Proposal (cont.) System Description –Major requirements and constraints - a prioritized list of 6-10 high-level requirements and constraints (distinguish between the two) that will be used as a basis of comparison among alternatives –Brief technical descriptions of the three alternatives –Proposed DFDs for all three alternatives –Comparison of alternatives in terms of requirements and constraints

The Systems Proposal (cont.) Feasibility assessment –Address each of the six types of feasibility for each alternative solution –For some feasibility types, the analysis may be the same for all three alternatives –Some analyses may be repeated from Deliverable 1 –Economic feasibility analysis must be much more detailed than in Deliverable 1

Generating Alternatives Must have three significantly different alternative solutions All 3 must involve some change from the current situation Consider: –non-technical solutions –partial solutions –low-end and high-end solutions

Requirements Document An idea from software engineering Another way to structure requirements A statement specifying what a proposed system is required to do Often structured as a list of numbered requirements, in textual form Details the what, not the how

Requirements Documents (cont.) What makes a good requirements document? -completeness -consistency -clarity -correctness -level of detail -testability -understandability

Purposes Contract between system vendor and customer Communication with customer Starting point for design Guide for testing Comparing alternatives

Types of requirements Functional Requirements Data Requirements Look and Feel requirements Usability requirements Performance Requirements Operational requirements Maintainability requirements Security requirements

Examples of requirements Functional requirements: When a customer applies for a video rental card by providing customer information and a means of verifying their identity, the system issues a video rental card. When a customer rents videos by providing their video rental card and the videocassettes they are renting, the system calculates the amount due from the customer (including late fees), record receipt of the amount, print a customer receipt, and make a record of each item rented. When a customer returns a video, the system records the return and notes any late fees on the customer record. If a customer returns a movie 1-5 days late, the late charge is equal to an additional rental for each day it is late. If the customer has outstanding late fees, they are not permitted to rent another video until the late fees are paid.

Examples of requirements Data requirements: The information maintained about customers includes customer id number, customer last name, address, telephone number, major credit card number and expiration date, and information on outstanding late fees The information maintained about videos includes a video id number, title, year, class (which determines rental rate) and copy number The information maintained about rentals includes the customer id, the video id, the date rented, the date returned, and the amount charged

Examples of requirements Look and Feel requirements: The user interface must conform to the conventions of the Microsoft Office products interface. The XYZ company logo must appear in the upper right corner of each screen. The fonts used on all printed output must be at least 14 points. The color purple must not be used in any screen output.

Examples of requirements Usability requirements: User training for video store clerks must not exceed 30 minutes. User training for video store managers must not exceed 2 hours. Error rates among trained users must not exceed 1 data entry error in 4 hours. On-line help must be provided and must be able to answer any questions a user has during use after training.

Examples of requirements Performance requirements: Average time to complete a customer application process must not exceed 10 minutes. Average time to complete a video rental transaction must not exceed 3 minutes. The system must be able to handle at least 2000 customers, 5000 video rental items, and 300 video rentals per day with no noticeable degradation in performance.

Examples of requirements Operational requirements: The system must run using PC-compatible hardware running the Windows 95 operating system. The system must successfully network up to 8 PC’s with full data-sharing capabilities.

Examples of requirements Maintainability requirements: A trained video store manager, with no additional training or background, must be able to change the rental rates used for different classes of videos. An enhancement to the system to allow it to handle more than one type of rental item (e.g. DVD) should cost (in terms of both time and money) no more than 10% of the original system development cost.

Examples of requirements Security requirements: The system must be password protected, allowing only video store employees to access any part of the system, and only managers to modify video information.

Assessing Feasibility Technical – is technology available or are we able to develop it? Economic – do we have the time and money? Operational - will it work? Schedule – can it be done in the given time? Legal and contractual - are we allowed to do this? Political – is anyone trying to undermine this project?

Operational Feasibility Will it work with current systems? Will it be accepted by users? Will it solve real problems?

Analysis Design Implementation Information Gathering Data, Logic, and Process Modeling Systems Proposal Preparation Data Entry Design Screen and Report Design Data Organization Process Design Integration Testing Work Breakdown - level 1

Information Gathering Data, Logic, and Process Modeling Systems Proposal Preparation Conduct Interviews Administer Questionnaires Introduce Prototype Observe Reactions to Prototype Data Modeling Logic Modeling Process Modeling Perform Cost/Benefit Analysis Prepare Proposal Present Proposal Work Breakdown - level 2

Conduct Interviews Administer Questionnaires Choose interviewees1 Develop interview guide2 Schedule interviews3 Conduct interviews10 Transcribe notes5 Design questionnaire5 Review questionnaire5 Distribute questionnaire1 Wait for responses10 Compile responses5 Introduce Prototype Observe Reactions to Prototype Build prototype5 Install prototype2 Observe prototype use5 Summarize recommendations2 Detailed Activity Days Required Work Breakdown - level 3

Choose interviewees Develop interview guide Schedule interviews Conduct interviews Transcribe notes Design questionnaire Review questionnaire Distribute questionnaire Wait for responses Compile responses Build prototype Install prototype Observe prototype use Summarize recommendations Activity Days 40 Gantt Chart

PERT Chart

Economic Feasibility Analysis For each alternative: identify tangible, intangible, one-time and recurring costs and benefits present and explain estimates for all tangible costs and benefits –use risk reduction and present value calculations if appropriate compare costs and benefits using break- even analysis

Cost/Benefit Analysis Risk reduction –use when one of the major benefits of the new system is to reduce the chance of some risk event or to reduce the loss from such an event Cash-flow analysis –use when justifying a large up-front cost that will be paid out of operating funds Present value –use when considering long-term costs and/or benefits Break-even analysis –use when there are significant tangible benefits expected from the new system

Quantifying Risk Reduction Risk reduction is often hard to quantify Customer needs to know how much they’re paying for risk reduction Can use the concept of utility loss to quantify the concept Utility loss is the product of: –the probability of the risk event occurring –the cost to the organization of the risk event occurring

Quantifying Risk Reduction Example Suppose: –The major benefit of the new system is that it reduces the risk from some event (e.g. a lawsuit) occurring –If this event happens, it will cost the organization about $2,000,000 (this is an estimate) –The probability that this event will occur is currently 5%, reduced to 1% with the new system (another estimate) –Compare utility losses: Currently: (.05)*($2,000,000) = $100,000 New system: (.01)*($2,000,000) = $20,000 Savings: $80,000

Time Value of Money Basic idea: the value of a dollar cost (or benefit) depends on when that dollar is spent (or received) After calculating the dollar amounts of all tangible costs and benefits for each year, you must adjust the totals to calculate the NPV (net present value) of each year’s costs and benefits

Net Present Value (NPV) To calculate NPV, need: –total tangible costs and total tangible benefits for each year –discount rate Calculate PV for costs and for benefits for each year Add up PVs to get NPV of costs and NPV of benefits Overall NPV = (NPV of benefits) - (NPV of costs)

Break-even Scenario Suppose: –initial tangible costs, including new equipment, analysis, development, and training, are estimated to be $75,000. –Recurring operational costs, including system maintenance and training for new users, is estimated at $5000 per year. –Tangible benefits, in the form of decreased costs, are estimated to be $25,000 per year.

Break-even Scenario (cont.) Years $ 25,000 50,000 75, ,000 Break-even point Costs Benefits