CSC340 Frequently Asked 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
- 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
- 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
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
- 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
- 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
- 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:
- Rational Rose is a full featured UML modelling tool.
It has way more features than you'll ever need, but it is the industry
standard. Rose is available on the solaris workstations in BA3185 and
BA3195, or can be run from the solaris server, eddie.cdf.toronto.edu.
The command to run it is: rose.
- ArgoUML is a free UML editor, which is much easier
to use. ArgoUML is installed on both solaris and linux, and the command
to run it is: argouml