Understanding Requirements Chapter 5 Applying UML and Patterns -Craig Larman.

Slides:



Advertisements
Similar presentations
Features, Advantages & Disadvantages of a Methodology.
Advertisements

Chapter 05: Evolutionary Requirements Definition : Requirements  “Requirements are capabilities and conditions to which the system, and more broadly.
CS3773 Software Engineering Lecture 01 Introduction.
Object-Oriented Analysis and Design LECTURE 2: INCEPTION PHASE.
Chapter 5 Evolutionary requirements –Expect change! –Learn as you go –Validate as you build Why – 25% requirements change on an average software project.
Chapter 7 Other Requirements Good Fast Cheap Pick any two. 1CS John Cole.
Object-Oriented Analysis and Design
NJIT From Inception to Elaboration Chapter 8 Applying UML and Patterns Craig Larman.
Requirements Analysis CMPT 371 Fall 2004 J.W. Benham.
SE 555 Software Requirements & Specification Requirements Quality Attributes.
Major Exam II Reschedule 5:30 – 7:30 pm in Tue Dec 5 th.
Dr. Kivanc DincerCS319 Week 1 - Sept.12,20051 Chapter 4 INCEPTION IS NOT THE REQUIREMENTS PHASE Objectives Define the inception step. Motivate the following.
Software Engineering Georges Grinstein Olsen 301E Class materials:
NJIT Evolutionary Requirements Chapter 5 Applying UML and Patterns Craig Larman.
From Inception to Elaboration Chapter 8 Applying UML and Patterns -Craig Larman.
SE 555 – Software Requirements & Specifications Introduction
NJIT Inception is not the Requirements Phase Chapter 4 Applying UML and Patterns Craig Larman.
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Object Oriented Analysis and Design Using the UML
Slide 1 Requirements Workflow. Slide 2 The Phases/Workflows of the Unified Process Figure 3.1 l Phase is Business context of a step Workflow is Technical.
Copyright © Craig Larman All Rights Reserved Requirements.
Managing Software Quality
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Unified Software Development Process (UP) Also known as software engineering process SEP describes how requirements are turned into software Defines who,
RUP Fundamentals - Instructor Notes
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
Investigating System Requirements
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CPSC 2150 August 21, Chapter 1 Object Oriented Software Development This is an introductory course In this chapter we will look at 3 topics Challenges.
 CS 5380 Software Engineering Chapter 2 – Software Processes Chapter 2 Software Processes1.
Object-Oriented Analysis and Design An Introduction.
Software Specification and Design Sirisin Kongsilp & James Brucker.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
Iterative development and The Unified process Chapter 2 Applying UML and Patterns -Craig Larman.
INFO 637Lecture #51 Software Engineering Process II Defining Requirements INFO 637 Glenn Booker.
Chapter 7 Applying UML and Patterns -Craig Larman
Chapter 7 Applying UML and Patterns Craig Larman
Jan 7, A UP project organizes the work and iterations across four major phases: – Inception -- approximate vision, business case, scope, vague estimates.
CSc 461/561 Software Engineering Lecture 2 – Software Processes.
Software Testing and Quality Assurance Software Quality Assurance 1.
1 COMP 350: Object Oriented Analysis and Design Lecture 1Introduction References: Craig Larman Chapter 1.
Chapter 1 Applying UML and Patterns. The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary.
RUP Life Cycle Software Engineering Learning Programme Software Engineering Foundation.
Inception Chapter 4 Applying UML and Patterns -Craig Larman.
Gerhard Dueck -- CS3013Requirements Capture 1  From Vision to Requirements  Why it is difficult?  Developers are not users  Inadequate requirements.
Software Requirements: A More Rigorous Look 1. Features and Use Cases at a High Level of Abstraction  Helps to better understand the main characteristics.
Chapter 5 Evolutionary Requirements. Introduction 5.1 Definition: Requirements 5.2 Evolutionary vs. Waterfall Requirements 5.3 What are Skillful Means.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Week 2. Topics Inception phase Evolutionary requirements Use cases.
Inception is not Requirement phasee Chapter 3 and 4 Applying UML and Patterns -Craig Larman.
Rational Unified Process (RUP)
Requirements Management with Use Cases Module 2: Introduction to RMUC Requirements Management with Use Cases Module 2: Introduction to RMUC.
Requirement Discipline Spring 2006/1385 Semester 1.
Larman chapter 41 Inception Larman chapter 4 and 7.
CS 389 – Software Engineering Lecture 2 – Part 2 Chapter 2 – Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.
Investigating System Requirements
Evolutionary requirements
(Professional Business Analyst Training organisation)
Unified Process(UP) popo.
Introduction to Software Engineering
Rational Unified Process
Week 2.
Requirements Analysis
Thursday’s Lecture Chemistry Building Musspratt Lecture Theatre,
Evolutionary Requirements
Chapter 5 Evolutionary requirements
Software Requirements
Software Requirements
Software Design and Development Processes
Presentation transcript:

Understanding Requirements Chapter 5 Applying UML and Patterns -Craig Larman

Requirements These are the capabilities and conditions that the system, the project, and the product must provide and meet. Managing requirements is a best practice for project managers. Requirement issues are the leading cause of project failure. Even if you do a perfect job of building the wrong thing, its no good!

Not Waterfall Requirements There is an attempt in the waterfall method to describe the requirements fully and accurately and “freeze” them. Unified process realizes that change is constant, so plans for change instead of setting an impossible goal.

Managing Requirements Stakeholder requirements are frequently unclear and change over time. Frequently new requirements are discovered as part of the development process. There must be a “systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.” (RUP)

FURPS+ Functional (features, capabilities, security) Usability (human factors, help, documents) Reliability (failures, recovery, predictable) Performance (response, throughput, etc) Supportability (maintainability, configuration) + ancillary and sub-factors (next slide)

Ancillary and sub-factors Implementation (includes limitations) Interface Operations Packaging Legal Requirements

Functional Requirements Detailed in the Use Case Model and in the System Features list of the Vision artifact. They are specified in detail in Operation Contracts where necessary.

Non-functional requirements Often called the “-ilities” of a system; quality, reliability, usability, performance, etc. The glossary, data dictionary and supplemental specifications describe many non-functional requirements. In addition, architectural documents may have non-functional requirements.