DOC PREVIEW
Toronto CSC 340 - CSC 340 - Requirements Engineering

This preview shows page 1 out of 4 pages.

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

Unformatted text preview:

1© Easterbrook 2004-51University of TorontoDepartment of Computer ScienceCSC340:Requirements EngineeringProf Steve [email protected]://www.cs.toronto.edu/~sme/CSC340FUniversity of TorontoDepartment of Computer Science© Easterbrook 2004-52About the Course Course website www.cs.toronto.edu/~sme/CSC340F/ Textbooks Fundamentals of Requirements Engineering UML Distilled Lecture Notes Available on the course website prior to each lecture Coursework Carried out in teams of 3 Each team submits one report (per assignment) All team members receive the same grade (exceptions can be negotiated) Involves a practical “real-world” analysis projectUniversity of TorontoDepartment of Computer Science© Easterbrook 2004-53Course Objectives Examine the state-of-the-art for research &practice in Requirements Engineering. Role of RE in software and systems engineering Current techniques, notations, methods, processes and tools used in RE Gain practical experience in selected RE techniques Especially goal-oriented and object-oriented modelling techniques Understand the essential nature of RE Breadth of skills needed for RE, and the many disciplines on which it draws Contextual factors & practicalitiesUniversity of TorontoDepartment of Computer Science© Easterbrook 2004-54Assessment 4 team assignments:1. Conduct an inspection of an existing specification (10%) Report on defects found, overall quality, and inspection stats2. Perform a feasibility study for an information systems project (15%) Write a feasibility report3. Perform a requirements analysis for the same project (10%) Produce models that explain the problem4. Specify the requirements for the same project (10%) Write a requirements specification 2 tests: Midterm test (20%) Final Exam (35%) Must obtain at least 40% on this exam to pass the course.2University of TorontoDepartment of Computer Science© Easterbrook 2004-55Course Policies Assignment Deadlines Are very strict (use a U of T medical certificate if you are seriously ill) Assignments are due in the first 10 minutes of a tutorial Daily penalties apply to late work Re-grading Will only be done by the professor (TAs will not re-grade your work) The whole report will be re-graded (not just individual sections) Your mark may go up or down Communication TAs and instructor will not answer any queries related to the assignments inthe 24 hour period prior to the deadline Announcements will appear on the course website. Please check it regularly.University of TorontoDepartment of Computer Science© Easterbrook 2004-56Software-Intensive Systems Software (on its own) is useless Software is an abstract description of a set of computations Software only becomes useful when run on some hardware we sometimes take the hardware for granted Software + Hardware = “Computer System” A Computer System (on its own) is useless Only useful in the context of some human activity that it can support we sometimes take the human context for granted A new computer system will change human activities in significant ways Software + Hardware + Human Activities = “Software-Intensive System” ‘Software’ makes many things possible It is complex and adaptable It can be rapidly changed on-the-fly It turns general-purpose hardware into a huge variety of useful machinesUniversity of TorontoDepartment of Computer Science© Easterbrook 2004-57Quality = 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 ofbanks and the needs of their customers The purpose is often complex: Many different kinds of people and activities Conflicting interests among themUniversity of TorontoDepartment of Computer Science© Easterbrook 2004-58Where are the challenges?Application Domain Machine Domain3University of TorontoDepartment of Computer Science© Easterbrook 2004-59Complexity of Purpose People and software are closely-coupled Complex modes of interaction Long duration of interaction Mixed-initiative interaction Socially-situated interaction …software systems and human activity shape each other in complex ways The problems we’d like software to solve are “wicked” No definitive formulation of the problem No stopping rule (each solution leads to new insights) Solutions are not right or wrong No objective test of how good a solution is (subjective judgment needed) Each problem is unique (no other problem is exactly like it) Each problem can be treated as a symptom of another problem Problems often have strong political, ethical or professional dimensionsUniversity of TorontoDepartment of Computer Science© Easterbrook 2004-510Dealing with problem complexity Abstraction Ignore detail to see the big picture Treat objects as the same by ignoring certain differences (beware: every abstraction involves choice over what is important) Decomposition Partition a problem into independent pieces, to study separately (beware: the parts are rarely independent really) Projection Separate different concerns (views) and describe them separately Different from decomposition as it does not partition the problem space (beware: different views will be inconsistent most of the time) Modularization Choose structures that are stable over time, to localize change (beware: any structure will make some changes easier and others harder)University of TorontoDepartment of Computer Science© Easterbrook 2004-511Designing 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:


View Full Document

Toronto CSC 340 - CSC 340 - Requirements Engineering

Documents in this Course
Scoping

Scoping

10 pages

Load more
Download CSC 340 - Requirements Engineering
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 CSC 340 - Requirements Engineering 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 CSC 340 - Requirements Engineering 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?