Quiz 1 Q1) Discuss briefly the main phases of the requirement process. Q2)Discuss briefly the main outcome of the Trawling for Requirements phase.

Slides:



Advertisements
Similar presentations
Chapter 2 Analyzing the Business Case.
Advertisements

1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
5/5/2015Software Engineering Code of Ethics1 Software Engineering Code of Ethics and Professional Practice Dr. Bob Weber CEG 460 / 660 Wright State University.
Chapter 10 Schedule Your Schedule. Copyright 2004 by Pearson Education, Inc. Identifying And Scheduling Tasks The schedule from the Software Development.
Chapter 3 Project Initiation
Project Plans CSCI102 - Systems ITCS905 - Systems MCS Systems.
University of Toronto at Scarborough © Kersti Wain-Bantin CSCC40 feasibility 1 why address feasibility? to answer the questions... can the project be done.
Software Requirements The Volere Requirements Source: “Mastering the Requirements Process”, S. Robertson, J. Robertson Created by Eshcar Hilel.
Chapter 4 After Green Light. After the Green Light Contractual Agreement Marketing Requirements Document (MRD) Project DefinitionBudget Project Approval.
Chapter 3 Project Initiation. The stages of a project  Project concept  Project proposal request  Project proposal  Project green light  Project.
The Agile vs. Waterfall Methodologies Systems Development:  the activity of creating new or modifying / enhancing existing business systems.  Objectives.
Acquiring Information Systems and Applications
Software Evolution Planning CIS 376 Bruce R. Maxim UM-Dearborn.
SYSTEM ANALYSIS AND DESIGN
Initiating and Planning Systems Development projects
Systems Analysis and Design with UML Version 2
1 Requirements Analysis and Design Engineering Southern Methodist University CSE 7313.
S/W Project Management
© The McGraw-Hill Companies, An Introduction Chapter 1 Software Project Management 4 th Edition Robert Hughes and Mike Cotterell.
4-1 Lesson 4 Technology: Resources and Implementation.
1 Phases in Software Development Lecture Software Development Lifecycle Let us review the main steps –Problem Definition –Feasibility Study –Analysis.
Feasibility Study.
1.  Project: temporary endeavor to achieve some specific objectives in a defined time  Project management ◦ Dynamic process ◦ Controlled and structured.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Lecture 4 1 Introduction to Systems Planning Lecture 4 2 Objectives n Describe the strategic planning process n Explain the purpose of a mission statement.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Chapter 12: Systems Investigation and Analysis. Agenda  How to Develop a CBIS?  Systems Development Life Cycle (SDLC)  Prototyping  Join Application.
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.
1 CS 426 Senior Projects Chapter 3: The Requirements Workflow [Arlow & Neustadt, 2005] January 31, 2012.
1 Activities covered by project management Feasibility study Is project technically feasible and worthwhile from a business point of view? Planning Only.
Strong9 Consulting Services, LLC 1 PMI - SVC I-80 Breakfast Roundtable Monthly Meeting Thursday, October 12, :00 am – 9:00 am.
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
Acquiring Information Systems and Applications
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
Project Specification part 2 BTEC National. Project boundaries or scope The boundaries or scope of a project are what the project aims to achieve. The.
Applied Software Project Management
Inception Chapter 4 Applying UML and Patterns -Craig Larman.
12/10/15.  It is a Cross Life Cycle Activity (CLCA) that may be performed at any stage ◦ In fact, some part of it (e.g. risk analysis and management)
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Systems Development Life Cycle
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Project Management Starting out. What makes projects different to BAU (Business as Usual)?  Change - Projects are the means by which we introduce change.
1 Business Aspects of Software Engineering SWE 513.
第 11 組 MIS 報告. Phases of any information system ~ recognition of a business problem or opportunity ~ recognition of a business problem or opportunity.
Module 4: Systems Development Chapter 13: Investigation and Analysis.
What is project management?
Chapter 4: Project Management and Planning Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A. Hoffer.
Quick Recap.
Chapter 3: The Requirements Workflow [Arlow and Neustadt, 2005] CS 426 Senior Projects in Computer Science University of Nevada, Reno Department of Computer.
Software Engineering Lecture # 1.
Software Project Management
Software Requirements Engineering Session: 1 Topics: Chapters 1 – 3.
Writing the Requirements

C. What is a Feasibility report
Fundamentals of Information Systems, Sixth Edition
Systems Analysis and Design in a Changing World, 4th Edition
Principles of Information Systems Eighth Edition
CHAPTER ‘3’ Project Blastoff
The Systems Engineering Context
CS 641 – Requirements Engineering
CS 641 – Requirements Engineering
REKAYASA PERANGKAT LUNAK
CS 790M Project preparation (I)
Chapter 3: The Requirements Workflow
ELEC4011 Ethics & Electrical Engineering Practice Hugh Outhred
Chapter 4 Inception CS John Cole.
Project Management Concepts May 5th, 2016
CS 426 CS 791z Topics on Software Engineering
CS 426 CS 791z Topics on Software Engineering
Presentation transcript:

Quiz 1 Q1) Discuss briefly the main phases of the requirement process. Q2)Discuss briefly the main outcome of the Trawling for Requirements phase.

CHAPTER ‘3’ Project Blastoff Dr. Ahmad F. Shubita

Blastoff Deliverables Goal/ Purpose of the project – short, measurable statement The client – who is the product being built for? The customer – who is going to buy the product? The stakeholders – people with interest The users – who is going to operate the product? Constraints – design, time or money Names – terminology Scope of the work – boundaries of project/product Estimated costs – effort, money The risks – risk analysis

Project Blastoff Activities

IceBreaker – Case Study IceBreaker is a case study we’ll use to demonstrate the requirements process. It uses a variety of data to predict exactly when ice will form on roadways, and it uses these predictions to schedule trucks to treat the roads with deicing material (a salt compound) before the roads become dangerous. The IceBreaker case study uses subject matter knowledge from the many weather/ice forecasting and road de-icing systems, and other products produced by Vaisala (U.K.)

Aspects of a Goal Purpose – what does it do? Advantage – business advantage Measurement – how to measure ◦ Feasible – can product achieve measure? ◦ Achievable – can organization build?

Product Purpose Purpose: To accurately forecast freezing times and dispatch de-icing trucks. Advantage: To reduce road accidents by forecasting icy road conditions. Measurement: Accidents attributed to ice shall be no more than 15% of the total number of accidents during winter. Supporting Materials: Thornes, J.E., 1992: Cost- Effective Snow and Ice Control for the Nineties. …

Product Purpose Purpose: To save money on winter road maintenance costs. Advantage: Reduced de-icing and road maintenance costs. Measurement : The cost of de-icing shall be reduced by 25% of the current cost of road treatment, and damage to roads from ice shall be reduced by 50%.

Product Purpose Purpose : To reduce damage to the environment by unnecessary application of de-icing compounds. Measurement: The amount of de-icing chemicals needed to de-ice the council’s roads shall be reduced by 50% Supporting Materials: Thornes, J.E., Salt of the Earth. Surveyor Magazine …

Clients & Customers Client is the person who pays for the development. Customer is the person(s) that pay for the product once it is developed.

Who’s Paying for This? Know the client and your customer Know what they want Understand the customer’s problems Understand the client’s objectives Know what is acceptable and unacceptable to the client and customer

Users Persons who ultimately operate the product In-house products: people that work for your client External products: user & customer usually are the same person

Roles of Users What are the jobs of the people who might use your product? What other roles might people have? Where will people be when using your product? What are the nationalities of the people who might use your product? Are there organizations that might use your product? Other considerations: ◦ People with disabilities ◦ Non-readers ◦ People with reading glasses

Stakeholders & Consultants Management Business Subject Matter Developers Inspectors Legal Professional Bodies Public Opinion Government Special Interest Groups Technical Experts Cultural Interests Adjacent Systems

Requirements Constraints Solutions Constraints ◦ Allowable Designs ◦ Prepackaged Solutions – Commercial off-the-shelf applications ◦ Partner applications Project Constraints ◦ Financial constraints ◦ Time constraints

Naming Terminology is extremely important to a project Example: Weather Station – a collection of hardware capable of collecting and transmitting road temperature, air temperature, humidity and precipitation readings. Weather stations are installed in eight locations in Northumberland.

Setting The Scope Deciding how much work will be done. Should contain the product purpose and other constraints. Also should address the domains of interest is a subject matter area. Sets the Work Scope

Domains of interest – Case Study Roads Weather Scheduling Trucking

196/13/2016 The Role of Adjacent Systems The adjacent systems are those pieces of work that supply your work with information or that receive information and services from your work An adjacent system might be an organization, an individual, a computer system or some other piece of technology, or a combination of any of these.

206/13/2016 Types of Adjacent Systems Active Adjacent Systems: usually humans Independent Adjacent Systems it is some external body to your work, e.g. other company, government department, example: weather station Supportive Adjacent Systems Can be relied onto and behave predictably ( computerized systems), example: thermal mapping supplier.

Adjacent systems - Case Study ◦ Weather forecasting service ◦ Weather station ◦ Map supplier ◦ Road engineering ◦ Truck station

Work Context

The Risks Project related risks Project related risks 1.Inadequate measurement 2.Excessive schedule pressure 3.Inaccurate cost estimating 4.Low quality 5.Low productivity

The Risks Requirements related risks Requirements related risks 1.The absence of clear & measurable purpose for the product 2.Lack of client involvement 3.Lack of stakeholder involvement 4.Little or no agreement on requirements 5.No measurements put on requirements 6.Rapidly changing requirements 7.New or unknown business area with uncertain needs

Go/No-go Decision Is the product Goals/purpose clear? Is it measurable and viable? Is it possible to achieve the objectives of the project? Can you reach agreement on the context of the work? Does the high portability/impact of the risks make the project feasible? Is the cost reasonable for the product’s benefit? Are the stakeholders willing to be involved? Do you have sufficient justification to invest in the project? Do you have enough reasons not to invest in the project? Is there any further investigation that you should do before pressing the button to start the project?