COM1028 Software Engineering

Project Part 1

COM1028 Software Engineering Coursework 2014
Ioana Sporea 1


Submission Deadline for Part 1: Tuesday 26
th
of August at 4pm via SurreyLearn
Weighting for Part 1: 30% of the module assessment

Academic Misconduct: Coursework will be routinely checked for academic misconduct.
Your submission must be your own work. Please read the Student Handbook to ensure
that you know what this means.
1. Purpose of the Resit Part 1 ......................................................................................... 1
2. Problem Definition ..................................................................................................... 1
3. Modelling the requirements (10%) ............................................................................ 1
4. Modelling the use case(s) (10%) ................................................................................ 2
5. Modelling the UI (5%) ............................................................................................... 2
6. Clarifying your assumptions that may impact on a design (5%) ............................... 3
7. How will your assignment be marked? ...................................................................... 3
8. What to Submit?......................................................................................................... 3

1. Purpose of the Resit Part 1
The purpose is that you can demonstrate an understanding of being able to take a given a
weak problem definition, clarify it, and turn it into a list of requirements, be able to mock up
a UI, and make clear the list of assumptions that you are going through your mind in order
which youd need to think about if you were taking the requirements to the next stage of
development.

2. Problem Definition
The following is the repetitive and clearly wrong problem definition but gives a
basis for the problem definition that you will need to come up with: Twice a year the
Department has a Christmas dinner and we want to be able to have a system for choosing
the menu options for a person and be able to use it yearly. Once the administrator knows
how many are coming she needs to work out how many drinks to order and of what type.
The dietary requirements of anyone need to be made clear and consequently they may not
always be able to have something from the list. Every time a person uses the system the
choices of a person are recorded. Everybody can come, PhD students and staff.
Additionally, the administrator requires a summary is provided of how many of which dish
is needed. Typically, it will be three or maybe even six courses that we eat. Once the
administrator doesnt know how many are coming she needs to work out what type of
drinks to order. The date for knowing how many come is typically two weeks after the
dinner. Every year we go to a different restaurant and the menu changes.

3. Modelling the requirements (10%)
Provide a Software Requirements Specification. The requirements should be written in
English using the recommended IEEE Requirements Specification Standard, as given in
the lecture notes. It will contain a table of contents, overview of the system, functional
requirements etc. It need not contain all the sections. Pick the ones that are relevant to
you.
COM1028 Software Engineering Coursework 2014
Ioana Sporea 2

Your overview of your system needs to restate the problem definition making it clearer,
elaborating on any details and improving its structure. You can change the scope of it
if you wish. But be careful if you narrow the scope too much then it will become too simple.
For example, it is going to be a mobile app, a J ava application.
Also is the person going to choose or is the administrator doing it for them? This will
impact on how you write the requirements.
You can write the functional requirements in terms of system/user, or group them in
different features, e.g., admin features, etc. They need to meet the guiding principles we
discussed in the lectures. You will need to think about what information the system will
need to store.

4. Modelling the use case(s) (10%)

The above is a partial and incorrect use case diagram.
Complete the use case diagram to reflect all the behaviour from the problem
description.
For each use case provide accompanying documentation for the Use Cases
(pre/post/description of purpose) using the template that you can find in one of the
tutorials.

You might think that writing up what a Use Case does is repeating what is said in your
requirements specification but it is different because it will form the basis of how you will
write your test scenarios.

5. Modelling the UI (5%)
Having modelled your requirements as a specification and using documented use cases
you are required to provide a UI to give a visual representation of your concepts. So this is
NOT like a prototype as you did in your previous attempt at Part1. I just want to see a
mock up of the UIs they need NOT be done using code.
Produce screenshots of a suitable UI for your application
Describe in a few paragraphs why you think this UI is good and how it enables you
to capture all the requirements related to the user in your system. (Hint: in these
paragraphs you should refer to things that make good UI which is appropriate for
the size and complexity of the system that you have. So I would suggest that you
read around the topic to give your ideas that will help you to provide your
justification:
o http://msdn.microsoft.com/enus/library/windows/desktop/ff728831%28v=vs.8
5%29.aspx/ [accessed
14/07/2013]
o http://www.nngroup.com/articles/ten-usability-heuristics/ [accessed
14/07/2013]
o http://goodui.org/ [accessed 14/07/2013]

COM1028 Software Engineering Coursework 2014
Ioana Sporea 3

6. Clarifying your assumptions that may impact on a design (5%)
List 5 points of things that you now have to think about in order to turn your
requirements into a design, implementation and test.

You need to write down the points and describe then in some detail with specific
reference to your requirements. I am not looking to read general statements that
could apply to any problem. I need it to be specific to your problem definition. I
would expect this to be around 1 page of A4.

(Hint: For example you could consider things like, what information will need to be
stored? What information will you load in dynamically into your system? How are
you going to capture this information? What patterns could be useful? How will you
make sure that your design is scalable? How will the UI you design impact on the
kinds of tests that you might write?)

7. How will your assignment be marked?
Grade descriptors are made available.

8. What to Submit?
For modelling the requirements of the system you are required to submit:
o The requirements specification (as a PDF document). Name this file as
username_reqspec.pdf (e.g., css2ht_reqspec.pdf).
o The Violet or Argo Use Case Diagram as a file that we can load. Name this
file as username_reqdiagram with the appropriate extension (e.g.
css2ht_reqdiagram.argo).
o The documentation for your Use Case diagram. There will be one page per
use case. If you are using Violet then this will be as a separate document (as
a PDF). Name this file as username_usecase.pdf (e.g., css2ht_usecase.pdf).
If you are using Argo then this could be done directly within the tool or as
PDF. If you are using the Argo tool itself then it will need to be as
comprehensive a documentation as providing it separately (i.e., with pre-post
condition descriptions etc.)
For the UI you are required to submit:
o a PDF document containing the screenshots and the paragraphs. Name this
file as username_ui.pdf (e.g., css2ht_ui.pdf).
For the clarification of assumptions you are required to submit:
o a PDF document. Name this file as username_clarification.pdf (e.g.,
css2ht_clarification.pdf).
Produce ONE zip file that contains all the above and name it
username_com1028_resitpart1.zip (e.g., css2ht_com1028_resitpart1.zip) and
upload this file to SurreyLearn.

Please use email me directly to ask any questions. No discussion board is being set up
for this assignment.