CSC340 Frequently Asked Questions

General Questions

Q. The course information says we have to be in teams of 3. Can my mates and I work in a team of 4 (5,6,2...) instead?
A. Almost certainly not. By insisting on teams of three, we keep the difficulty of the exercises consistent for everybody. Different size teams represent different kinds of challenges in coordination, sharing of workload, etc. It is possible that the number of students on the course will not divide exactly by 3, in which case we might end up with one team of a different size, but don't count on it.

Assignment 1: Inspection of a Specification

Q. The assignment says we have to select an inspection process. What does this mean?
A. The choices of process model involve such things as how to structure the inspection meeting, how long to meet for, what roles each of you play, what kind of preparation you each do, whether you use checklists or other kinds of guide, and if so which ones, the kinds of form you need for recording the defects, and whether any adaptations are needed for these forms, and so on. The lecture on inspections described some of the possible choices for these process issues.
Q. Is what we're being asked to do a 'Fagan inspection'?
A. Yes (more or less). Although Fagan inspections were originally developed for inspecting code, the same basic principles apply to inspecting other things. The main emphasis in Fagan inspections is on studying the kinds of defects discovered, and using this to learn something about how to improve the processes of writing specifications, and the processes of inspecting them. That is precisely the reason for this assignment in this course - so that you learn something about how to write a good specification by critiquing an existing one. The fact that the assignment asks you to comment on the quality of the specification, and the lessons you learned in inspecting it emphasizes that this is a Fagan-style inspection.
Q. How will we know when we've found all the defects?
A. You won't. In fact, you cannot find all the defects. As there is no such thing as a perfect specification, there is no such thing as a complete list of defects. Remember, you are not graded by how many defects you find, but on your ability to select and conduct a good inspection process, and to report on what you learned by doing so. We do not have a master list of defects, anyway!
Q. If we find reference to hardware decisions in the specifications, are these defects?
A. That's a good question. I made a few comments in one of the lectures about the difference between software engineering and systems engineering. Basically, if you're doing software engineering, you assume the hardware environment is fixed (i.e. it is part of the domain properties) and your job is to find out what the software needs to do to fit within these constraints. However, if you're doing systems engineering, you take the whole software+hardware system as 'to-be-designed', and need to consider requirements for the whole thing. So, in answer to the question, decide whether the specification you are reviewing should properly be evaluated as a software requirements specification, or a system requirements specification (there's probably no right answer - use your judgement). Then you'll have a good basis for deciding whether descriptions about hardware in the specification really is a valid requirement, or whether it represents premature design commitments.
Q. Do we have to hand in the inspection log forms? Do these count in the eight page limit? Should we include a list of the defects found in the report?
A. You should include all the data you collected (i.e. the filled out forms) as appendices to your report. And as you are doing this, there is no point in repeating all the information in the main body of your report. But you should include some summarization of the defects found. E.g. if you categorized them, how many defects were discovered in each class? That kind of thing. Such statistics might tell you something interesting about either the specification itself, or your inspection process. For example, if one particular type of error is extremely common, is this because there is a flaw in how the team that wrote the spec approached the job, or is it because the inspection process you used made it easy to spot this particular type of error?
Q. Do we need to come up with a possible fix for each defect found?
A. No! Absolutely not. The whole point of inspection is to reveal defects, but not to correct them. Otherwise you won't have time to get beyond the first few defects. However, in your report, you can use your defect data to speculate on ways to prevent certain classes of defect from occuring in the future. This should be done after the inspection meeting, as you reflect on your findings. Remember, thinking up preventative measures is not the same as fixing the defects in the current specification.
Q. Is the 8 page limit for the report for single or double spaced type? Should it be in 10 or 12 point font? Should we write in the first person using "we", "us", etc.?
A. I have posted no specific requirements for these issues, because I don't have any. My only requirement is that the report be as readable as possible. So use sensible font sizes, include white space where it helps readability, and use whichever pronouns sound best. The only reason for the 8 page limit is to stop you writing too much. Remember, it is an upper limit, not a target length.

Assignment 2: Feasibility Study

Q: I have a friend who works for company X. Can I interview my friend and get all the data I need for the study, without having to go and talk to anyone else in company X?
A: No. While it is definitely a good idea to use your friends (and/or relatives) as contacts to get you initial access to an organisation that you can study, you will need to do more than just talk to your friend. Two issues arise: first, you will need to seek the consent of someone in a position of responsibility at the organisation to proceed with the study. It will involve accessing information that the organisation may regard as commercially sensitive. Second, for many of the reasons described in the lectures, you shouldn't rely on just information from just one person (i.e. your friend). You will need to talk to others at the organisation to ensure you have understood all the important aspects of the problem, and you'll probably also need to access documents and other sources of information.
Q: The company that we have contacted are worried about whether our report will reveal confidential information about them. What should we do?
A: You need to take some basic steps to protect their information. For example, in your reports, you can always use a fictitious name for the organisation, and for the people you have spoken to, to protect their identity. Offer to let someone in the organization read your report before you submit it for grading, so that that they can discuss any concerns with you before you finalize it. Note that this means you will need to have a fairly complete draft well before the course deadline, to allow them to review it in time. Discuss the timeline with them well ahead of the deadlines, so they know what to expect, and check that they will be able to review it in the timeframe you need.You could also offer to sign a non-disclosure agreement with the organisation, if that would make them feel more comfortable. Your reports will not be shown to anyone other than your TAs and the professor, unless we seek your permission first. (If your report is selected as one of the best, to be displayed on the course website, I will ask you first whether you and the organisation you worked with are comfortable with this).
Q: Our team has a started a project with an organisation that cannot disclose to us all the financial data we need for our feasilibility study. Other than that, the organisation is very keen to work with us. What should we do?
A: Go ahead with the study, and estimate any of the figures that they cannot share with you. Do the best you can in coming up with reasonable estimates, by doing a little research to see if you can get any comparison data from other projects. Be sure to describe in your report whatever data you used to help you make the estimates - e.g. if you found any comparison projects, figures on the web, examples in the textbook, etc. Do not just pluck numbers out of thin air - you must base them on some real data.
Q: Do we need to include any UML diagrams in our feasibility report?
A: (because I got the wrong answer before!) Yes. The assignment asks you to create activity diagrams and/or statechart diagrams to illustrate any important parts of the business processes that are relevant to the study. You should also use goal diagrams to demonstrate how the various options contribute to the goals of your stakeholders.
Q: Are goal diagrams part of UML?
No. The current UML standard does not include any notations for goal modelling. This means that there is no accepted standard for how to draw goal diagrams, so use whichever style you like best (e.g. the one I used in the lectures, or one of the styles from the readings). Be sure to pick one style, use it consistently, and provide a key for anyone not familiar with that style.

Assignment 3: Requirements Specification

Q: Is there a tool we can use for drawing UML diagrams?
A: Yes. We have two available on CDF: