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