DOC PREVIEW
Toronto CSC 302 - Lecture 12 - Requirements Analysis

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1 Lecture 12:!Requirements Analysis"University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2 Quality = Fitness for purpose"Software technology is everywhere"Affects nearly all aspects of our lives"But our experience of software technology is often frustrating/disappointing"Software is designed for a purpose"If it doesnʼt work well then either:"…the designer didnʼt have an adequate understanding of the purpose"…or we are using the software for a purpose different from the intended one"Requirements analysis is about identifying this purpose"Inadequate understanding of the purpose leads to poor quality software"The purpose is found in human activities"E.g. Purpose of a banking system comes from the business activities of banks and the needs of their customers"The purpose is often complex:"Many different kinds of people and activities"Conflicting interests among them"2!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3 Designing for people"What is the real goal of software design?"Creating new programs, components, algorithms, user interfaces,…?"Making human activities more effective, efficient, safe, enjoyable,…?"How rational is the design process?"Hard systems view:"Software problems can be decomposed systematically"The requirements can be represented formally in a specification"This specification can be validated to ensure it is correct"A correct program is one that satisfies such a specification"Soft systems view:"Software development is embedded in a complex organizational context"There are multiple stakeholders with different values and goals"Software design is part of an ongoing learning process by the organization"Requirements can never be adequately captured in a specification"Participation of users and others throughout development is essential"Reconciliation:"Hard systems view okay if there is local consensus on the nature of the problem"University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 4 Separate the problem from the solution"Problem Statement Implementation Statement System Correspondence Correctness Validation Verification A separate problem description is useful:"It can be discussed with stakeholders"It can be used to evaluate design choices"It is a good source of test cases"Note: Most obvious problem might not the right one to solve"Still need to check:"Solution correctly solves the stated problem (verification)"Problem statement corresponds to the needs of the stakeholders (validation)"""Problem Situation3!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 5 Problem Situation But design changes the world…"abstract model of world implementation statement problem statement change System University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 6 Requirements as Theories"Prior Knowledge (e.g. customer feedback) Observe (what is wrong with the current system?) Model (describe/explain the observed problems) Design (invent a better system) Intervene (replace the old system) Note similarity with Process of scientific Investigation: Requirements models are theories about the world; Designs are tests of those theories Initial hypothesis Look for anomalies - what canʼt the current theory explain? Create/refine a better theory Design experiments to test the new theory Carry out the experiments4!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 7 A problem to describe…"E.g. “land a spacecraft on Mars”"Multi-threading gravity mission goals cost savings safety margins altitude landing sites project team processor load touch sensors thruster performance Exception handling Memory management Command sequences (Soft) timers things the software cannot observe directly things private to the software shared phenomena sensor failures University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 8 A problem to describe…"Donʼt overload the processors… "Donʼt use data from failed sensors…"Ignore noise on sensors when legs unfold…"Poll multiple sensors continually and compare results to test sensor function."Start using touchdown sensors at 12m above the surface"(Assumes legs have finished unfolding by then…)"gravity mission goals cost savings safety margins altitude landing sites project team processor load touch sensors thruster performance sensor failures Multi-threading Exception handling Memory management Command sequences (Soft) timers5!University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 9 D - domain properties R - requirements C - computers P - programs Thinking about Software Requirements"Domain Properties (assumptions):"things in the application domain that are true, whether or not we ever build the proposed system"(System) Requirements:"things in the application domain that we wish to be made true, by delivering the proposed system"May involve phenomena to which the machine has no access"A (Software) Specification:"a description of the behaviours that the program must have, in order to meet the requirements"Can only be written in terms of shared phenomena!"University of Toronto Department of Computer Science © 2012 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 10 Fitness for purpose?"Two


View Full Document

Toronto CSC 302 - Lecture 12 - Requirements Analysis

Documents in this Course
Load more
Download Lecture 12 - Requirements Analysis
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 12 - Requirements Analysis and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 12 - Requirements Analysis 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?