BTS330: Business Requirements Analysis using OO Lecture 5: The Importance of Stakeholders.

Slides:



Advertisements
Similar presentations
Building Customer Relationships Through Effective Marketing
Advertisements

Workbook 1: Crafting Your Value Proposition Workbook Template
Inception: Starting a New Project Needs Features Vision.
Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Sponsored by the U.S. Department of Defense © 1998 by Carnegie Mellon.
Enterprise Systems.
1 Chapter 5: The F1ive Steps in Problem Analysis The five steps in problem analysis. Team Skill 1.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 1.Gain agreement on the problem definition. 2.Understand the root causes 3.Identify the.
Collecting and Reporting Accounting Information Design of an effective AIS begins by considering outputs from the system. Outputs of an AIS include: 1.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
Copyright 2004 Prentice Hall
LECTURE. FORMATION OF PRICE FOR THE COMPANIES PRODUCT Plan lectures 1. Price and types of prices 2. Classification prices 3. Pricing policy of the enterprise.
Waniwatining Astuti, M.T.I
Problem Analysis The goal of problem analysis is to gain a better understanding of the problem being solved before development begins Gain agreement on.
Product Management 1. The Product Champion  Nearly every successful project has a Product Champion who: Develops the Vision Document. Manages customer.
SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:
What is Business Analysis Planning & Monitoring?
Chapter 2 – Enterprise Systems
1 BTS330 Vision & Scope. 2 IT Projects What defines project success? On time Within budget Delivers what the clients want The reality Less than 20% of.
Gregor v. Bochmann, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher with material from: Wiegers: Software Requirements, Chapter 5.
Software Project Management Introduction to Project Management.
1 SYS366 Week 3 Lecture 1 Introduction to Requirements Gathering: Part 1.
1 SYS366 Week 10, Lecture 3 Systems Requirements Gathering: Identifying Operating Requirements.
BUSINESS PLUG-IN B15 Project Management.
Quality Control Project Management Unit Credit Value : 4 Essential
BTS330: Business Requirements Analysis using OO Discussion: Introduction to Business and the systems that support it.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Software Requirements Engineering: What, Why, Who, When, and How
This chapter is extracted from Sommerville’s slides. Text book chapter
BTS330: Business Requirements Analysis using OO Lecture 5: The Importance of Stakeholders.
Lecture: The Importance of Stakeholders.  Objective of the requirements capture and analysis phases is to understand business processes and develop requirements.
1 SYS366 Constraints: Business Rules. Constraints: The Grim Reality Developers are not given all the time in the world, all the money in the world, and.
Client/User Analysis Website Design. 2 Questions to be answered: What is the purpose of the site? What is the purpose of the site? Who is the site for?
Welcome to Session 3 – Project Management Process Overview
1 BTS330 Introduction to Stakeholders & Business Areas.
1 Identifying System Requirements. 2 Agenda Identifying System Requirements –Stakeholder Needs –Features Project Scope Stakeholder Classifications.
a guidance to conversion
1 SYS366 Week 4, Lecture 2 Requirements Part 4: Constraints, The Problem Statement.
Key terms & New product development
Systems Analysis and Design in a Changing World, 6th Edition
Concepts in Enterprise Resource Planning Fourth Edition
1 SYS366 Lecture Requirements Gathering: Stakeholders.
1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan.
Lecture: The Importance of Stakeholders SYS366. Identifying Requirements Objective of the requirements capture and analysis phases is to understand business.
Initiation Project Management Minder Chen, Ph.D. CSU Channel Islands
Team Skill 1 Analyzing the Problem
Problem Analysis 1. What is Problem Analysis?  The process of understanding real-world problems and user needs and proposing solutions to meet those.
IS2210: Systems Analysis and Systems Design and Change Twitter:
Introduction Complex and large SW. SW crises Expensive HW. Custom SW. Batch execution Structured programming Product SW.
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
1 Project Management C13PM Session 2 Project Initiation & Definition Russell Taylor Business Department Staff Workroom
UTA/ARRI. Enterprise Engineering for The Agile Enterprise Don Liles The University of Texas at Arlington.
1 BTS330 Visual Modeling. What is Visual Modeling? 2 Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
INTRODUCTION Mehmet Sait Andaç Web: Office: 431.
The Project Management Process Groups
1 BTS330 Week 4 - Lecture 1 Businesses and Business Processes.
CMMI Certification - By Global Certification Consultancy.
Q uality C oncepts. WHAT IS QUALITY ? ‘Quality’ is now a familiar word.  When most people talk about the quality of an object, or service, they are normally.
Analysis of the External Environment and Competition
1 Team Skill 1 Analyzing the Problem … Part 1: 5 steps in Problem Analysis Based on “Software Requirements Management, A use case approach”, by Leffingwell.
THE VALUE (SUPPLY) CHAIN STRETCHES FROM THE BEGINNING OF YOUR SUPPLIER’S SUPPLY CHAIN THROUGH ALL OF YOUR PROCESSES THAT CREATE VALUE FOR YOUR CUSTOMERS.
BUSINESS PLUG-IN B15 Project Management.
Chapter 5 – Requirements Engineering
Fundamentals of Information Systems, Sixth Edition
BANKING INFORMATION SYSTEMS
UNIT V QUALITY SYSTEMS.
Guidance notes for Project Manager
Project Management Process Groups
Introduction to Requirements Management
Presentation transcript:

BTS330: Business Requirements Analysis using OO Lecture 5: The Importance of Stakeholders

Agenda  Identifying System Requirements –Stakeholder Needs –Features  Project Scope  Stakeholder Classifications  Constraints

Identifying Requirements  Objective of the requirements capture and analysis phases is to understand business processes and develop requirements for the new system

Identifying System Requirements  “A requirement is a desired feature, property or behavior of a system.” * * Unified Modeling Language

Identifying System Requirements  A requirement “is either derived directly from stakeholder or user needs Or stated in a contract, standard, specification, or other formally imposed document.” * * Use Case Modeling, by Bittner & Spence, page 5.

Identifying System Requirements Stakeholder Need: A reflection of the business, personal or operational problem…that must be addressed to justify consideration, purchase or use of the new system. * * Use Case Modeling, by Bittner & Spence, page 72. * Use Case Modeling, by Bittner & Spence, page 5.

The Problem Statement  “If you want to satisfy [Stakeholders’] real needs, you must understand the problem that they are trying to solve.” * *Use Case Modeling by Bittner and Spence, page. 69.

Identifying System Requirements  Capturing stakeholder needs allows us to understand how and to what extent the different aspects of the problem affect different [categories] of stakeholders. * * Use Case Modeling, by Bittner & Spence, page 72.

Identifying System Requirements  Stakeholder needs are an expression of the true ‘business requirements’ of the system * * Use Case Modeling, by Bittner & Spence, page 72.

Identifying System Requirements  Features: –“Informal statements of capabilities of the system used often for marketing and product-positioning purposes as a shorthand for a set of behaviors of the system.” Use Case Modeling, by Bittner & Spence, pages

Identifying System Requirements  Features: –“The high-level capabilities (services or qualities) of the system that are necessary to deliver benefits to the users and that help to fulfill the stakeholders and user needs.” * * Use Case Modeling, by Bittner & Spence, page 74.

Identifying System Requirements “Features represent some area of functionality of the system that, at this time, is important to the users of the system” * * Use Case Modeling, by Bittner & Spence, page 75.

Identifying System Requirements “The immediate and informal nature of features makes them a very powerful tool when working with the stakeholders and customers in defining what they want from a system’s release.” * * Use Case Modeling, by Bittner & Spence, page 76.

Identifying System Requirements “Features provide the fundamental basis for product definition and scope management” * * Use Case Modeling, by Bittner & Spence, page 76.

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

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

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

Take orders via phone, fax, . Orders are from U.S. and Canada Payment by credit card only. Customers are companies, not individuals Report on orders for a given time frame ($ ordered, qty ordered, products ordered—most/least popular) Sales Sales People Packaging & Shipping Shippers Orders picked, packaged with packing slip, labeled with shipping address Shipping outsourced—use only UPS/Fedex (US) Shipping reports generated for a given timeframe Product Promotion Promotion Staff For new products: photograph, add product to database, create pricing Create quarterly product catalogue Maintain a list of potential customers Maintain actual customers with customer preferences. Manage ads—mailings, s, web??? Track competition Materials Purchasing Purchasers Manage Materials List Order Materials—create a PO (may be from a purchase requisition) Receive materials—receive against the PO. Generate quarterly reports—materials purchased and received, materials list. Production Potters Scheduled by production manager Create regular products Create and test new products and materials Use materials but don’t track them Updates production daily—what is in progress and what is completed. For completions, inventory of finished product is updated. Needs to be aware of daily orders Creates purchase requisition for materials on an as needed basis. Reports on and disposes of unused materials. Production Manager Planning Sales People Potters Meet each quarter to discuss: what products should be continued/discontinued; what products should be added; what the competition is doing; product pricing. Create a product list for next quarter Create a preliminary materials list for next quarter (based on products) Promotion Staff Production Manager GANDELF POTTERY & CERAMICS

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 Use Case Diagrams –Ask, “Is problem understood?”

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!

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

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

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

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

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.

Categories of Stakeholders  Five primary categories –Users –Sponsors –Developers –Authorities –Customers

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

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

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

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

Developer Stakeholders  Those involved in the production and maintenance

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

Customer Stakeholders  Those doing business with the company

Questions to Ask to Determine Stakeholders:  Who will be affected by the success or failure of the new solution?  Who are the users of the system?  Who is the economic buyer for the system?  Who is the sponsor of the development? * * Use Case Modeling, by Bittner & Spence, page 63.

Questions to Ask to Determine Stakeholders:  Who else will be affected by the outputs that the system produces?  Who will evaluate and sign off on the system when it is delivered and deployed?  Are there any other internal or external users of the system whose needs must be addressed? * * Use Case Modeling, by Bittner & Spence, page 63.

Questions to Ask to Determine Stakeholders:  Are there any regulatory bodies or standards organizations to which the system must comply?  Who will develop the system?  Who will install and maintain the new system?  Who will support and supply training for the new system?  Who will test and certify the new system? * * Use Case Modeling, by Bittner & Spence, pages

Questions to Ask to Determine Stakeholders:  Who will sell and market the new system?  Is there anyone else?  Okay, Is there anyone else? * * Use Case Modeling, by Bittner & Spence, page 64.

Constraints: The Grim Reality  Developers are not given all the time in the world, all the money in the world, and all the best resources that money can buy so that they can build the best system ever built!

Constraints  “ are restrictions on the degree of freedom the developers have in providing a solution….” *  come directly from the economic, technological, political, and business environment into which the system will be introduced * Use Case Modeling by Bittner and Spence, page. 16.

More Reasons to Involve Stakeholders and Users  “…you must understand the economic, technological, political, and business environment into which the system will be introduced and how that environment will be changed by the new system.” * * Use Case Modeling by Bittner and Spence, page. 15.

Stakeholders & Users are the ones who can tell you the economic, technological, political, and business environment into which the system will be introduced and how that environment will be changed by the new system.

Constraints  “Constraints are not related to the fulfilling the stakeholders’ needs; they are restrictions imposed on the project by external forces.” Use Case Modeling by Bittner and Spence, page. 77.

Constraints Include Business and Economic: Cost and pricing, availability, marketing and licensing issues Use Case Modeling by Bittner and Spence, page. 77.

Constraints Include Environmental: External standards and regulations that are imposed on the development project Use Case Modeling by Bittner and Spence, page. 78.

Constraints Include Technical: The technologies that the project is forced to adopt or the processes that the project has to follow Use Case Modeling by Bittner and Spence, page. 78.

Constraints Include System: Compatibility with existing systems and operating environments Use Case Modeling by Bittner and Spence, page. 78.

Constraints Include Schedule and Resources: Dates the project has been committed to or limitations on the resources that the project must use Use Case Modeling by Bittner and Spence, page. 78.

Why Stakeholders Impose Constraints Politics Constraints my be placed on the project by the relationships among the stakeholders rather than the technical or business forces shaping the project Use Case Modeling by Bittner and Spence, page. 78.

Why Stakeholders Impose Constraints Organizational Policies may be in place that constrain the way that the product can be developed. A company may have made a policy decision to move toward specific techniques, methodologies, standards, or languages Use Case Modeling by Bittner and Spence, page. 78.

Why Stakeholders Impose Constraints Strategic Directions may be in place that constrain the way that the project is to use specific technologies and suppliers (such as the decision by the Dealer Principal to outsource all IT to your company) Use Case Modeling by Bittner and Spence, page. 78.

Why Stakeholders Impose Constraints Organizational Culture may itself constrain the project by limiting the way that the project must address the project must address the problem. (There is a limit to the amount of change that people can cope with at any one time.) Use Case Modeling by Bittner and Spence, page. 78.

Constraints  Constraints = Reality Checks!