dr. kivanc dincercs319 week 1 - sept.12,20051 chapter 4 inception is not the requirements phase...
Post on 21-Dec-2015
222 views
TRANSCRIPT
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 1
Chapter 4INCEPTION IS NOT THE REQUIREMENTS PHASE
Objectives• Define the inception step.• Motivate the following chapters in this section.
“The best is the enemy of the good.” - Voltaire
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 2
Inception is NOT the Requirements Phase
• Purpose is to decide whether to proceed with development, not to define requirements.– Only key requirements are investigated.
• Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?
• Inception is the initial short step to establish a common vision and basic scope for the project.– It will include analysis of perhaps 10% of use cases, analysis
of the critical non-functional requirement, creation of a business case, and preparation of the development environment.
• Inception in one sentence:Determine the product scope, vision, and business case.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 3
Questions during inception
• What is the vision for this project?• What is the business case?• Is the project feasible?• Should we buy or build?• Rough estimate of cost?• At end of inception: Go or No Go?
An Analogy: New field exploration decision in the oil business.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 4
Inception Artifacts
• Vision and Business Case• Use-Case Model• Supplementary Specification• Glossary
• Prototypes and proof-of-concepts
• Risk List & Risk Management Plan• Iteration Plan• Phase Plan and Software Development Plan• Development Case
*Not all documents are needed for every project.
Project Mgr’s responsibility
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 5
Vision and Business Case
• Describes the high level goals and constraints, the business case, and provides an executive summary.– Usually has an estimate of costs (+/- 100%) and
expected benefits stated in financial terms.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 6
Use Case Model
• Describes the functional requirements and related non-functional requirements.– A set of typical scenarios of using a system.
• Preliminary only, usually the names of most of the expected use cases and actors, but usually only about 10% of the use cases are detailed.– Do not detail all of the use cases. Only document
the most important ones. About 10% of the use cases should be detailed enough to estimate the scope of the total project.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 7
Supplementary Specification
• Describes non-functional requirements that do not appear elsewhere.
• Functional requirements describe the functionality of the product. All other requirements that must be met are considered non-functional requirements.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 8
Glossary
• Describes the key terms in the business domain.
• Includes a data dictionary– Validation rules, acceptable values, etc.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 9
• These may be developed to clarify the vision, or to validate technical ideas.
• Inception phase prototypes are throw away prototypes, not evolutionary prototype that may be evolved into a product. – UI oriented prototypes and programming
experiments for “show stopper” technıcal questions.– They are often done with a prototyping tool.
Prototypes / Proof of concepts
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 10
Risk Plan
• Contains a list of known and expected risks.• Includes business, technical, resource, and
schedule risks identified by probability and severity.
• All significant risks should have a response or mitigation plan.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 11
Iteration Plan
• Describes what to do in the first iteration of the product.
• Usually implements the core functionality of the product.
• Eliminate biggest risk first. – The worst risk is usually that the final product will not
meet the most important requirement.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 12
Phase / Software Development Plan
• A low precision guess for the duration and effort of the elaboration. Includes tools, people, training and other resources required.
• May also be called a Resource Plan.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 13
Development Case
• A description of the Unified Process steps and artifacts for the project. Note that the UP is always customized for each project.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 14
Isn’t that a lot of documentation?
• In UP, those artifacts are optional– Choose to create only those that really add value for
the project
• Often, the point of creating artifacts or models is not the document or diagram itself, but the thinking, analysis, and proactive readiness.– “In preparing for battle, I have always found that
plans are useless, but planning indispensable.” –
General Eisenhower
• Artifacts from previous projects can be partially used for later ones.– esp. Risk, project management, testing, and
environment artifacts.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 15
You know you don’t understand Inception when…
• Schedule– Inception should last a few weeks at most.
• Requirements and most of the use cases &actors identified.– Only key requirements should be described during
inception. Save the rest for later phases and later iterations.
• Accuracy of estimates– There is a funnel of cost estimates. The earlier the
estimate, the less accurate it is.
• Architecture designed– Architecture should be done iteratively during
elaboration.– Defer decisions as late as possible. The more you know,
the less chance that you will make a bad decision.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 16
How much UML during inception?
• Perhaps, beyond simple UML use case diagrams, not much diagramming is warranteed.– Requirements expressed mostly in text forms.
• UML diagramming will occur in the elaboration phase.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 17
Chapter 5EVOLUTIONARY REQUIREMENTS
Objectives• Motivate doing evolutionary requirements.• Defines the FURPS+ model.• Define the UP requirements artifacts.
“Ours is a world where people don’t know what they want and are willing to go through hell to get it.”
- Don Marquis
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 18
Path to disaster*
• The Waterfall method is too risky:- Define the requirements
- Design the architecture– Implement the product
• There is an attempt in the waterfall method to describe the requirements fully and accurately and “freeze” them. – The wrong paradigm is viewing the software project as similar to
predictable mass manufacturing, with low change rates.
• Avoid “Paralysis by Analysis” – it kills the budget without significantly benefiting the corporation.– Classic Mistake: Too much time and money wasted in the
“fuzzy front end.” – Use iterations instead.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 19
Requirements
• These are the capabilities and conditions that the system, the project, and the product must provide and meet.
• Requirement issues (...) are the leading cause of project failure. – Even if you do a perfect job of building the wrong
thing, its no good!– Managing requirements is a best practice for project
managers.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 20
Poor user input13%
Changing requirements12%
Poor technical skills7%
Poor staffing6%
Other50%
Incomplete requirements12%
Figure 5.1 Actual use of waterfall-specified features (Johnson 2002): 45% such features were never used, and an additional
19% were rarely used.
WRONG GRAPH!
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 21
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)
* Skillful elicitation via useful techniques– Such as writing use cases with customers, requirements workshops, focus
groups with proxy customers, and a demonstratıon of the results of each iteration to the customer.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 22
Types and Categories of Requirements : FURPS+ Model
(Grady 1992)• Functional (features, capabilities, security)• Usability (human factors, help, documents)• Reliability (failures, recovery, predictable)• Performance (response, throughput, etc)• Supportability (maintainability, configuration)
• + ancillary and sub-factors– Implementation (includes limitations)– Interface– Operations– Packaging– Legal Requirements
QualityRequirements
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 23
Functional Requirements
• “Behavioral” 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.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 24
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.
Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 25
UP Requirements Artifacts
• Use-Case Model• Supplementary Specification• Glossary• Vision
• Business (Domain) Rules– Decribes requirements or policies that transcend one
software project.– Ex. Government tax rules.