The Business Case for Requirements Engineering RE’2003 12 September 2003 Donald Firesmith Acquisition Improvement Team Acquisition Support Program Software Engineering Institute (SEI) Carnegie Mellon University Pittsburgh, PA 15213 © 2003 by Carnegie Mellon University

page 1

In a Nut Shell • Requirements first opportunity to screw up • Many requirements engineers aren’t • Requirements typically contain many defects • Requirements impact all down-stream work • Cost to fix defects increases rapidly the earlier they are introduced • Requirements primary reason for failure

© 2003 by Carnegie Mellon University

page 2

First Opportunity to Fail There are many chances to fail on any project: • Contracting • Requirements Engineering • Architecting • Design • Implementation • Integration • Testing • Etc. Requirements first engineering chance to fail. © 2003 by Carnegie Mellon University

page 3

Many Requirements Engineers Aren’t Requirement Myth: • Since most requirements are specified in narrative English and most employees are minimally literate, managers often think that anyone (including low-level new hires) can do requirements engineering. Requirements engineers lack training in: • Requirements Tasks: • Requirements Identification • Requirements Analysis • Requirements Specification • Requirements Management • Requirements Techniques (e.g., use case modeling) • Requirements Tools © 2003 by Carnegie Mellon University

page 4

Requirements Contain Defects The percentage of defects originating during requirements engineering are estimated as: • 50% (Karl Wiegers, 2001) • 42% (A Wingrove) • 60-64% (requirements and design – EBG Consulting) Requirements typically lack: • Cohesiveness, Completeness, Correctness, Consistency, Currency, Essential, Feasibility, Lack of Ambiguity, Relevance, Testability, Usability, Validatability

© 2003 by Carnegie Mellon University

page 5

Requirements Engineering Impacts Requirements Engineering impacts: • Management (scope management) • Architecture (architecturally-significant requirements) • Design and Implementation • Testing • Quality Engineering (determines defects) • Safety Engineering (safety requirements) • Security Engineering (security requirements) • Reuse • Training Requirements Defects Snowball © 2003 by Carnegie Mellon University

page 6

Defect Costs Are Excessive Requirements engineering defects cost: • 50-200 times as much to correct once fielded. (Barry Boehm, 1988) • 10-100 times as much to correct once fielded (Steve McConnell, 2001) • 15 times as much to correct once fielded (IBM System Sciences Institute – all defects so requirements worse) • 10 times as much to correct during testing (Hughes Aircraft) Reworking requirements defects on most software development projects cost: • 40-50% of the effort (Capers Jones) • 80% of the effort (Karl Wiegers, 2001) © 2003 by Carnegie Mellon University

page 7

Bad Requirements Cause Failures Requirements problems are the single number one cause of project failure: • Significantly over budget • Significantly past schedule • Significantly reduced scope • Poor quality applications • Not significantly used once delivered • Cancelled © 2003 by Carnegie Mellon University

page 8

Conclusion Requirements Engineering: • Starts project on the right foot • Turns requirements workers into trained requirements engineers • Eliminates and minimizes defects • Improves architecting, design, implementation, testing, QA, security, safety, etc. • Decreases development and lifecycle costs • Increases probability of success © 2003 by Carnegie Mellon University

page 9

Contact Information Donald Firesmith Senior Member of the Technical Staff Acquisition Improvement Team Acquisition Support Program Telephone: 412-268-6874 Email: [email protected] U.S. Mail: Software Engineering Institute (SEI) Carnegie Mellon University Pittsburgh, PA 15213-3890 World Wide Web: http://www.sei.cmu.edu/ http://www.donald-firesmith.com/ © 2003 by Carnegie Mellon University

page 10

The Business Case for Requirements Engineering - Software ...

Sep 12, 2003 - The Business Case for. Requirements Engineering ... Implementation. • Integration. • Testing ... (e.g., use case modeling). • Requirements Tools ...

314KB Sizes 4 Downloads 310 Views

Recommend Documents

Engineering Safety-Related Requirements for Software ...
May 15, 2005 - ABSTRACT. Many software-intensive systems have significant safety .... Systems (RHAS) Workshop, in Kyoto, Japan, IEEE Computer Society,.

Engineering Safety-Related Requirements for Software ...
Engineering Safety-Related Requirements for Software-Intensive Systems. 2 ... Safeware Engineering, “Safety-Critical Requirements Specification and Analysis.

Engineering Safety-Related Requirements for Software ...
Engineering Safety-Related Requirements for Software-Intensive Systems. 2. Topics .... “A hazard analysis shall be performed during early in the project.”.

Engineering Safety-Related Requirements for Software ...
Mar 9, 2006 - F. Brooks, No Silver Bullet, IEEE Computer, 1987 ... ○The system shall be easy to use. ... subsystem, software application, or component).

Engineering Safety- and Security-Related Requirements for Software ...
Feb 5, 2007 - the engineering discipline within systems/software engineering ..... Safety and. Security. Engineering. Event. Analysis. Danger. Analysis. Risk.

IEEE Recommended Practice for Software Requirements Specifications
James J. Longbucco. Dieter Look. John Lord. Stan Magee. David Maibor. Harold Mains. Robert A. Martin. Tomoo Matsubara. Mike McAndrew. Patrick D. McCray.

IEEE Recommended Practice for Software Requirements Specifications
Carl A. Singer. James M. Sivak. Richard S. Sky. Nancy M. Smith ..... hidden assumptions they may have. b) Have developers make correct design decisions and ...

Agile Software Requirements
and the Enterprise (Agile Software Development ... Enterprise (Agile Software Development Series), Full PDF Agile Software Requirements: Lean .... author of Managing the Design Factory; and leading expert on rapid product development.

Software Requirements Specification
and Defect are entities that implement create, read, update and delete actions, but .... public String createDomain(String domainName) – Method creates a new.