Assignment 1

Handouts from the lecture can be found here.

Software Engineering Spring 2009

Requirements Engineering

Normally, requirements engineering begins with a feasibility study or market analysis, and interviewing (potential) users about their needs. We do not have time to start from scratch. Therefore you get an input document, which is the assignment to the Methods of Programming course. Your task is to reshape part of this document into a well-organized requirements specification.

The following information in the input document must not be included in the requirements specification.

Things that have to do with administration of the MP2-assignment, grading, late assignments, etc.
What is listed in chapter 2 under "Part 1", "Part 4" and "Part 5".
The mathematics of ray tracing (chapters 3 - 8)
The details of the PPM and XML formats

So the requirements should cover the functionality of part 2 and part 3 in one document. You should be able to identify which functionality is required in part 2, in order to decide if you must test the functionality in assignment 3. All functionality must be tested in assignment 4.

Organisation, following Sommerville Figure 6.17

Preface (formalities: what is this document?)
Introduction (what is a ray-tracer and why would you want one, other than to pass Methods of Programming?)
Glossary
User Requirements definition - Omitted. This doucment would normally be produced before your input document.
System architecture - Omitted. The architecture is small, and use of libraries is left to MP.
System Requirements Specification. This is the core of your work.
System models. Draw a small data-flow model.
System evolution. Here you are allowed to speculate about possible extensions. Don't make too much of this.
Appendices. Probably not needed. In real life, the chapters in the input document that outline the mathematics of ray-tracing and the PPM and XML formats would go here.
Index.

Issues

Proper document identification (authors, versions, change history and so on)
Proper organisation of the requirements specification
Requirements are correctly identified (functional/nonfunctional, product/process, etc.)
Requirements for exceptional cases (such as limits on values, and behaviour if these limits are exceeded)
Traceability - in various forms - is supported
Testability - just ask yourself each time: "how would I test this requirement"?

Since this is a rather small system, learning to use a specialized CASE tool does not pay off. You are free to use the tools you want.

Administrative

The assignment is made in groups of three. You are welcome to discuss the assignment with others if it helps you clarify your thinking, but submit your own work!
Deadline: 13/2 at 17:00.
You must write in English.