Lecture 3 requirements
1 / 34

Lecture 3 Requirements - PowerPoint PPT Presentation

  • Uploaded on

CS 540 – Quantitative Software Engineering. Lecture 3 Requirements. Software Requirements Process. Requirements Elicitation Requirements Analysis Use Cases Requirements Specification Prototype/Modeling Requirements Management. Highlights of quantitative approach. Lambda Protocol

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Lecture 3 Requirements' - sakina

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Software requirements process
Software Requirements Process

  • Requirements Elicitation

  • Requirements Analysis

  • Use Cases

  • Requirements Specification

  • Prototype/Modeling

  • Requirements Management

Highlights of quantitative approach
Highlights of quantitative approach

  • Lambda Protocol

  • Overlaps with Systems Engineering

  • Industrial Strength Requirements for

    Software Intensive Systems-of-Systems

What is a requirement
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

Lecture 3 requirements

Robust Requirements

Discrete Specifications





Dynamic Range

Spiral model
Spiral Model

Cumulative Cost

Determine objectives, alternatives, constraints

Progress through steps

Evaluate alternatives; identify and resolve risks



Risk Analysis

Risk Analysis

Risk Analysis

Risk Analysis

Prototype 1

Prototype 2

Prototype 3

Operational Prototype


Commitment Partition

Simulations, models, benchmarks

Requirements Plan; Life-cycle plan

Concept of Operation

Software Requirements

Detailed Design

Software Product Design


Development Plan

Req.s Validation

Unit Test

Integration and Test Plan

Design Validation and Verification

Integration and Test

Acceptance Test


Plan next phase


Develop and verify next-level product


From Boehm (1988), p. 64

Project uncertainty
Project uncertainty





Relative Cost Range





Concept of Operation

Requirements Specifications

Product Design Specifications

Detailed Design Specifications

Accepted Software



Plans and Requirements

Product Design

Detailed Design

Development and Test

Phases and Milestones

Sei capability model

Reasonable control over quality, measured process

Adaptive feedback process

Process defined & institutionalized, reliable cost & schedule

Level 4



Level 2



Level 3



Level 5







Intuitive, dependent on talented individuals

Level 1




Ad Hoc, chaotic

SEI Capability Model

Key Process Areas

Process change managementTechnology change managementDefect prevention

Software quality managementQuantitative process management

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

Configuration ManagementQuality AssuranceSubcontract ManagementProject planning, tracking, & oversightRequirements management

Source: Andriole, Stephen J., Managing

System Requirements, Methods,

Tools, and Cases

McGraw-Hill, 1996

Top ten software risk items
Top Ten Software Risk Items

From Boehm (1988), p. 6

Creeping featurism
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

It’s only software!

What drives creeping featurism
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 requirements

Source: Assessment and Control of

Software Risks,

Capers Jones, 1994

Managing requirements
Managing requirements

  • Create and invoke the MOV (Measurable Operational Value)

  • 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


Source: Andriole, Stephen J., Managing

System Requirements, Methods,

Tools, and Cases

McGraw-Hill, 1996

Requirements engineering process
Requirements engineering process

  • Process Models

  • Process Actors and Stakeholders

  • Process Support and Management

  • Process Quality and Improvements

  • Relationship to the Business Decision

Informal Statement of Requirements

Decision Point: Accept Document or re-enter spiral

Requirements Elicitation

Requirements Analysis & Negotiation

Requirements Document & Validation Report

Agreed Requirements

Requirements Validation

Requirements Specification

Draft Requirements Document

Qse lambda protocol
QSE Lambda Protocol

  • Prospectus

  • Measurable Operational Value

  • Prototyping and Modeling

  • sQFD: Simplified Quality Function Deployment

  • Schedule, Staffing, Quality Estimates

  • ICED-T: Intuitive, Consistent, Efficient, Durable and Thoughtful

  • Trade-off Analysis

As of 31 August

Requirements engineering van vliet p 209
Requirements Engineering(van Vliet, p.209)


User Rqts


Models to be

Validated by user

Rqts Spec








Request more


Problem domain

Domain Knowledge

Domain Knowledge

More on requirements
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
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
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
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
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
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
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 techniques1
Requirements Elicitation Techniques

  • Form analysis: existing forms

  • Natural language descriptions: training, manuals,

  • Derivation from existing system

  • Domain analysis: study existing systems w/in domain, reusable components

  • Project future business environment from PMO and systems

Requirements elicitation techniques2
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
Requirements Analysis

  • Lambda Protocol

  • Revise requirements as needed

  • Redo and replan with GANTT chart

  • Review MOV and ICED-T to see if it is worth doing

Cost of big requirements up front bruf
Cost of Big Requirements Up Front (BRUF)

Even “Successful” Projects Have Significant Waste

Feature usage

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

As of 9/26

Serial development is costly
Serial development is costly

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

Business analyst
Business Analyst

A sometime facilitator between customers and developers.

Agile values www agilealliance org

We value:

Individuals and interactions

Working software

Customer collaboration

Responding to change


Processes and tools

Comprehensive documentation

Contract negotiation

Following a plan

Agile Values (www.agilealliance.org)

Some things are more important than others

Summary typical requirements specifications
Summary: Typical Requirements Specifications

  • Project/Feature Title: Identification (Release and Identifier) Author(s)

  • Scope and Purpose

  • Measurable Operational Value

  • Summary

  • Feature Description

  • Interfaces

  • Constraints

  • Non-functional Requirements (“ilities”)

  • Change log

  • Responses to the unexpected

  • Glossary/References

Summary requirements
Summary: Requirements

  • Software Requirement: property which must be exhibited by software developed or adapted to solve a particular problem

  • Fundamentals: Functional vs. non-functional, Quantifiable vs Qualifiable, Emergent vs. Basic

  • Four Phases: Elicitation, Analysis, Specifications, Validation

    • Elicitation: sources and techniques

    • Analysis: Classification, Modeling, Design, and Negotiation

    • Specifications: System Definition, Requirements Specifications

    • Validation: Requirements Reviews, Prototyping, Model Validation, Acceptance

  • Practical Considerations: Iteration, Change Management, Attributes, Traceability, Measurement

Summary requirements directions
Summary: Requirements Directions

  • Requirements elicitation and proposals have become part of “software services” and “system integration”

    • Business process analysis

    • Process re-engineering

    • Conceptual data modeling

    • Task and work-flow analysis

    • Request for Quotations/Request for Proposals

    • Information strategy planning

    • Enterprise Resource Management/Customer Relationship Management

  • Standards exist (i.e., IEEE 830) but very domain dependent

  • Provides communication vehicle customer-analyst/analyst-developer

  • Assignment: Read B&Y Chapter 3, MMM Chapter 3.

  • Search “Software Requirements”/ Review 3-5 websites for commercial products/ Reference your sites and provide overview of current products.