Chapter 4: Inception is Not the Requirements Phase

Slides:



Advertisements
Similar presentations
1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
Advertisements

Chapter 05: Evolutionary Requirements Definition : Requirements  “Requirements are capabilities and conditions to which the system, and more broadly.
Object-Oriented Analysis and Design
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Software Life Cycles ECE 417/617: Elements of Software Engineering
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
Dynamic Systems Development Method (DSDM)
Rational Unified Process
COMP 350: Object Oriented Analysis and Design Lecture 3 Case Studies, Inception & Use Cases References: Craig Larman Chapters 3-6.
NJIT From Inception to Elaboration Chapter 8 Applying UML and Patterns Craig Larman.
Object-oriented Analysis and Design
NJIT 1 Iteration 2 Requirements and More GRASP Chapter 24.
Dr. Kivanc DincerCS319 Week 1 - Sept.12,20051 Chapter 4 INCEPTION IS NOT THE REQUIREMENTS PHASE Objectives Define the inception step. Motivate the following.
Chapter 30 Agile Requirements Methods. Mitigating Requirements Risk  The entire requirements discipline within the software lifecycle exists for only.
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
NJIT Inception is not the Requirements Phase Chapter 4 Applying UML and Patterns Craig Larman.
1 College of Engineering and Computer Science Computer Science Department CSC 131 Computer Software Engineering Fall 2006 Lecture # 2 Chapter 6 & 7 System.
© 2005 Prentice Hall14-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
S/W Project Management
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
1 REQUIREMENT ENGINEERING Chapter 7. 2 REQUIREMENT ENGINEERING Definition Establishing what the customer requires from a software system. OR It helps.
Chapter 1 , 2 , 3 and 4 Applying UML and Patterns -Craig Larman
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Instructor: Tasneem Darwish1 University of Palestine Faculty of Applied Engineering and Urban Planning Software Engineering Department Object Oriented.
Software Engineering Management Lecture 1 The Software Process.
1 Software Process Models-ii Presented By; Mehwish Shafiq.
Systems Analysis Lecture 2 Analysing the Business Case Feasibility Scope 1 BTEC HNC Systems Support Castle College 2007/8.
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
Rational Unified Process Mr Hisham AlKhawar. Iterative versus Waterfall  We need to use a life cycle model in order to approach developing a system easily,
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.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
CS 5150 Software Engineering Lecture 7 Requirements 1.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Chapter 4. Inception is NOT Requirements: Inception is a short, initial stage. Its purpose is a common vision and scope measurement. needed to do: –analyze.
Project Initiation at The Regence Group 12/19/2015John Garrigues1.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
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.
Week 2. Topics Inception phase Evolutionary requirements Use cases.
Ivar Jacobson, Grady Booch, and James Rumbaugh The Unified Software Development Process Addison Wesley, : James Rumbaugh's OOMD 1992: Ivar Jacobson's.
Inception is not Requirement phasee Chapter 3 and 4 Applying UML and Patterns -Craig Larman.
Rational Unified Process (RUP)
Prototypes A systematic look at Prototyping (Christiane Floyd)
Requirement engineering & Requirement tasks/Management. 1Prepared By:Jay A.Dave.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
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.
Meghe Group of Institutions Department for Technology Enhanced Learning 1.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
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.
Larman chapter 41 Inception Larman chapter 4 and 7.
The Unified Process and the Inception Phase James W. Benham CMPT 371 Fall 2004.
The B uff. The Buffs Outline 1. Summary of last presentation 2. Current iteration and Progress 3. Plan for next iteration.
PART II INCEPTION Chapter 4 Inception is Not The Requirements Phase.
RUP RATIONAL UNIFIED PROCESS Behnam Akbari 06 Oct
TK2023 Object-Oriented Software Engineering
Applying UML and Patterns
Unified Process (UP).
COMP 350: Object Oriented Analysis and Design Lecture 2
Week 2.
Chapter 4 Inception CS John Cole.
Applied Software Project Management
Other System Requirements
Presentation transcript:

Chapter 4: Inception is Not the Requirements Phase

4.1. Introduction Inception is the initial short step to establish a common vision and basic scope for the project. It may include for example: Analysis of perhaps only 10% of the use cases; Identification of main risks; Analysis of the critical non-functional requirements (e.g. performance); Business case; Identification of development environment needs (e.g. do we need a new tool?); It is not the documentation of the full detailed requirements: I.e. the writing-up of the software specification in the waterfall-way.

4.2 What is Inception? A phase to clarify things-up a bit: What is the vision of this project, its scope? Feasibility? Buy components and glue or from scratch? Very rough cost and schedule? Can we convince people of business case? It is not to define and document all requirements: We have to accept that all our estimates and requirements will be, at the end of this phase, still very rough; It is during elaboration (once we get the go-ahead) that these will be refined; The idea is to do just enough investigation to be able to present a rational business case to show purpose, feasibility and need for the proposed software: should we investigate further or stop right now?

Although it would be nice to have all the requirements detailed, the cost and schedule all worked-out before committing to a project, it is unrealistic for most applications (including games). The inception phase is about deciding if the project is worth a serious investigation (during elaboration), not to do that investigation.: This implies that the project may be abandoned during elaboration: this should not be taken as being a project failure or as a mistake having been made during inception; In the UP, the plans and estimates created during the inception phase are not to be considered as reliable: the inception phase is more or less a feasibility study: Can we do it from a technical point-of-view? Does it make sense from a business point-of-view?

4.2 How Long Should the Inception Phase be? Short. It may even be shorter (less than a week) if the project is commissioned by a client. Sometimes business negotiations will take much longer however … What do you think?

4.3 Which Artifacts Should be Started? Potential artifacts: Vision and Business Case: describes the high-level goals and constraints, provides an executive summary; Use Case Model: describes the fundamental requirements: during inception identify the names of the use cases and analyse perhaps 10% of the them; Supplementary specification: describe non-functional requirements, look-and-feel, atmosphere etc. Glossary: keeping track of key terms; Risk list and risk management plan: describe the risks (business, technical, resource, schedule) and ideas for their mitigation; Prototypes and proof-of-concepts: to clarify the vision, and validate technical ideas; Iteration Plan: Describes what to do in the first elaboration iteration, and overall goals of the elaboration phase; Development Case: Customised software development process;

A key aspect, is that while these documents/artifacts may be started during the inception phase they will not be completed during it! The artifacts will only be partial at this stage: they will be refined in later iterations. Coding may take place during this phase for the development of prototypes. These may be used to: Clarify some functional and/or non-functional requirements (animation, look-and-feel etc.); Reduce technical risk by demonstrating (or otherwise!) feasibility; Often the real value is not in the artifacts themselves but in the process that was necessary to write them up: the thinking, the analysis, the communication between the team (with involvement of the client) etc. : much more valuable than the details of the documents.

You must also be honest and realistic: But it is also worthwhile to have some structure (e.g. keeping standard names for documents). You must also be honest and realistic: There is absolutely no point in writing up a document just for the sake it, just for the manager to tick a box in his plan … (this happens very, very often); At the end of the day, a document must bring some value to a project; Being honest and realistic is not always easy (commercial pressures, personnel issues etc.); The agile approach is centered on humans not documents; The UML will play little role during this phase apart from Use Case Diagrams.

4.4 You Know you did not Understand Inception when … It is more than a few weeks long; There is an attempt to define most of the requirements; Plans and estimates are expected to be reliable; There is no business case or vision artifact; All the use cases were written in detail;

4.5 Conclusion The inception phase is not very technical, it is really about deciding if it is worthwhile to invest in deeper exploration (the purpose of the elaboration phase); Not going any further is not a negative outcome … Questions Please