Other System Requirements

Slides:



Advertisements
Similar presentations
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Advertisements

Chapter 05: Evolutionary Requirements Definition : Requirements  “Requirements are capabilities and conditions to which the system, and more broadly.
Chapter 7 Other Requirements Good Fast Cheap Pick any two. 1CS John Cole.
Object-Oriented Analysis and Design
September Ron McFadyen1 design analysis implementation testing maintenance Waterfall Development Process Linear one phase is completed before.
Rational Unified Process
COMP 350: Object Oriented Analysis and Design Lecture 3 Case Studies, Inception & Use Cases References: Craig Larman Chapters 3-6.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
NJIT From Inception to Elaboration Chapter 8 Applying UML and Patterns Craig Larman.
Development Processes UML just is a modeling technique, yet for using it we need to know: »what do we model in an analysis model? »what do we model in.
OO Development Process. UML and Process UML standardizes notation, not process –Increase likelihood of widespread acceptance There is significant variability.
Object-oriented Analysis and Design
Understanding Requirements
Dr. Kivanc DincerCS319 Week 1 - Sept.12,20051 Chapter 4 INCEPTION IS NOT THE REQUIREMENTS PHASE Objectives Define the inception step. Motivate the following.
Jan 8, Ron McFadyen1 Waterfall Spiral UP Case study UML Use Cases.
Iterative development and The Unified process
From Inception to Elaboration Chapter 8 Applying UML and Patterns -Craig Larman.
COMP 350: Object Oriented Analysis and Design Lecture 2
Week 3 Iteration 1 Domain Models System Sequence Diagrams.
Copyright © Craig Larman All Rights Reserved Requirements.
UML - Development Process 1 Software Development Process Using UML (2)
Object-Oriented Analysis and Design Iterative Development and the Unified Process.
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
RUP Fundamentals - Instructor Notes
Rational Unified Process (Part 1) CS3300 Fall 2015.
IDENTIFYING OTHER REQUIREMENTS Write a Supplementary Specification, Glossary, and Vision. Compare and contrast system features with use cases. Relate the.
Testing Workflow In the Unified Process and Agile/Scrum processes.
Iterative development and The Unified process Chapter 2 Applying UML and Patterns -Craig Larman.
Chapter 7 Applying UML and Patterns -Craig Larman
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
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.
Chapter 2 Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler 1CS
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Object-Oriented Analysis and Design Jan 21, 2009.
2 2009/10 Object Oriented Technology 1 Topic 2: Introduction to Object-Oriented Approach Reference: u Ch.16 Current Trends in System Development (Satzinger:
Inception Chapter 4 Applying UML and Patterns -Craig Larman.
Rational Unified Process (RUP) Process Meta-model Inception Phase These notes adopted and slightly modified from “RUP Made Easy”, provided by the IBM Academic.
Rational Unified Process Fundamentals Module 7: Process for e-Business Development Rational Unified Process Fundamentals Module 7: Process for e-Business.
J. Scott Hawker p. 1Some material © Rational Corp. Rational Unified Process Overview See and use the RUP Browser on lab machines.
The Rational Unified Process 1 EECS810: Software Engineering.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Software Engineering 1 Object-oriented Analysis and Design Chap 24 Iteration 2 More Patterns.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Chapter 8: Iteration 1 - Basics.  We review here the requirements for first iteration of our case studies. They are a subset of the requirements as described.
Chapter 8. Iteration 1, Elaboration: book view differs from reality for pedagogical reasons not doing “risk-driven” up front uses many OOA/D skills should.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
Review of Definitions Software life cycle: –Set of activities and their relationships to each other to support the development of a software system Software.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XIV. From Requirements to Design in the UP.
Development Process Based on Chapter 5 Bennett, McRobb and Farmer
Iterative development and The Unified process
TK2023 Object-Oriented Software Engineering
Object-oriented Analysis and Design
Elaboration popo.
Evolutionary requirements
The Web Application Development Process Models
Unified Process(UP) popo.
Unified Process (UP).
UML: Unified modeling language
Requirements and the Software Lifecycle
Introduction to Software Engineering
COMP 350: Object Oriented Analysis and Design Lecture 2
Rational Unified Process
Chapter 6 Use Case The interaction between an actor and the system.
Week 3 Iteration 1 Domain Models System Sequence Diagrams.
Week 3 Iteration 1 Domain Models System Sequence Diagrams.
Software Development Process Using UML Recap
CSCI 360: Software Architecture & Design
Presentation transcript:

Other System Requirements Ch. 7

Unified Process Artifacts and Timing Discipline Artifact Inception I1 Elaboration E1,…, En Construction C1, …, Cn Transition T1,…, Tn Business Modeling Domain Model S Requirements Use-Case Model R Vision Supplementary Specification Glossary Design Design Model SW Architecture Document Data Model Implementation Implementation Model Supplementary specification captures and identifies other kinds of requirements such as reports, documentation, packaging, supportability, licensing, etc. Supplementary specs: FURPS - functionality, usability, reliability, performance, supportability + implementation constraints, purchased components, free open source components, interfaces – noteworthy hardware and software interfaces, legal issues, information in domains of interest: pricing, credit, debit handling, sales tax, Vision: executive summary, Terse feature list is good in vision, less than 10 features Features are behavioral functions that a system can do. System does feature X Glossary: terms and definitions, aliases, abbreviations Domain rules: long living, spanning rules such as tax laws, dictate how domain and business may operate Inception is for feedback, it is a first approximation of requirements

From Inception to Elaboration – Iteration 1 Basics

Iteration 1 Requirements Implement a basic key scenario of the Process Sale use case: entering items and receiving a cash payment. No collaboration with external devices (such as tax calculator or product database) No complex pricing rules are applied. Subsequent iterations will grow on this foundation. Tackle difficult, risky things first. But how do we know which are these? Iterative means we do not tackle everything at once.

Incremental Development for the Same Use Case Across Iterations Not all requirements in the Process Sale use case are being handled in iteration 1. How many use cases should be completed during iteration 1? How long should these be? Not all requirements in the Process Sale use case are being handled in iteration 1. It is common to work on varying scenarios or features of the same use case over several scenarios and gradually extend the system to ultimately handle all the functionality required. On the other hand, short, simple use cases may be completed within one iteration. Key understanding of UP/Scrum and other iterative processes: we start production-quality programming and testing for a subset of the requirements and we start development BEFORE all the requirements analysis is complete – different than waterfal

Fig. 8.1 One use case could be iterated multiple times depending on its complexity. New features, exceptions may be added.

What happened during Inception? Basic feasibility assessment Risk list Scope definition Requirements workshop Actors, goals, use cases named Use cases written in brief format – why did we start with fully dressed? 10-20% use cases written in fully dressed – why? Scope understanding Risk list – time PoC prototypes! Recommendations: what to build, what to buy, tools list Plan first iteration

On to Elaboration! Core, risky structure programmed Majority of requirements Major risks mitigated/retired Estimate overall schedule, resources Build the core architecture, resolve high risk elements, define most requirements Short, timeboxed, risk driven iterations Start programming early Test early & often

Elaboration artifacts Domain Model Design Model Software Architecture Document Data Model Use case storyboards, UI prototypes Domain model: business model, concepts, entities Design model: diagrams, logical, class, interaction, package etc. diagrams SW Architecture doc: learning aid, key architectural issues, outstanding design ideas, motivation Data Model: database schemas Use I/F paths of navigation, usability models You know you did not understand elaboration when: you do not prepare production ready code, no early realistic testing, most requirements were defined before elaboration, risky elements are not tackled, it is considered primarily design/requirements phase preceded by implementation, there is minimal feedback & adaptation, proof-of-concept programming