CSC340 Requirements Engineering page 1/8 Faculty of Arts and Science University of Toronto Midterm Test Department: Computer Science Instructor: Steve Easterbrook Date and Time: 10:10am, Thursday Nov 10, 2005 Conditions: Closed Book Duration: 50 minutes This test counts for 20% of your final grade Name: _______________________________________________________ (Please underline last name) Student Number: _______________________________________________ Question Marks 1 ______________/20 2 ______________/20 3 ______________/20 4 ______________/20 Total___________/80 = _________%CSC340 Requirements Engineering page 2/8 1. [Short Questions; 20 marks total] (b) [Operational Feasibility – 5 marks] Operational feasibility refers to the likelihood that the proposed system, if built, can actually be used by its intended users to solve the original problem. What types of issues can affect the operational feasibility of a proposed system? User resistance – e.g. the users decide the system has a negative impact on them personally, and so find ways of avoiding using it Legal and social factors – e.g. the system would violate legal or social norms, for example by invading people’s privacy or data protection laws Labor objections – e.g. unions protest that the system causes an unacceptable change to working conditions, and threaten to strike in protest (etc) (b) [Systems Theory – 5 marks] In systems theory, a system may be described as a soft system or as a hard system. Explain each type of system, and give an example of each. Soft systems are systems that are difficult to define precisely, because the system depends on the viewpoint of the person describing it. If it is difficult or impossible to come to agreement on the boundaries of the system and its behavior, then the system is considered to be soft. All human activity systems are soft systems. For example, a banking system is a soft system. Hard systems are well-defined and it is relatively easy to get agreement on where the boundaries to the system are, and what the purpose of the system is. The key difference between soft and hard systems is the amount of consensus that can be reached. The mechanical operation of a car is an example of a hard system.CSC340 Requirements Engineering page 3/8 (c) [Formal Inspections – 5 marks] Name two different approaches for structuring the defect collection meeting during a requirements inspection. What are the advantages and disadvantages of each? Checklists – the inspectors take each item on the checklist in order, and discuss defects of that type no matter where they occur. This approach ensures the inspection covers all the different types of defect normally found in a document, so that important classes of defect are not neglected. However, it may mean some parts of the document are not covered well; if the checklist omits certain types of defect, these will not be discovered. Round Robin – the inspectors take it in turn to describe one of the defects they have found. This approach ensures that all inspectors get to contribute equally, so that the particular expertise of each inspector is taken into account. However, it means that the inspectors might not cover the whole document very well, or might miss certain classes of error. If the expertise/experience of one particular inspector is more important, this technique does not all the moderator to give that inspector more time. (d) [Requirements vs. Specifications – 5 marks] Michael Jackson has proposed a conception of requirements engineering that distinguishes machine domain phenomena from application domain phenomena, as illustrated in the following diagram: Explain the distinction Jackson makes between Requirements, R, and Specifications, S. What steps are needed to turn requirements into a specifications? Requirements are any properties of phenomena in the application domain that a stakeholder would like to be made true by some new system. Requirements may refer to any phenomena, whether accessible to the machine or not. Specifications are a subset of requirements, covering only phenomena that are shared between the application domain and the machine. A specification must be expressed only in terms of things the machine can accomplish by reference to its inputs and outputs. Hence, for each requirement, it is necessary to identify how the phenomena the stakeholders actually care about can be mapped onto inputs to outputs that the machine can manipulate.CSC340 Requirements Engineering page 4/8 2. [State Modelling – 20 marks] The following statechart diagram is a sketch of some of the behaviours of an iPod. a) Write down a sequence of events that will play a song (from the initial state). press any button; select song (this assumes that initially battery has power) b) What is the shortest sequence of events needed to get back to the playing state if the battery runs out connect; disconnect; select song c) What is the shortest sequence of events needed to select a different song while playing? connect; disconnect; select song (note: the model isn’t very accurate!) d) For each of these properties, state whether the property is true or false, and explain your reasoning: “the iPod remembers what song was playing when it is docked” False – the only path from the docked state requires you to select a song “the iPod remains in the sleep state if the battery dies” False – the “battery=0%” returns the iPod to the Off state from the sleep state. “sometimes you need to press play more than once to get it to play” True – from the sleep state, you need to press play twice. “there is no way to turn the iPod off other than running the battery down” True – You need to generate a “battery=0%” event to get back to the Off state e) What does the model say about what would happen if the battery dies while the iPod is docked? It ignores this case. If the battery is dead when you disconnect, the model says you go to the menus state, and then to the Off state immediately, implying the menu shows, if briefly. This might be okay if docking always provides a minimal charge. f) When you first buy an iPod it has no songs on it. How would you modify the model to include this situation? Add another state distinct from “off” to indicate “empty”. The iPod would start in this state, but would probably never return to it except perhaps for
View Full Document
Unlocking...