INFO 627Lecture #51 Requirements Engineering and Management INFO 627 Defining the System and...

INFO 627 Lecture #5 1

Requirements Engineeringand ManagementINFO 627

Defining the System and Managing Scope Glenn Booker


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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)


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


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!


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

Time

Number of

People Project

Scope

Deadline


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


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


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!


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


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


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


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 needed to accomplish each feature Rough order of magnitude is okay here At least do Critical/Important/Useful or H/M/L Do more refined estimates if possible


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


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)


Assigning Resources to Features

For critical

priority features

Risk

Effort

Risk mitigationand immediate

resources

Immediateresources

Lastresources

Middleresources


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


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


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


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!


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


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


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


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


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)


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


Waterfall Model

Coding &Unit Test

DetailedDesign

SystemTesting

Problem Analysis

Architectural Design

RequirementsAnalysis


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


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


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 ...


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


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


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


Waterfall with Subprojects

Detailed Design, Coding,Unit Test, Subsystem Testing

SystemTesting

Conceptual Development





Sub-Project A

C

B


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


Staged Delivery

Stage 2: Detailed Design, Coding,Unit Test, Test, and Deliver

Conceptual Development



Stage 1: Detailed Design, Coding,Unit Test, Test, and Deliver

Stage n: Detailed Design, Coding,Unit Test, Test, and Deliver

…


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)


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


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


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 627Lecture #51 Requirements Engineering and Management INFO 627 Defining the System and...

Documents

Transcript of INFO 627Lecture #51 Requirements Engineering and Management INFO 627 Defining the System and...