Prepared by Stephen M. Thebaut, Ph.D. University of Florida

Slides:



Advertisements
Similar presentations
Chapter 2: Software Process
Advertisements

Key Verbs in Written Response and Essay Questions Most questions contain a key verb or command term.
INFORMATION TECHNOLOGY IN BUSINESS AND SOCIETY SESSION 20 – HOW SOFTWARE IS MADE SEAN J. TAYLOR.
Software Requirements Thomas Alspaugh ICS Nov 5.
May 14, May 14, 2015May 14, 2015May 14, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa,
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
The Mythical Man-Month by Fred Brooks (I) Published 1975, Republished 1995 Experience managing the development of OS/360 in Central Argument –Large.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
SWE Introduction to Software Engineering
Requirement Engineering – A Roadmap
SE 555 – Software Requirements & Specifications Introduction
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 8: Modelling Interactions and Behaviour.
SoITSSpecifications of IT systems? 1 Specifications of IT systems checking and validating Jens Bennedsen and Peter Gorm Larsen
What are Requirements?. "The hardest single part of building a system is deciding what to build... No other part of the work so cripples the resulting.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Chapter 5 Software Requirements.
Software Engineering Saeed Akhtar The University of Lahore Lecture 7 Originally shared for: mashhoood.webs.com.
1 CSE 403 Software Requirements Reading: Pragmatic Programmer Ch. 7: Before the Project These lecture slides are copyright (C) Marty Stepp, 2007, with.
©Ian Sommerville 2000 Software Engineering. Chapter 6 Slide 1 Chapter 6 Software Requirements.
Requirements and Specifications Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 3.
 What is Modeling What is Modeling  Why do we Model Why do we Model  Models in OMT Models in OMT  Principles of Modeling Principles of Modeling 
Monday Session 1 – Introduction to the MYTC Forum Registration – Introduction to the ESRI Training Site Registration Starting a Course Learning Pathways.
CS5103 Software Engineering Lecture 03 Requirement Engineering.
1 EE29B Feisal Mohammed EE29B: Introduction to Software Engineering Feisal Mohammed Ph: x3156.
No Silver Bullet – Essence and Accident “Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will.
Requirements / Specifications. 01/18/10CS-499G2 Requirements Determine what the customer needs (wants) the software to do  What are requirements?  An.
Software Engineering REQUIREMENT ENGINEERING. Software Engineering Phases.
Lecture 4: Requirements Engineering COSI 120b, Principles of Software Engineering.
Requirements and Specifications Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 3.
Requirements Engineering Dr. Richard Jones
George Wang, Ph.D. COMP 380/L Lesson 2. Use Case Use cases are a way to capture system functionalities (i.e., functional requirements) Based on use case.
Introduction to Software Requirement Engineering Nisa’ul Hafidhoh Teknik Informatika
CS 389 – Software Engineering Lecture 2 – Part 2 Chapter 2 – Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.
REQUIREMENTS ANALYSIS CONCEPTS & PRINCIPLES. Requirement  IEEE defines Software Requirements as:  A condition or capability needed by user to solve.
Software Requirements Engineering (CS 708)
Requirements Elicitation Techniques
G&W Chapter 5: Starting Points Software Specification Lecture 12
Chapter 4 Requirements Engineering (1/3)
Chapter 4 – Requirements Engineering
Chapter 5 – Requirements Engineering
Requirements Validation – II
G&W Chapter 22: Test Cases Software Specification Lecture 29
(State) Model-Based Approaches I Software Specification Lecture 35
Pop Quiz Define/compare Reactive with Proactive (such as Risk Management) What is the difference between Product Quality and Process Quality? List any.
White-Box Testing Techniques IV
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Black-Box Testing Techniques I
Software Requirements
(State) Model-Based Approaches II Software Specification Lecture 36
Requirements and Specifications
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Requirements Engineering
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Follow the commands
Chapter 2 – Software Processes
Daniel Siahaan February 2012
Thebaut’s Guaranteed Method Software Specification Lecture 5
COMP 208/214/215/216 Lecture 3 Planning.
G&W Chapter 16: Constraints Software Specification Lecture 23
Software Engineering Furqan Rustam.
Essentials of Oral Defense (English/Chinese Translation)
Software Engineering Lecture #3
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Black-Box Testing Techniques II
Algebraic Specification Software Specification Lecture 34
G&W Preface Software Specification Lecture 4
Rapid software development
Prepared by Stephen M. Thebaut, Ph.D. University of Florida
Black-Box Testing Techniques II
G&W Chapter 15: Attributes Software Specification Lecture 22
Presentation transcript:

Prepared by Stephen M. Thebaut, Ph.D. University of Florida Why is Requirements Engineering Difficult? Software Specification Lecture 2 Prepared by Stephen M. Thebaut, Ph.D. University of Florida

Once upon a time, the IBM engineer who managed the development of OS/360 wrote… The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult… No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later. – Fred Brooks, “No Silver Bullet…”

So WHY is RE so hard? Difficulty of anticipation Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”) Conflicts between & among users and procurers Fragmented nature of requirements Complexity / number of distinct requirements for large or complex systems

an·tic·i·pa·tion [an-tis-uh-pey-shuhn] noun, 14th century 1. a prior action that takes into account or forestalls a later action; 2. the act of looking forward; 3. visualization of a future event or state. We can never know about the days to come, but we think about them anyway…Anticipation, anticipation is makin' me late, Is keepin' me waitin’. -Carly Simon

So WHY is RE so hard? Difficulty of anticipation Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”) Conflicts between & among users and procurers Fragmented nature of requirements Complexity / number of distinct requirements for large or complex systems

So WHY is RE so hard? Difficulty of anticipation Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”) Conflicts between & among users and procurers Fragmented nature of requirements Complexity / number of distinct requirements for large or complex systems

So WHY is RE so hard? Difficulty of anticipation Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”) Conflicts between & among users and procurers Fragmented nature of requirements Complexity / number of distinct requirements for large or complex systems

So WHY is RE so hard? Difficulty of anticipation Unknown or conflicting requirements / priorities (“I’ll know what I want when I see it.”) Conflicts between & among users and procurers Fragmented nature of requirements Complexity / number of distinct requirements for large or complex systems

So WHY is RE so hard? (cont’d) Some analogies: Working a dynamically changing jigsaw puzzle Blind men describing an elephant Different medical specialists describing an ill patient

The terminology problem: problem definition problem specification requirements (functional or non-functional) requirements definition requirements specification requirements analysis systems analysis specifications (functional or non-functional) software specifications systems specification design specifications

Requirement: ...something required; something wanted or needed; an essential requisite. Elicit: ...to draw forth or bring out; to derive by reason or argument; to evoke.

Analysis: ...separation of a whole into its component parts; an examination of a complex, its elements, and their relations; resolving complex expressions into simpler or more basic ones; clarification of an expression by an elucidation of its use in discourse. Specify: ...to name; to state explicitly or in (sufficient) detail.

Prepared by Stephen M. Thebaut, Ph.D. University of Florida Why is Requirements Engineering Difficult? Software Specification Lecture 2 Prepared by Stephen M. Thebaut, Ph.D. University of Florida