University of Toronto University of Toronto Department of Computer Science Department of Computer Science About the Course Course website www cs toronto edu sme CSC340F CSC340 Requirements Engineering Textbooks Fundamentals of Requirements Engineering UML Distilled Lecture Notes Available on the course website prior to each lecture Prof Steve Easterbrook sme cs toronto edu Coursework Carried out in teams of 3 Each team submits one report per assignment http www cs toronto edu sme CSC340F All team members receive the same grade exceptions can be negotiated Involves a practical real world analysis project 1 Easterbrook 2004 5 University of Toronto University of Toronto Department of Computer Science Course Objectives Examine the state of the art for research practice in Requirements Engineering 4 team assignments 1 Conduct an inspection of an existing specification 10 Report on defects found overall quality and inspection stats 2 Perform a feasibility study for an information systems project 15 Current techniques notations methods processes and tools used in RE Write a feasibility report Gain practical experience in selected RE techniques 3 Perform a requirements analysis for the same project 10 Produce models that explain the problem Especially goal oriented and object oriented modelling techniques Department of Computer Science Assessment Role of RE in software and systems engineering 2 Easterbrook 2004 5 4 Specify the requirements for the same project 10 Understand the essential nature of RE Write a requirements specification Breadth of skills needed for RE and the many disciplines on which it draws Contextual factors practicalities 2 tests Midterm test 20 Final Exam 35 Must obtain at least 40 on this exam to pass the course Easterbrook 2004 5 3 Easterbrook 2004 5 4 1 University of Toronto University of Toronto Department of Computer Science Course Policies Software Intensive Systems Assignment Deadlines Software is an abstract description of a set of computations Assignments are due in the first 10 minutes of a tutorial Software only becomes useful when run on some hardware we sometimes take the hardware for granted Software Hardware Computer System Re grading Will only be done by the professor TAs will not re grade your work A Computer System on its own is useless Only useful in the context of some human activity that it can support The whole report will be re graded not just individual sections we sometimes take the human context for granted Your mark may go up or down Software on its own is useless Are very strict use a U of T medical certificate if you are seriously ill Daily penalties apply to late work Department of Computer Science A new computer system will change human activities in significant ways Communication Software Hardware Human Activities Software Intensive System TAs and instructor will not answer any queries related to the assignments in the 24 hour period prior to the deadline Software makes many things possible It is complex and adaptable Announcements will appear on the course website Please check it regularly It can be rapidly changed on the fly It turns general purpose hardware into a huge variety of useful machines 5 Easterbrook 2004 5 University of Toronto Department of Computer Science University of Toronto Quality Fitness for purpose 6 Easterbrook 2004 5 Department of Computer Science Where are the challenges Software technology is everywhere Application Domain Machine Domain 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 Easterbrook 2004 5 7 Easterbrook 2004 5 8 2 University of Toronto University of Toronto Department of Computer Science Complexity of Purpose Dealing with problem complexity People and software are closely coupled Abstraction Complex modes of interaction Ignore detail to see the big picture Long duration of interaction Treat objects as the same by ignoring certain differences Mixed initiative interaction beware every abstraction involves choice over what is important Socially situated interaction software systems and human activity shape each other in complex ways Department of Computer Science Decomposition Partition a problem into independent pieces to study separately The problems we d like software to solve are wicked beware the parts are rarely independent really No definitive formulation of the problem No stopping rule each solution leads to new insights Projection Separate different concerns views and describe them separately Solutions are not right or wrong Different from decomposition as it does not partition the problem space No objective test of how good a solution is subjective judgment needed beware different views will be inconsistent most of the time 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 dimensions Modularization Choose structures that are stable over time to localize change beware any structure will make some changes easier and others harder 9 Easterbrook 2004 5 University of Toronto University of Toronto Department of Computer Science Designing for people What is the real goal of software design Generic software components E g Core operating system functions network services middleware Making human activities more effective efficient safe enjoyable Functionality relatively stable determined by technical interfaces But note that these systems still affect human activity How rational is the design process E g concepts of a file a URL etc Hard systems view Software problems can be decomposed systematically The requirements can be represented formally in a specification Control Systems E g aircraft flight control industrial process control This specification can be validated to ensure it is correct Most requirements
View Full Document
Unlocking...