1 Identifying System Requirements. 2 Agenda Identifying System Requirements –Stakeholder Needs –Features Project Scope Stakeholder Classifications.

Slides:



Advertisements
Similar presentations
Inception: Starting a New Project Needs Features Vision.
Advertisements

Chapter 5 Buying business services. Program The increasing importance of services Differences between goods and services A classification of services.
1 Chapter 5: The F1ive Steps in Problem Analysis The five steps in problem analysis. Team Skill 1.
Requirements - Why What and How? Sriram Mohan. Outline Why ? What ? How ?
Software Requirements
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.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
ISO 9001 Interpretation : Exclusions
CHAPTER 9: LEARNING OUTCOMES
Waniwatining Astuti, M.T.I
Chistyakova Nataly O.. Project stakeholders The client is the principal party interested in the carrying out of a project and in its successful outcome.
Problem Analysis The goal of problem analysis is to gain a better understanding of the problem being solved before development begins Gain agreement on.
SYS366 Week 3, Lecture 2 Introduction to Requirements Gathering:
Project Management Lecture 5+6 MS Saba Sahar.
Chapter 4 Requirements Engineering
S/W Project Management
Capability Assessment Process
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.
Chapter 2 Introduction to Requirements Management
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Software Project Management Introduction to Project Management.
1 SYS366 Week 3 Lecture 1 Introduction to Requirements Gathering: Part 1.
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
1 SYS366 Week 10, Lecture 3 Systems Requirements Gathering: Identifying Operating Requirements.
المحاضرة الثالثة. Software Requirements Topics covered Functional and non-functional requirements User requirements System requirements Interface specification.
Module CC3002 Post Implementation Issues Lecture for Week 1 AY 2013 Spring.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
BUSINESS PLUG-IN B15 Project Management.
Quality Control Project Management Unit Credit Value : 4 Essential
Systems Development AIMS 2710 R. Nakatsu. Overview Why do IT projects succeed and fail? Two philosophies of systems development –Systems Development Life.
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
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.
Lecture 7: Requirements Engineering
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
1 BTS330 Introduction to Stakeholders & Business Areas.
1 SYS366 Week 4, Lecture 2 Requirements Part 4: Constraints, The Problem Statement.
Microsoft Office Project 2003: Selling EPM in your Organization Matt Wilson Business Solutions Specialist LMR Solutions.
REQUIREMENTS - WHY WHAT AND HOW? Steve Chenoweth & Chandan Rupakheti CSSE 371 Chapters Requirements Text. Question 6.
Software Requirements and Design Khalid Ishaq
1 SYS366 Lecture Requirements Gathering: Stakeholders.
By Germaine Cheung Hong Kong Computer Institute
1 Team Skill 1 - Analyzing the Problem Continued and Product Features and Challenges Sriram Mohan.
Requirements Management with Use Cases Module 3: Analyze the Problem Requirements Management with Use Cases Module 3: Analyze the Problem.
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
Software Engineering Lecture # 1.
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:
Requirements engineering The process of establishing the services that the customer requires from a system and the constraints under which it operates.
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
1 Version /05/2004 © 2004 Robert Oshana Requirements Engineering Analyzing the Problem.
BTS330: Business Requirements Analysis using OO Lecture 5: The Importance of Stakeholders.
1 Home Care Support Outcome Based Specification Workshop 26 th November 2009.
LECTURE 5 Nangwonvuma M/ Byansi D. Components, interfaces and integration Infrastructure, Middleware and Platforms Techniques – Data warehouses, extending.
1 BTS330 Week 4 - Lecture 1 Businesses and Business Processes.
1 Software Requirements Descriptions and specifications of a system.
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.

Project Quality Management
BUSINESS PLUG-IN B15 Project Management.
Chapter 5 – Requirements Engineering
BANKING INFORMATION SYSTEMS
Chapter 4 Systems Planning and Selection
Requirements Engineering Introduction
Project Management Process Groups
Introduction to Requirements Management
Presentation transcript:

1 Identifying System Requirements

2 Agenda Identifying System Requirements –Stakeholder Needs –Features Project Scope Stakeholder Classifications

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

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

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

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

7 Identifying System Requirements “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.

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

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

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

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

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

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

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

15 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

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

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

18 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!

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

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

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

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

23 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

24 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

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

26 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

27 Sponsor Stakeholders Business Managers, investors Department heads “champions”

28 Developer Stakeholders Those involved in the production and maintenance

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

30 Customer Stakeholders Those doing business with the company

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

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

33 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

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