Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.

Slides:



Advertisements
Similar presentations
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.
Advertisements

PROJECT TITLE Project Leader: Team: Executive Project Sponsor (As Required): Date: Month/Day/Year 110/17/2014 V1.
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
1 Chapter 4 The Software Team Requisite’s 6 team skills for effective requirements management.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
TSS Architecture Definition Context. TSS Scoping Study Context Detailed Requirements Specification (products, functionality) High Level Architecture Description.
8/28/2005ECEN5543 Req Elicitation1 Targets of Requirements Engineering ECEN 5543 SW Engineering of Standalone Programs University of Colorado, Boulder.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
Recall The Team Skills 1. Analyzing the Problem 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5. Refining the System.
1 Team Skill 3 - Defining the System (Chapters of the requirements text) CSSE 371 Software Requirements and Specification Don Bagert, Rose-Hulman.
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.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Information Technology Project Management – Fourth Edition
Chapter 3 The Structure of the CMM
Recall The Team Skills Analyzing the Problem
© 2005 Prentice Hall2-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Chapter 4 After Green Light. After the Green Light Contractual Agreement Marketing Requirements Document (MRD) Project DefinitionBudget Project Approval.
The Vision Document 1. Importance of a Vision Document  It describes the application in general terms, including descriptions of the target market, the.
An Introduction to the new features in TOGAF® 9
RUP Requirements RUP Artifacts and Deliverables
UML - Development Process 1 Software Development Process Using UML (2)
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
1 Text Layout Introduction (1-4) Team Skill 1 – Analyzing the problem (5-7) Team Skill 2 – Understanding User and Stakeholder Needs (8-13) Team Skill 3.
1 IBM Software Group ® Mastering Requirements Management with Use Cases Module 4: Analyze the Problem.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
Rational Requirements Management with Use Cases v5.5 Copyright © Rational Software, all rights reserved 1Welcome! Rational Requirements Management.
Organizing the Requirements Information 1. Need for Organizing Requirements  Many stakeholders are involved in most projects.  They must reach agreement.
Adaptive Processes © Adaptive Processes Simpler, Faster, Better Software Requirements.
Software Requirements The starting point of software development “He kept changing the requirements on us” 1 540f07reqelic4sep4.
10/12/ Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 1. Interviews & questionnaires.
Software Engineering Chapter 7 Fall Capturing the Requirements as Use Cases Capturing the Requirements as Use Cases By using use cases analysts.
Project scope and activities INFO 638Lecture #21.
Agile User Stories Enriched with Usability ANA M. MORENO AND AGUSTÍN YAGÜE UNIVERSIDAD POLITECNICA DE MADRID MADRID, SPAIN
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System 4. Managing Scope 5.
Insert: Title of Improvement Read Out Date:. 2 Objectives for Today’s Session Share results of improvement effort Demonstrate fact-base, analytical approach.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Object Oriented Analysis and Design using the UML CIS 520 Advanced Object-Oriented Design.
Team Skill 3 – Organizing Requirements & Product Management (Chapters of the requirements text ) Sriram Mohan/Steve Chenoweth RHIT 1.
Software Engineering COSC 4460 Class 4 Cherry Owen.
Requirements Management with Use Cases Module 10: Requirements Across the Product Lifecycle Requirements Management with Use Cases Module 10: Requirements.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
Requirements Engineering for Web Applications. SR: System Vision Document Written by key stakeholders Written by key stakeholders An executive summary.
Chapter 31 Your Prescription for Requirements Management.
Team Skill 6: Building the Right System Assessing Requirements Quality (29)
PRJ566 Project Planning & Management Software Architecture.
RequisitePro Software Requirement Management Tool A peresentation by: Mojdeh Jalali-Heravi Maryam Daneshi.
Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing.
An Agile Requirements Approach 1. Step 1: Get Organized  Meet with your team and agree on the basic software processes you will employ.  Decide how.
Team Skill 3: Defining the System The Vision Document (16) 1.
Requirements Management with Use Cases Module 4: Analyze the Problem Requirements Management with Use Cases Module 4: Analyze the Problem.
Software Engineering CE 501 Prepared by : Jay Dave.
Team Skill 3 - Defining the System (Chapters of the requirements text ) Sriram Mohan 1.
Enterprise Architectures Course Code : CPIS-352 King Abdul Aziz University, Jeddah Saudi Arabia.
List 3 – 5 guiding principles that will serve as foundation and guide rails for the project. See slide 4 for further details ObjectivesGuiding PrinciplesKey.
Requirements Management with Use Cases Module 0: About this course Requirements Management with Use Cases Module 0: About this course.
George Wang, Ph.D. COMP 380/L Lesson 2. Use Case Use cases are a way to capture system functionalities (i.e., functional requirements) Based on use case.
Your Prescription for Requirements Management 1. Assumptions The prescription for requirements management is based on the following assumptions:  The.
Chapter 25 – Configuration Management 1Chapter 25 Configuration management.
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Process 4 Hours.
The Project Infrastructure
The Vision Document Group members: Zainab BSEF07M025 Noreen BSEF08M021
Recall The Team Skills Analyzing the Problem (with 5 steps)
CEN 5035, Software Engineering
Chapter 4 After Green Light
SRS : Software Requirement Specification. How to Write a Software Requirements Specification (SRS Document)  A software requirements specification (SRS)
Presentation transcript:

Recall The Team Skills 1. Analyzing the Problem (with 5 steps) 2. Understanding User and Stakeholder Needs 3. Defining the System A Use Case Primer Organizing Requirements Information The Vision Document 4. Managing Scope 5. Refining the System Definition 6. Building the Right System

Chapter 16 The Vision Document

The Vision Document The Vision document captures the needs of the user, the features of the system, and other common requirements for the project. As such, the scope of the Vision document extends over the top two levels of the requirements pyramid, thereby defining at a high level of abstraction both the problem and the solution.

The Importance of Vision Document It serves as the basis for discussion and agreement among the stakeholders. It captures the essence of the product from all significant perspectives in a short, abstract, readable, and manageable form.

Template for a Software Product Vision Document

See Appendix B For more detailed template.

The Delta Vision Document Keeping the Vision document understandable and manageable is an important team skill that will greatly benefit the overall productivity of the project. In future releases, you may discover that it is counterproductive to repeat features that have been incorporated in prior releases and other information that has not changed in this particular project context, such as user profiles, markets served, and existing features. We therefore introduce the Delta Vision document, which addresses these issues.

The Vision Document for Version 1.0 This document serves as the foundation for the 1.0 release and drives the more detailed software requirements and use cases that will more fully elaborate the system.

Delta Vision Document v2.0 The Delta Vision document focuses on only two things: What has changed; and Any other information that must be included for context. In other words, it focuses primarily on … What is new; and What is different about this release.

The Evolving Product Definition

Key Points Every software project will benefit from having a Vision document. The Vision document describes the application in general terms, including descriptions of the target market, the system users, and the application features. The Vision document defines, at a high level of abstraction, both the problem and the solution. The Delta Vision document focuses on what has changed.