Lecture 3 Requirements

CS 540 – Quantitative Software Engineering

Software Requirements Process

Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype/Modeling Requirements Management

Highlights of quantitative approach

Lambda Protocol Overlaps with Systems Engineering Industrial Strength Requirements for

Software Intensive Systems-of-Systems

What is a requirement?

A property that must be exhibited by a system to solve some problem.

Requirements may be • Functional providing product capabilities

• Non-Functional constraining the implementation

Robust Requirements

Volume

Dynamic Range

Ideal

Discrete Specifications

RobustRequirements

Simplified Spiral Model

Determine objectives, alternatives, constraints1 Evaluate alternatives;

identify and resolve risks2

Develop and verify next-level product3Plan next phase4

Cumulative CostProgress through steps

Commitment Partition

Review

Spiral Model

Determine objectives, alternatives, constraints1 Evaluate alternatives;

identify and resolve risks2

Develop and verify next-level product3

Plan next phase4

Cumulative CostProgress through steps

Commitment Partition

Review

Requirements Plan; Life-cycle plan

Concept of Operation

Risk Analysis Prototype

1Prototype

2Prototype

3Operational Prototype

Simulations, models, benchmarks

Software Requirements

Risk Analysis

Risk Analysis

Risk Analysis

Req.s Validation

Development Plan

Integration and Test Plan

Software Product Design

Design Validation and Verification

Detailed Design

Code

Unit Test

Integration and Test

Acceptance Test

Implementation

From Boehm (1988), p. 64From Boehm (1988), p. 64

Project uncertainty

Relative Cost Range x

1.25x

1.5x

2x

4x

0.8x

0.5x

0.25x

0.67x

Phases and Milestones

Feasibility

Concept of Operation

Plans and Requirements

Requirements Specifications

Product Design

Product Design Specifications

Detailed Design

Detailed Design Specifications

Development and Test

Accepted Software

SEI Capability Model

Level 1Initial

Process81%

Ad Hoc, chaotic

Level 2Repeatable

Process12%

Intuitive, dependent on talented individuals

Level 3DefinedProcess

7%

Process defined & institutionalized, reliable cost & schedule

Level 4ManagedProcess

0%Reasonable control over quality, measured process

Level 5Optimizing

Process0% Adaptive feedback

process

Source: Andriole, Stephen J., Managing System Requirements, Methods,

Tools, and CasesMcGraw-Hill, 1996

Source: Andriole, Stephen J., Managing System Requirements, Methods,

Tools, and CasesMcGraw-Hill, 1996

Key Process Areas

Configuration ManagementQuality AssuranceSubcontract ManagementProject planning, tracking, & oversightRequirements management

Peer reviews & training programInter-group coordinationProduct engineeringProcess definition & focusIntegrated software management

Software quality managementQuantitative process management

Process change managementTechnology change managementDefect prevention

Top Ten Software Risk Items

Category Risk Item

People 1. Personnel Shortfalls

2. Unrealistic Schedules and Budgets

Requirements 3. Developing the Wrong Software Functions

4. Developing the Wrong User Interface

5. Gold Plating

6. Continuing Stream of Requirements Changes

Externalities 7. Shortfalls in Externally-Furnished Component

8. Shortfalls in Externally-Performed Tasks

Technology 9. Real-Time Performance Shortfalls

10. Straining Computer Science Capabilities

From Boehm (1988), p. 6From Boehm (1988), p. 6

Creeping featurism

Endemic to the Software Industry• Occurs on more than 70% of all applications over 1000 function points

From a 60 project sample

• Average creep = 35%

• Maximum = 200%

• Creeping requirements change about 1% per month» For a 3 year project, 1/3 of the delivered requirements will

be added after requirements are baselined. Rate of software requirements change is higher than for other

engineering fields (electrical, mechanical, civil).

Source: Assessment and Control of Software Risks,

Capers Jones, 1994

Source: Assessment and Control of Software Risks,

Capers Jones, 1994It’s only software!

What drives creeping featurism?

Not knowing real user needs, not their wants. Changes in normal business environment Solution changes nature of business Economic downturns. Failure to adopt processes designed to limit creeping

featurism Primitive technologies for exploring and modeling

requirements Failure to use technology to measure the impact of

creeping requirementsSource: Assessment and Control of

Software Risks,Capers Jones, 1994

Source: Assessment and Control of Software Risks,

Capers Jones, 1994

Managing requirements

Create and invoke the MOV. Establish, update and model the business case . Strategic linkages to business and technology

organizations to AVOID SHELFWARE Continuous customer agreement on requirements Requirements agreement used as a basis for estimating,

planning, implementing and tracking FORMAL COMMITMENT PROCESS

Source: Andriole, Stephen J., Managing System Requirements, Methods, Tools, and CasesMcGraw-Hill, 1996

Requirements engineering process

Requirements ElicitationRequirements Elicitation

Requirements Analysis & Negotiation

Requirements Analysis & Negotiation

Agreed Requirements

Draft Requirements Document

Requirements Document & Validation Report

Informal Statement of Requirements

Decision Point: Accept Document or re-enter spiral

Requirements SpecificationRequirements Specification

Requirements ValidationRequirements Validation

Process Models Process Actors and

Stakeholders Process Support and

Management Process Quality and

Improvements Relationship to the

Business Decision

QSE Lambda Protocol

Prospectus Measurable Operational Value Prototyping and Modeling sQFD Schedule, Staffing, Quality Estimates ICED-T Trade-off Analysis

As of 31 August

Universal Software Engineering Equation

Reliability (t) = ℮ -k t

when the error rate is constant and where k is a normalizing constant for a software shop and

= Complexity/ effectiveness x staffing

Case Study: SchedulerPro Prospectus

User friendly, efficient interface for students to create and modify class schedules.

Features:• Visual schedule creation and editing

• Schedule suggestion

• Schedule comparison view

• Monitor closed-out sections

SchedulerPro Prototype

SchedulerPro Prototype Iterated

SchedulerPro Notification Emails

SchedulerPro MOV

Course scheduling and registration time reduced by an average of 20 minutes per student per semester.

SchedulerPro features

Schedule Classes and Personal Time

Searching

Course Placement

Course Detail Viewing

Course Removal

Scheduling Personal Blocks

Notification (optional)

Course Suggestions (optional)

SchedulerPro Functional Requirements

• Search available classes by: Same professor Similar time Same or equivalent class but different sections

• Register and track registrations

• Color classes and arbitrary time-blocks by user choice

SchedulerPro nonfunctional requirements

• Integrate with “Web for Students’ and existing authentication systems and avoid incompatibilities

• Allow schedules to be saved/accessed from a server or local file

• Provide a scaled time-accurate visual representation of the schedule

More non-feature requirements

Make schedules available even if the application is down, provided an internet connection is available

Perform some functions without a live connection to the ‘Web for Students’ registrar web site

Make compatible with all popular browsers• Display section states and print schedules without

loss of detail

SchedulerPro sQFD

Features / Functions

Class FiltersAllocate non-class

timeLong term information

availabilityAuthenticate

Makes scheduling classes easier 8 3 6 2 19

Makes scheduling a semester easier

7 9 8 2 26

Find schedules in one place 1 1 5 7 14

Total 16 13 19 11 59

Jan. Function Point estimates

Function Low (L) Average (A) High (H) Total

Outputs 1 3 0 19

Inquiries 8 4 1 49

Inputs 5 7 1 41

Internal Files 3 2 0 24

External Interfaces 2 1 0 10

Total UFP 143

Adjustment Factor 0.99

Total AFP 141

April Function Point estimates

Function Low Average High Total

Outputs 1 0 1 9

Inquiries 3 0 0 9

Inputs 2 3 0 18

Internal Files 3 1 0 31

External Interfaces 1 1 0 12

Total UFP 79

AFP 82

History of Function Point estimates

Date AFP Project Length*

Projected Finish*

January 27 141 19.7 staff months

August 2006

February 24 104 14.4 staff months

March 2006

April 17 82 8.5 staff months

May

2006

*Using COCOMO Model

Web Point estimates

Function Total Web Objects

Outputs 11

Inquiries 9

Inputs 18

Internal Files 31

External Interfaces 12

# Multimedia files 6

# Web building blocks 7

# Scripts 3

# Links 0

Total Web Objects 97

Effort = A * cdi (Size)P1

Because it is a small web project, assume:

A=2.1, B=2.0, P1=1.00, and P2=.5

Language Expansion Factor = 25

From this, we estimate 2.43 KLOC

Effort = A* KLOC = 2.1 * 2.43

= 5.103= 5.103 staff-months staff-months Duration =B * EffortP2 = 2.0 * 5.103.5

= 4.5184.518 calendar months calendar months

ICED-T

Scheduling by:Intuitive Consistent Efficient Durable Thoughtful

Paper 3 2 2 2 3

Excel 3 2 3 3 3

School Scheduler 3 4 4 3 4

SchedulerPro 4 4 5 4 5

SchedulerPro Creeping Features

Are the System Admins important stakeholders?

You bet…

SchedulerPro Installation Plan

Installation

1. Third Party Software Required

Scheduler Pro requires the following products to be already installed on the target machine. Please consult the documentation of each product for installation instructions specific to each.

- Windows 2000, XP, or 2003 Server- Microsoft IIS, version 5.0 or higher- Microsoft .NET, version 1.1- Microsoft SQL Server 2000- Message Queuing Service (Windows component)- ASP.NET State Service

2. Installing the Scheduler Pro applicationTo install Scheduler Pro, please follow these steps:

I. Setting up the web site1. Create a virtual directory for the site in IIS2. Copy the contents of the “site” folder to the directory on your hard drive represented

by the IIS virtual directoryII. Setting up the database

1. Using the SQL Server Enterprise Manager tool, attach the database located under the “sqldb” directory.2. Create a new user account for accessing this database, and give it read/write access for the database.

III. Installing the Suggest, Notified, and Data Loader Windows ServicesOpen the directory titled “services”. Run each of these files: - InstallSuggestService.exe - InstallNotifierService.exe - InstallDataLoaderService.exe

Each installer will properly install the service. The Data Loader installer willalso ask you for the location and name of the course data file it will load.

SchedulerPro Installation Plan

SchedulerPro Installation Plan

3. Configuring Your InstallationOpen the directory where you installed the site files (step 2A above). Open the file “web.config”, and find the properties labeled “DBLocation”, “DBUser”, “DBPassword”, and “SecretAuthenticateKey”. These are set to default values that you should modify. Make sure that the location, username, and password match those you set up in SQL Server in step 2B above. Set SecretAuthenticateKey to the random string you are using in your authentication web page.

Technical Information

Scheduler Pro uses HTTP and XMLTHTTP protocols:

- HTTP: As a typical client/server application, an HTTP request is sent to server. Server processes the request and returns HTTP response.- XMLHTTP: client opens XMLHTTP connection to the server. Server executes query on the database and returns needed data.

Refer to Development view and process view from the “4+1” architecture views for further technical details.

Requirements Engineering(van Vliet, p.209)

Feedback

Domain Knowledge Domain Knowledge

User Rqtsuser

Problem domain

elicitation specification validation

Models to be Validated by user

Rqts Spec

Knowledge

Request moreKnowledge

models

Validationresults

More on Requirements

Requirements are the what and why but … “… it is an illusion to expect that perfect

requirements can be formulated ahead of time” - (Endres & Rombach, p. 15)

Outsourced products require careful requirements - key in today’s world

All stakeholders must participate

Importance of Requirements

Often too many, unstable due to late changes, ambiguous, incomplete

Glass: “Requirements deficiencies are the prime source of project failures.”

Boehm: “Errors are most frequent during the requirements and design activities and are more expensive the later they are removed.”

Cost of requirements errors increase with their longevity.

Some Success Processes

Should expend 15-30% of effort on requirements Requirements should be assigned priorities Traceability should be enforced throughout Validation and verification

What goes wrong

Miss or misunderstand a majority of the essential requirements - prototyping and other elicitation techniques are helpful

Endless requirements - requirements stages require a cutoff point

Sales team (or management) interferes and confuses what is desired with what is required

Spend too little time on user interface requirements - what does the user see in the end, eh?

Requirements Process

Elicit feature or functional requirements from the user (Boehm -as much as 40% of final features not in requirements specification)

Understand constraints and non-functional requirements - many are ‘ilities

Analyze the requirements (use cases) to make sure they flow and make sense

Develop prototype, model or user documentation Produce and control a requirements specification

Requirements Elicitation

Implicit conceptual model of users becomes explicit Requires us to become quick learners but Much of knowledge is

• Knowledge taken for granted• Tacit-knowledge skillfully applied in the background,

not verbalized• Involves habits, customs, inconsistencies• Influenced by frequency and recency• What’s needed may be different from what exists

Requirements Elicitation Techniques

Asking: interview, questionnaire, structured interview, Delphi (group based)

Task analysis: hierarchical decomposition Scenario based analysis: instances of tasks, use-

case (not only for OO) Ethnography: studying folks in natural setting Walking around Models

Requirements Elicitation Techniques

Form analysis: existing forms Natural language descriptions: training, manuals, Derivation from existing system Domain analysis: study existing systems w/in

domain, reuseable components Project future business enviornment from PMO

and systems

Requirements Elicitation Techniques

Business Process Redesign - radically redesign the processes, information processing systems should enable• At the very least rethink the existing

process Prototyping Usually a combination Panels of Subject Matter Experts

Requirements Analysis

1. Lambda Protocol2. Revise requirements as needed3. Redo and replan with GANTT chart 4. Review MOV and ICED-T to see if it is worth

doing

Cost of Big Requirements Up Front (BRUF)

Never45%

Rarely19%

Sometimes16%

Often13%

Always7%

Source: Jim Johnson of the Standish Group, Keynote Speech XP 2002

Feature usageEven “Successful” Projects Have Significant Waste

As of 9/26

Serial development is costly

Cost ofChange

Time

The Longer You Wait for Feedback, the more costs are sunk.

Business Analyst

Requirements Specifications

Questions Questions

A sometime facilitator between customers and developers.

Agile Values (www.agilealliance.org)

We value:1. Individuals and

interactions 2. Working software3. Customer collaboration4. Responding to change

Over:

1. Processes and tools

2. Comprehensive documentation

3. Contract negotiation

4. Following a plan

Some things are more important than others

Agile Principles 1-6

1. Satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Agile Principles 7-12

7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The

sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Communication Medium

Co

mm

un

ica

tio

n E

ffe

cti

ven

es

s

Richness of Communication ChannelCold Hot

Paper

Audiotape

Videotape

Emailconversation

Phoneconversation

Videoconversation

Face-to-faceconversation

Face-to-faceat whiteboard

DocumentationOptions

ModelingOptions

Misunderstandings about Agility

Ideas which are just plain crazy talk:• Agile = “code and fix”• XP is the only agile process• Agilists don’t document• Agilists don’t model• We’re ISO/CMM/6sigma therefore we can’t be agile• Agile results in low quality• Agile doesn’t scale• Agilists ignore enterprise concerns

Agile Software Requirements Management

{Each iteration implement the highest-priority requirements

Each new requirement is prioritized and added to the stack

Requirements may be reprioritized at any time

Requirements may be removed at any time

Requirements

HighPriority

LowPriority