Requirements Engineering and Management INFO 627 Defining the System and Managing Scope Glenn Booker INFO 627 Lecture #5
Download ReportTranscript Requirements Engineering and Management INFO 627 Defining the System and Managing Scope Glenn Booker INFO 627 Lecture #5
Requirements Engineering and Management INFO 627
Defining the System and Managing Scope
Glenn Booker INFO 627 Lecture #5
1
Organizing Requirements
Requirements must be captured and documented. Period. No excuses.
For that to happen, the stakeholders must reach agreement on what are the requirements It is rare for all requirements to be fulfilled in the first release of a system, so need to agree on their priority, too INFO 627 Lecture #5 2
Organizing Requirements
The requirements specification defines the external behavior of the system A single document rarely can capture all requirements Might separate system requirements from software requirements Could use a high level Vision document, vs. a lower level software requirements specification INFO 627 Lecture #5 3
Organizing Requirements
Might use product family versus software requirements Could separate business requirements from software requirements The systems engineering approach can lead us to defining system requirements, then define subsystem requirements INFO 627 Lecture #5 4
Organizing Requirements
Then each subsystem’s requirements could be divided into hardware, software, and interface requirements (1E p. 163) Product families, or product lines, are sets of systems which share some common subsystems Like different cars using the same model starter INFO 627 Lecture #5 5
Product Families
In those cases, the vision for each system is based in part on a vision for the whole family, and the shared software requirements For any system, need to distinguish requirements which are being implemented from those saved for future releases INFO 627 Lecture #5 6
Business Requirements
Some organizations use a Marketing Requirements Document (MRD) to capture business issues Market release windows Target market or audience Distribution and marketing issues Profit margin and investment amortization INFO 627 Lecture #5 7
Vision Document
The vision document combines some marketing and product requirements Use of the Vision document is highly recommended Also known as the scope or business blueprint Can define vision for an organization too Joint Vision 2020 INFO 627 Lecture #5 8
Vision Document
Challenge in writing the Vision is to keep everything understandable by all major stakeholders Write at a low level of detail, and use plain language The vision captures what the system will do, and won’t do INFO 627 Lecture #5 9
Vision Document
The Vision document gives a synopsis of the problem to be addressed, and the solution proposed The Vision describes: The users of the system; their demographics, profile, and environment Alternative solutions and competition INFO 627 Lecture #5 10
Vision Document
The product, including its benefits, differences from the competition, capabilities, dependencies, and cost Key features Key use cases Non-functional requirements Documentation, installation, and help INFO 627 Lecture #5 11
Delta Vision Document (DVD?)
As a product concept matures during development, a “Delta Vision” document can be used to reflect improved understanding Hence the basic product information from the first Vision document isn’t repeated Instead, focus on changes INFO 627 Lecture #5 12
Delta Vision Document 2.0+
The second and later major releases could use a delta vision with New features in version 2 Removed features from version 1 Planned features for future releases The delta vision document is kind of like a release’s Version Description Document (VDD), but at a higher level INFO 627 Lecture #5 13
Delta Vision for Legacy Systems
Fully defining requirements for a large legacy system is often too time consuming Can then use a delta vision document to capture what
changes
you want to make in the system features This avoids documenting stuff which isn’t changing INFO 627 Lecture #5 14
Champion
No, not a mushroom, that’s a
champignon
The project vision is maintained by a product champion The champion maintains the vision, and makes sure that changes to it are negotiated fairly among the various stakeholders The champion is fully focused on what this product will become, and makes it that way INFO 627 Lecture #5 15
Champion
In contrast, some projects are marked by: Inability to refuse a new feature Inability to accept a reasonable schedule to create the desired features Inability to balance the product’s features (like a car with a 1000 HP engine and stock tires) These are all signs of a weak or nonexistent champion INFO 627 Lecture #5 16
Champion
The champion could be a lead engineer, project manager, or have other titles Depending on industry, the champion might be closely tied to marketing, to ensure the product remains desirable by the customer Champion must balance market, customer, technology, and profit all at once INFO 627 Lecture #5 17
Champion
For internal IT development, the champion might be from almost any area Champion needs to play a key role in feature change decisions (e.g. participate in the configuration control board) INFO 627 Lecture #5 18
Team Skill 3 Summary
So we’ve Started to structure requirements by subsystem, Captured the vision for the product, and Identified a champion to keep the vision from going out of focus *ouch* Now it’s time to get concerned about managing scope INFO 627 Lecture #5 19
Project Scope
The scope of a project consists of three parts: The
functionality
(features) to be delivered The
resources
available (people, facilities, tools, money, etc.) The
time
to complete implementation Given enough resources and time, most projects are easy!
INFO 627 Lecture #5 20
Project Scope
If we ignore facilities and tools for now, people and money can be equated to restrict our focus to two issues – people and time Number of People Project Scope Time Deadline INFO 627 Lecture #5 21
Project Scope
Can’t just add
resources
(people) to make a project finish sooner Too many interdependencies among their work Learning curve for project characteristics Proven by Brooks in 1975 Only works if enough time for people to become productive, and productivity still goes down with project size INFO 627 Lecture #5 22
Project Scope
Time may or may not be a flexible constraint May – Windows Server 2003 (first due for release in 2001) And Windows Vista, known as Longhorn in 2003?
May not – The Year 2000 Problem, any fixed regulatory constraint, or known competitive constraint INFO 627 Lecture #5 23
Project Scope
The functionality which gets delivered is limited by the available time and resources Yet on average, projects will start based on completing 200% of the features in the scope available Maybe that’s why projects average 89% late!
Result is that half of the features don’t work, or all features half work – yuck!
INFO 627 Lecture #5 24
Project Scope
This leads to the development team’s dilemma of chopping the scope in half, without ticking off the customer Otherwise the customer becomes an unofficial part of the test team, which is generally not appreciated Old line – release 1.0 means “beta” test INFO 627 Lecture #5 25
Establishing Scope
The key to defining the scope of a project is to create the
requirements baseline
The requirements baseline defines what requirements will be delivered in which version of the application Assumes incremental development of features Must be agreed to by customer INFO 627 Lecture #5 26
Requirements Baseline
The requirements baseline must also have a reasonable chance of being implemented on time Start to define the requirements baseline by making a list of the features Need to keep a consistent, low level of detail Remember the guideline of 25-99 features INFO 627 Lecture #5 27
Requirements Baseline
Then assign
priorities
to each feature Critical/Important/Useful or H/M/L is enough Could vote on priorities like we saw earlier Now estimate the amount of
effort
accomplish each feature needed to Rough order of magnitude is okay here At least do Critical/Important/Useful or H/M/L Do more refined estimates if possible INFO 627 Lecture #5 28
Requirements Baseline
Now define the
risk
in implementing each element – how technically challenging is it to implement?
Again, use three level scale, at least Now look at candidates for reducing scope, if necessary INFO 627 Lecture #5 29
Reducing Scope
Make sure that the critical priority features are really the core of the system First look for high priority, then balance effort and risk High effort and high risk might call for immediate risk mitigation Assign resources to high effort features first (unless system architecture dictates otherwise) INFO 627 Lecture #5 30
Assigning Resources to Features
Middle resources Risk mitigation and immediate resources Risk For critical priority features Last resources Immediate resources Effort Lecture #5 INFO 627 31
Reducing Scope
Then look at how much scope reduction is needed, and reduce resource allocation to lower priority features accordingly For slight scope reduction, might shift immediate resources to middle, middle to low, and eliminate low completely For more drastic scope reduction, might drop
all
medium and low priority features INFO 627 Lecture #5 32
Reducing Scope
The keys to successful reduction are: Make sure the customer is happy with what will get implemented The features implemented still form a coherent product – not a hodgepodge of unrelated features Keep the vision intact INFO 627 Lecture #5 33
Requirements Baseline
The requirements baseline is formed when the time and effort match the features to be developed The requirements baseline defines the expected features to be developed Then if any lower priority features can be included in time, they’re a bonus INFO 627 Lecture #5 34
Managing the Customer
It often helps to maintain a supportive position with your customer Want to help them meet their commitments and do so with a product which will fulfill their needs Remember the product belongs to the customer, not the development team!
INFO 627 Lecture #5 35
Managing the Customer
Customer needs to be a direct participant in all decisions affecting the product scope This gets buy-in from the customer, and alleviates responsibility for the developer Negotiating is critical for scope discussions “Getting to Yes” is a classic guide See Dale Carnegie, Zig Ziglar, and Dr. Norman Vincent Peale for negotiation and sales skills INFO 627 Lecture #5 36
Managing the Customer
Try to
underpromise
and
overdeliver
when negotiating, because of the inevitable risks of development Unexpected technical risks Delays in getting hardware or software Emergencies among your staff And a thousand other things which might go wrong INFO 627 Lecture #5 37
Managing the Customer
Margins for error also allow for feature creep, which can run 30-100% after the start of the project Need to continually balance desire for more features with the needs for schedule and cost accuracy and product quality INFO 627 Lecture #5 38
Managing Feature Changes
Changes need to be recorded and tracked using our change control system Added features will result in some effect: Change in cost, schedule, and/or resources Lower priority for some other feature(s) Higher risk for completing one or more features Customer needs to be clear about the impact INFO 627 Lecture #5 39
Software Development Process
The software development process (life cycle) model describes the sequence in which all major activities will occur Defines
who
does
what when
Whether formal or not, some model is always being used – just not necessarily the ones shown here (See lecture 3 of INFO 638 for more models) INFO 627 Lecture #5 40
Waterfall Life Cycle Model
One of the first models used, circa 1970 Covers all major software development activities in a logical sequence Based on an assembly-line mentality Transitions between activities often called “throwing it over the wall” Little or no communication among life cycle phases INFO 627 Lecture #5 41
INFO 627
Waterfall Model
Problem Analysis Requirements Analysis Architectural Design Detailed Design Coding & Unit Test System Testing Lecture #5 42
Waterfall Model
Works well for: Known requirements AND known technologies Weak or inexperienced staff Clearly defined requirements (
must
have!) Problems: Often hard to define requirements adequately Expensive and time consuming Few signs of progress INFO 627 Lecture #5 43
Spiral Life Cycle Model
Focuses on addressing major risk areas for a project (requirements, architecture, etc.) Each “mini-project” addresses one or more risk areas, then start the next mini-project A.k.a. the cinnamon roll model Developed by Barry Boehm, USC, 1988 INFO 627 Lecture #5 44
Spiral Model
Each mini-project has six steps Determine objectives, alternatives, and constraints for this mini-project Identify and resolve risks Evaluate alternatives (possibly through prototyping) Develop and verify the deliverables for the next iteration ...
INFO 627 Lecture #5 45
Spiral Model
Plan the next iteration Review progress to date; obtain commitment for next mini-project Go on to the next mini-project Repeat until project is completed, or major risks are under control Then
another life cycle model must be used
INFO 627 Lecture #5 46
Spiral Model
Is often combined with other life cycle models within each mini-project too Pros Handles risk very well Cons Very complicated Hard to define and resolve many mini-projects Hard to stay focused on overall project goals INFO 627 Lecture #5 47
Waterfall with Subprojects
After Requirements and Architectural Design of project, break out [Detailed Design, Coding, and Unit Testing] for several subprojects Then integrate the whole system and complete system testing for a single release of the product Pros include faster development of known tasks, and possibly better use of resources Cons include unforeseen dependencies between subprojects INFO 627 Lecture #5 48
Waterfall with Subprojects
Conceptual Development Requirements Analysis Architectural Design C Sub-Project A B Detailed Design, Coding, Unit Test, Subsystem Testing Detailed Design, Coding, Unit Test, Subsystem Testing INFO 627 Detailed Design, Coding, Unit Test, Subsystem Testing Lecture #5 System Testing 49
Staged Delivery
Like Waterfall model for Requirements Analysis and Architectural Design; then [Design, Code, Test, and Deliver] the product in stages Project fully defined from the start and is delivered in stages, based on feature priorities Increases chance of getting key features into product Good for maintenance environment INFO 627 Lecture #5 50
Staged Delivery
Conceptual Development Requirements Analysis Architectural Design Stage 1: Detailed Design, Coding, Unit Test, Test, and Deliver
…
Stage 2: Detailed Design, Coding, Unit Test, Test, and Deliver Stage n: Detailed Design, Coding, Unit Test, Test, and Deliver Lecture #5 51 INFO 627
Iterative Approach
The iterative life cycle model breaks life cycle phases apart from the features of the product Used by the Rational Unified Process See also INFO 620’s text by Larman, Ch. 2 Each phase has one or more iterations Each iteration produces an executable system (or some defined release) INFO 627 Lecture #5 52
Iterative Approach
Phases are: Inception, to define scope of an issue Elaboration, to define requirements, structure, and resolve highly risky parts of this issue Construction, to implement less risky parts of this issue Transition, to get issue ready for beta testing and deployment INFO 627 Lecture #5 53
Iterative Approach
Each iteration has a clear time limit (timeboxed), such as 2 or 4 weeks duration Hence this model is heavily risk-focused, like the spiral model, but has overall phases more like a waterfall model Goal is to blend risk reduction with a mix of design and development activities Iterations build on each others’ functionality INFO 627 Lecture #5 54
Iterative Approach
Approach gets rid of many “Yes, But” objections due to many releases Helps manage scope through frequent estimation and effort cycles No matter which development process model is used, get a prototype to the customer!
INFO 627 Lecture #5 55