Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 SYS366 Week 3 Lecture 1 Introduction to Requirements Gathering: Part 1.

Similar presentations


Presentation on theme: "1 SYS366 Week 3 Lecture 1 Introduction to Requirements Gathering: Part 1."— Presentation transcript:

1 1 SYS366 Week 3 Lecture 1 Introduction to Requirements Gathering: Part 1

2 2 Today Business Systems Projects Why do Projects Fail? The importance of Stakeholders

3 3 What is a system? A combination of hardware and software that meets the needs of a business. A collection of inter-related components that collect, process, store and provide as output the information needed to complete business tasks and to make business decisions.

4 4 Types of systems? Office Systems Productivity tools available to employees on a desk top. Electronic Mail, Word Processing, Database Management, Spreadsheets, Desktop Publishing, Presentation Graphics and so on.

5 5 Types of systems? Operational (Transaction Processing) Systems Take care of the day-to-day processing of the business Information about the transactions that affect the organization are captured and recorded

6 6 Types of systems? Management Information Systems Uses operational systems’ information to give management the information needed to make management decisions

7 7 Types of systems? Executive Information Systems Provide information to executives on how their company is doing relative to the industry

8 8 Types of systems? Decision Support Systems Systems that allow a user to explore the impact of available options or decisions ‘What if’ analysis

9 9 Types of systems? Expert Systems Simulate human reasoning and decision- making. Artificial Intelligence.

10 10 Types of Systems Information systems Collection of interrelated components that collect, process, store, and provide as output the information needed to complete business processes

11 11 Flow of Information Horizontally - information flows across departments Vertically - information needs of clerical staff, middle management, and senior executives

12 12 Information Systems IS Planning Level Type of planningTypical IS applications Organizational Unit Responsible for Developing StrategicStrategies in support of organizational long-term objectives Market and sales analysis, Product planning, Performance evaluation Senior Management/ Executives TacticalPolicies in support of short-term goals and resource allocation Budget analysis, Salary forecasting, Inventory scheduling, Customer service Middle Management OperationalDay-to-day staff activities and production support Payroll, Invoicing, Purchasing, Accounting Lower Management; Operational

13 13 Today Business Systems Projects Why do Projects Fail? The importance of Stakeholders

14 14 What is a Project? Sequence of unique, complex, connected activities having one goal and that must be completed by a specific time, within a specific budget and according to spec

15 15 Project Initiation: How are Projects Chosen? Long-term information systems strategic plan (top-down) Department managers or process managers (bottom-up) Response to outside forces Legislative changes Market forces Competition

16 16 Strategic Planning Strategic Planning involves determining long-term objectives by analyzing the strengths and weaknesses of an organization, studying opportunities and threats in the business environment, predicting future trends, and projecting the need for new products and services.

17 17 Strategic Plan Helps determine which projects go ahead

18 18 How do you get projects justified? Understand the relationship to the Strategic Plan Support from Stakeholders Understand and quantify hard & soft benefits Understand and calculate one-time and ongoing costs

19 19 Some IT Examples Software/system development Package implementation Selection of a turnkey solution Technology implementation Business process re-engineering Component assembly

20 20 Hard vs Soft Benefits Hard- quantifiable in terms of dollars Soft - Intangible

21 21 Justification based on benefit Cost Savings New Services to clients Mandatory changes Strategic advantage Technical reasons

22 22 Project Parameters Scope Quality--product and process Cost Time Resources Scope and Quality ARE DIRECTLY IMPACTED BY Cost, Time, Resources

23 23 What is project scope? A definition of the boundaries of the project

24 24 When do you define scope? You define scope at the beginning of the project You manage and control scope throughout the life of the project

25 25 How do you define scope? You talk to your stakeholders!

26 26 How do you define scope? In addition to talking to your stakeholders!, You research and clarify You document Identify expected capabilities of new system Develop Business Use Case Diagrams Develop textual Business Use Case descriptions Ask, “Is problem understood?”

27 27 Today Business Systems Projects Why do Projects Fail? The importance of Stakeholders

28 28 Why is scope important? One of the biggest factors in project success Good scope definition = good client and IT understanding of what will be delivered and when Ensures you understand WHERE you are going, HOW you will get there and WHEN you will arrive This is where most projects start to fail!

29 29 What defines project success? On time Within budget Expected results achieved

30 30 The evil truth Only 16.2% of all IT projects succeed! Fully functional, on time, within budget Some studies show this as low as 10%.

31 31 The evil truth 52.7% are “challenged” --less than fully functional, over budget, late The remaining 31.1% get cancelled before they are fully implemented

32 32 The evil truth Estimated cost of challenged and cancelled projects in 1 year? $140 billion

33 33 More evil truth The average project: exceeds planned budget by 90% exceeds schedule by 120% How to estimate: take your best, most honest guess multiply that by 4

34 34 Why do projects fail? Objectives not fully specified (51%) Poor planning/estimating (48%) New technology (45%) Poor or no project management discipline (42%) Inadequate skills (42%) and so on…

35 35 Today Business Systems Projects Why do Projects Fail? The importance of Stakeholders

36 36 To A Avoid Disaster “The team must Establish a good understanding of the stakeholder community Demonstrate an understanding of the problem to be solved…”* * Use Case Modeling by Bittner and Spence, p. 50.

37 37 To A Avoid Disaster “The team must Capture the real needs of the stakeholders and the system features required to fulfill them Ensure that the views of the stakeholder community are actively and appropriately represented throughout the project” * * Use Case Modeling by Bittner and Spence, p. 50.

38 38 Who is a Stakeholder? “An individual who is materially affected by the outcome of the system or the project (s) producing the system” * Or the people who suffer from the problem being addressed * * Use Case Modeling by Bittner and Spence, p. 51.

39 39 Categories of Stakeholders Five primary categories Users Sponsors Developers Authorities Customers

40 40 User Stakeholders Those who actually use the system Technology Adopters Interested in using all of the features of the system; in pushing it to the limit of its capabilities Standard Users Not interested in using all of the features of the system. Rather they want a system that allows them to perform their business processes simply and in the same way that they are used to performing them

41 41 Standard Users Those in day-to-day business operations use and change information Those using queries view calculated/collected information Management use reports, statistics demand controls Executives strategic issues

42 42 User Stakeholders Non-human users Mechanical devices that the system must interact with Other business areas Other systems

43 43 Sponsor Stakeholders Indirect users Or those actually paying for the development of the system Or those affected only by the business outcomes that the system influences

44 44 Developer Stakeholders Those involved in the production and maintenance

45 45 Authority Stakeholders Those who are expert in a particular aspect of the problem or solution domain Ministries Technical experts Domain experts

46 46 Customer Stakeholders Those doing business with the company

47 47 Over to You Let’s get started on Work Package 1 In-Class Exercise 5


Download ppt "1 SYS366 Week 3 Lecture 1 Introduction to Requirements Gathering: Part 1."

Similar presentations


Ads by Google