Comments on Project Drafts, 3/10

• Where to start: introduce the problem and the system you plan to build. Chapters 1 and 2 should be a preamble to the meat (requirements) in 3 and 4. Concentrate on a coherent introduction to your system that gets the reader ready to understand the requirements.
• Who is your audience? E.g. don't impose the vocabulary of the course. E.g. a context diagram is a good idea, but you don't need to label it as such. "Figure x shows how the ABC system interfaces with..."
• What to leave out. You may have built a lot of models (process, DFD, object hierarchy...) to help you understand the requirements but if they don't help the user read the requirements section, they don't need to be there.
• You should, however, describe the users and the what they will do with the system. Perhaps a viewpoint hierarchy and associated text.
• Refer to the Digicomp and McQuay documents for ideas.
• Include a table of contents and page numbers.
• Next: organizing the requirements.
• Functional: by what is done.
• Non functional: use the categories in the text.
• It is not necessary to explicitly label requirements as functional or non functionsl (see Digicomp and McQuay).
• Try to identify categories of requirement for Chapter 3.
• Put headings in, even if you haven't written the requirements.