soft 423: software requirements
TRANSCRIPT
SOFT 423: Software RequirementsCourse Basics
• Instructor • Eric J. Rapos, Teaching Fellow, PhD Candidate • 3rd Year PhD Candidate in Software Technology Lab, School of
Computing • I was probably the TA for most of you in CISC 327 last year • 9th years at Queen’s (finished BCmpH and MSc previously) • [email protected] • Office Hours:
• Wed: 1:00-2:00pm and by appointment • Office: Goodwin Hall Room 624
• Teaching Assistant • Saikat Das • [email protected]
2SOFT 423 – Winter 2015
•Location •Goodwin Hall 254
• (First is 9%, others are 5%)
• 3 Tests 24% • Final Exam 52%
•all tests & exams are closed book •Tests scheduled on following dates at beginning of
class (may be lecture following tests depending on material) •Wednesday Jan 21 – 2:30-3:00pm •Wednesday Feb 11 – 2:30-3:00pm •Monday Mar 16 – 3:30-4:00pm
4SOFT 423 – Winter 2015
Useful References
•An Introduction to Requirements Engineering by Ian K Bray •Software Requirements: Styles & Techniques by
Soren Lauesen •Requirements Engineering: Fundamentals,
Principles, and Techniques by Klaus Pohl •Requirements Engineering: Processes and
Techniques by Gerald Kotonya, Ian Sommerville •Software Requirements: Objects, Functions and
States (Revised Edition) (2nd Edition) by Alan M. Davis
5SOFT 423 – Winter 2015
•Slides adapted from content by:
•Thomas R. Dean Queen’s University •Jo Anne Atlee, Daniel Berry University of Waterloo •Steve Easterbrook University of Toronto
6SOFT 423 – Winter 2015
Overlap with Other Courses
•SOFT/CISC 325 – Human Computer Interaction •Elicitation
•CISC 422 - Formal Methods •Software Specification
7SOFT 423 – Winter 2015
8SOFT 423 – Winter 2015
•How Requirements fits into broader system engineering
•Importance of requirements documents
10SOFT 423 – Winter 2015
System Requirements
•Define what a system is required to do and the constraints under which it is required to operate •The system shall control the movement of the
telescope, keeping it aimed at given celestial objects, and moving it between celestial objects
•The system shall allow the user to specify the telescope position given by RA and Dec or by the stored coordinate of a stellar object
11SOFT 423 – Winter 2015
Definition of Requirements
•IEEE Standard Definition •A condition or capability that must be met or possessed by a system or system component in order to satisfy a contract, standard, specification or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component.
12SOFT 423 – Winter 2015
Types of Requirements
•The system shall control the movement of the telescope, keeping it aimed at given celestial objects, and moving it between celestial objects
•Very general requirement •Sets out in broad terms what the system should do
13SOFT 423 – Winter 2015
14SOFT 423 – Winter 2015
Types of Requirements
•The system shall allow the user to specify the telescope position given by RA and Dec or by the stored coordinate of a stellar object
•Functional Requirement •Defines part of system’s functionality
15SOFT 423 – Winter 2015
Types of Requirements
•The system shall be implemented on a intel or compatible laptop
•Implementation/Design requirement •constrains the acceptable implementation
16SOFT 423 – Winter 2015
Types of Requirements
•The system shall keep the telescope pointed within 1/2 arc second of the target coordinates
•performance requirement •minimal acceptable performance •Speed, Capacity •non-functional (also: security, reliability, usability)
17SOFT 423 – Winter 2015
Types of Requirements
•The system shall be menu driven and demonstrable in 1/2 hr
•Usability requirement •constraints on the interface of the system •also non-functional
18SOFT 423 – Winter 2015
Types of Requirements
•The telescope shall never be pointed closer than 5 degrees from the sun.
•Safety requirement •Constraint to protect the system or users of the system.
19SOFT 423 – Winter 2015
•The system shall cost less than $1000
•Commercial requirement •constraints on the cost of development or on the cost of the final system
20SOFT 423 – Winter 2015
•Increased reliance on software •consumer products
•Software now the biggest cost element for many mission critical systems •AATS, CAATS, DMV
•High Consequence of Failure •Ariane 5, Mars Observer, Beagle 2
•Factors •Certification costs, defect removal, changing
requirements
Importance of Requirements
•F-22 Raptor - 1.7 million lines of code Credit: Rob Shenk Great Falls, VA, USA
23SOFT 423 – Winter 2015
Importance of Requirements
•F-35 Lightning - 5.7 million lines of code Credit: Andy Wolfe, US Navy
24SOFT 423 – Winter 2015
Importance of Requirements
•787 Dreamliner - 6.5 million lines of code Credit: Wikipedia author Spaceaero2
25SOFT 423 – Winter 2015
26SOFT 423 – Winter 2015
•Increased reliance on software •consumer products
•Software now the biggest cost element for many mission critical systems •AATS, CAATS, DMV
•High Consequence of Failure •Ariane 5, Mars Observer, Beagle 2
•Factors •Certification costs, defect removal, changing
requirements
Requirements - Introduction
•What happens if they are wrong? •system may be late and over budget •system doesn’t meet needs, may even be
discarded •system may be unreliable
•75-85% of errors found in SW can be traced back to requirements and design [Barry Boehm 1981] •pretty good job of implementing what we think we want, but a lousy job of knowing what we want [Berry 2000]
28SOFT 423 – Winter 2015
Requirements - Introduction
•2 general sources of errors: •errors occur because the particular situation was not understood or expressed correctly (correctness)
•errors happen because the requirements do not mention the situation and the design and code does not plan for it. (completeness)
29SOFT 423 – Winter 2015
Requirements Problems
•Requirements don’t reflect the real needs of the customer of the system
•Requirements are inconsistent and/or incomplete
•Expensive to change requirements once everyone has agreed on them
•Misunderstandings between customers, requirement writers, and developers
30SOFT 423 – Winter 2015
•The process involved in developing system requirements •Engineering: systematic and repeatable techniques
•Bridge between the real world needs of users/customers and the developers and maintainers of the software systems •About 15-30% of system development costs
31SOFT 423 – Winter 2015
Requirements Engineering
•Scale Matters •Difficult to show in Academic Setting •Many of the projects and systems in an undergraduate program can be built without formal requirements •Many commercial system can be (and are) built without formal requirements
32SOFT 423 – Winter 2015
• government/military
•Very Large Systems (AATS, DMV) • Billions of Dollars, 10s of 1000s of developers
•Risk Systems • fly by wire systems • nuclear safety • ICU Medical Systems
33SOFT 423 – Winter 2015
•What is a requirements document? •official statement of systems requirements •many names: functional specification, requirements definition, SRS (system requirements specification) •forms the basis for future development. •purpose of this class...
34SOFT 423 – Winter 2015
Next Class
•A deeper look into the introduction to requirements, as well as definitions for the course: •Looking at types of systems •Requirements vs. design •Elicitation •Stakeholders
35SOFT 423 – Winter 2015
• Instructor • Eric J. Rapos, Teaching Fellow, PhD Candidate • 3rd Year PhD Candidate in Software Technology Lab, School of
Computing • I was probably the TA for most of you in CISC 327 last year • 9th years at Queen’s (finished BCmpH and MSc previously) • [email protected] • Office Hours:
• Wed: 1:00-2:00pm and by appointment • Office: Goodwin Hall Room 624
• Teaching Assistant • Saikat Das • [email protected]
2SOFT 423 – Winter 2015
•Location •Goodwin Hall 254
• (First is 9%, others are 5%)
• 3 Tests 24% • Final Exam 52%
•all tests & exams are closed book •Tests scheduled on following dates at beginning of
class (may be lecture following tests depending on material) •Wednesday Jan 21 – 2:30-3:00pm •Wednesday Feb 11 – 2:30-3:00pm •Monday Mar 16 – 3:30-4:00pm
4SOFT 423 – Winter 2015
Useful References
•An Introduction to Requirements Engineering by Ian K Bray •Software Requirements: Styles & Techniques by
Soren Lauesen •Requirements Engineering: Fundamentals,
Principles, and Techniques by Klaus Pohl •Requirements Engineering: Processes and
Techniques by Gerald Kotonya, Ian Sommerville •Software Requirements: Objects, Functions and
States (Revised Edition) (2nd Edition) by Alan M. Davis
5SOFT 423 – Winter 2015
•Slides adapted from content by:
•Thomas R. Dean Queen’s University •Jo Anne Atlee, Daniel Berry University of Waterloo •Steve Easterbrook University of Toronto
6SOFT 423 – Winter 2015
Overlap with Other Courses
•SOFT/CISC 325 – Human Computer Interaction •Elicitation
•CISC 422 - Formal Methods •Software Specification
7SOFT 423 – Winter 2015
8SOFT 423 – Winter 2015
•How Requirements fits into broader system engineering
•Importance of requirements documents
10SOFT 423 – Winter 2015
System Requirements
•Define what a system is required to do and the constraints under which it is required to operate •The system shall control the movement of the
telescope, keeping it aimed at given celestial objects, and moving it between celestial objects
•The system shall allow the user to specify the telescope position given by RA and Dec or by the stored coordinate of a stellar object
11SOFT 423 – Winter 2015
Definition of Requirements
•IEEE Standard Definition •A condition or capability that must be met or possessed by a system or system component in order to satisfy a contract, standard, specification or other formally imposed document. The set of all requirements forms the basis for subsequent development of the system or system component.
12SOFT 423 – Winter 2015
Types of Requirements
•The system shall control the movement of the telescope, keeping it aimed at given celestial objects, and moving it between celestial objects
•Very general requirement •Sets out in broad terms what the system should do
13SOFT 423 – Winter 2015
14SOFT 423 – Winter 2015
Types of Requirements
•The system shall allow the user to specify the telescope position given by RA and Dec or by the stored coordinate of a stellar object
•Functional Requirement •Defines part of system’s functionality
15SOFT 423 – Winter 2015
Types of Requirements
•The system shall be implemented on a intel or compatible laptop
•Implementation/Design requirement •constrains the acceptable implementation
16SOFT 423 – Winter 2015
Types of Requirements
•The system shall keep the telescope pointed within 1/2 arc second of the target coordinates
•performance requirement •minimal acceptable performance •Speed, Capacity •non-functional (also: security, reliability, usability)
17SOFT 423 – Winter 2015
Types of Requirements
•The system shall be menu driven and demonstrable in 1/2 hr
•Usability requirement •constraints on the interface of the system •also non-functional
18SOFT 423 – Winter 2015
Types of Requirements
•The telescope shall never be pointed closer than 5 degrees from the sun.
•Safety requirement •Constraint to protect the system or users of the system.
19SOFT 423 – Winter 2015
•The system shall cost less than $1000
•Commercial requirement •constraints on the cost of development or on the cost of the final system
20SOFT 423 – Winter 2015
•Increased reliance on software •consumer products
•Software now the biggest cost element for many mission critical systems •AATS, CAATS, DMV
•High Consequence of Failure •Ariane 5, Mars Observer, Beagle 2
•Factors •Certification costs, defect removal, changing
requirements
Importance of Requirements
•F-22 Raptor - 1.7 million lines of code Credit: Rob Shenk Great Falls, VA, USA
23SOFT 423 – Winter 2015
Importance of Requirements
•F-35 Lightning - 5.7 million lines of code Credit: Andy Wolfe, US Navy
24SOFT 423 – Winter 2015
Importance of Requirements
•787 Dreamliner - 6.5 million lines of code Credit: Wikipedia author Spaceaero2
25SOFT 423 – Winter 2015
26SOFT 423 – Winter 2015
•Increased reliance on software •consumer products
•Software now the biggest cost element for many mission critical systems •AATS, CAATS, DMV
•High Consequence of Failure •Ariane 5, Mars Observer, Beagle 2
•Factors •Certification costs, defect removal, changing
requirements
Requirements - Introduction
•What happens if they are wrong? •system may be late and over budget •system doesn’t meet needs, may even be
discarded •system may be unreliable
•75-85% of errors found in SW can be traced back to requirements and design [Barry Boehm 1981] •pretty good job of implementing what we think we want, but a lousy job of knowing what we want [Berry 2000]
28SOFT 423 – Winter 2015
Requirements - Introduction
•2 general sources of errors: •errors occur because the particular situation was not understood or expressed correctly (correctness)
•errors happen because the requirements do not mention the situation and the design and code does not plan for it. (completeness)
29SOFT 423 – Winter 2015
Requirements Problems
•Requirements don’t reflect the real needs of the customer of the system
•Requirements are inconsistent and/or incomplete
•Expensive to change requirements once everyone has agreed on them
•Misunderstandings between customers, requirement writers, and developers
30SOFT 423 – Winter 2015
•The process involved in developing system requirements •Engineering: systematic and repeatable techniques
•Bridge between the real world needs of users/customers and the developers and maintainers of the software systems •About 15-30% of system development costs
31SOFT 423 – Winter 2015
Requirements Engineering
•Scale Matters •Difficult to show in Academic Setting •Many of the projects and systems in an undergraduate program can be built without formal requirements •Many commercial system can be (and are) built without formal requirements
32SOFT 423 – Winter 2015
• government/military
•Very Large Systems (AATS, DMV) • Billions of Dollars, 10s of 1000s of developers
•Risk Systems • fly by wire systems • nuclear safety • ICU Medical Systems
33SOFT 423 – Winter 2015
•What is a requirements document? •official statement of systems requirements •many names: functional specification, requirements definition, SRS (system requirements specification) •forms the basis for future development. •purpose of this class...
34SOFT 423 – Winter 2015
Next Class
•A deeper look into the introduction to requirements, as well as definitions for the course: •Looking at types of systems •Requirements vs. design •Elicitation •Stakeholders
35SOFT 423 – Winter 2015