lecture 3 requirements
Download
Skip this Video
Download Presentation
Lecture 3 Requirements

Loading in 2 Seconds...

play fullscreen
1 / 34

Lecture 3 Requirements - PowerPoint PPT Presentation


  • 107 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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
slide5

Robust Requirements

Discrete Specifications

Ideal

Volume

Robust

Requirements

Dynamic Range

spiral model
Spiral Model

Cumulative Cost

Determine objectives, alternatives, constraints

Progress through steps

Evaluate alternatives; identify and resolve risks

1

2

Risk Analysis

Risk Analysis

Risk Analysis

Risk Analysis

Prototype 1

Prototype 2

Prototype 3

Operational Prototype

Review

Commitment Partition

Simulations, models, benchmarks

Requirements Plan; Life-cycle plan

Concept of Operation

Software Requirements

Detailed Design

Software Product Design

Code

Development Plan

Req.s Validation

Unit Test

Integration and Test Plan

Design Validation and Verification

Integration and Test

Acceptance Test

4

Plan next phase

Implementation

Develop and verify next-level product

3

From Boehm (1988), p. 64

project uncertainty
Project uncertainty

4x

2x

1.5x

1.25x

Relative Cost Range

x

0.8x

0.67x

0.5x

Concept of Operation

Requirements Specifications

Product Design Specifications

Detailed Design Specifications

Accepted Software

0.25x

Feasibility

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

Managed

Process

Level 2

Repeatable

Process

Level 3

Defined

Process

Level 5

Optimizing

Process

0%

0%

12%

7%

Intuitive, dependent on talented individuals

Level 1

Initial

Process

81%

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
  • FORMAL COMMITMENT PROCESS

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

User Rqts

Feedback

Models to be

Validated by user

Rqts Spec

models

Knowledge

elicitation

specification

validation

Validation

results

Request more

Knowledge

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

Over:

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