Section 1 - Discussion
The Eduqas specification says:
a) Describe, to others, the broad aims and limitations of the project.
b) Identify and describe, to others, the possible limitations of a solution to the problem.
c) Consider and use feedback from others to refine understanding of the problem and proposed solution.
Things to consider doing:.
i) You should have an initial meeting with your user, to get background information on them, the organisation and the problem area. Plan the questions before the interview - what exactly do you need to know so you can write it down later in your report? Keep notes (or ask if it's okay to record the interview on your phone). Keep a diary with key events and dates.
ii) Put a heading, Introduction.
iii) Introduce the person or people you are designing a solution for, their jobs or roles and responsibilities. Introduce the organisation and the background to the problem. Paint the bigger picture. Aim to get any reader of your report to understand the context of the problem area, where the problem area fits in with the organisation. Something as simple as a photo of the people involved or of the department or a company's building can help do this as well as a few paragraphs. This should be no more than a side of A4, including a photo.
iv) Put a heading, 1a Aims and limitations of the project.
v) From the general description above, you should then describe the problem area that you will investigate. What are you going to look at? What sort of things do you hope to be able to do. Identify in general terms some things that can't be done now, either that the customer wishes they could do but there isn't time, or some things that might be useful but would create a project that is too large to complete in the time available. Don't be too specific at this point - you haven't investigated the problem area in detail yet so you don't want to be writing too much about it.
vi) Put a heading, 1b Possible limitations of a solution to the problem.
vii) A limitation is simply something that your system can't do, that if it could, it would be very useful. As you haven't investigated the problem area in any detail yet, it will be difficult to know the limitations of any solution that might emerge! However, you can have a good guess at what some of them might be. For example:
You could give some examples of some features that would be useful but you won't include because they couldn't be completed in the timeframe of the project.
You could talk about focusing on a particular area of the project and ensuring that that is working perfectly, rather than trying to do to much, and again, you need to give one or two examples.
You could discuss the fact that will be using made-up data to test your system, rather than actual data, because you are not allowed access to real student data, for example. This may mean that some of your testing may not test some occurances of data that you had not considered before.
You discuss the fact that you will be developing the system on a school computer but it won't be actually deployed onto a user's computer. If you did, it might throw up problem areas that can't be identified by just working on a school computer.
viii) Put a heading, 1c Using feedback.
ix) You are being asked to use feedback to refine your understanding of the problem and the proposed solution. Although you haven't investigated the problem fully yet or come up with a solution, you should have talked to your user about the problem area and should discussed general ideas about a solution. You could provide evidence of refining your understanding of the problem and your outline approach by producing a diagram of the problem, perhaps on an A3 sheet. In very broad, general terms, you could on one sheet draw boxes to represent different screens, add a few details to describe each box, show how they are linked, explain what they do and anything else that you know. Use colour, stickmen, cut out pictures, draw arrows and anything else you know up to this point. In other words, you can draw a non-technical 'rich picture' that you can then take back to your user to discuss and to check you have fully understood correctly what they have already told you. Take note of their comments and then include the very first interview with your user, the rich picture and the subsequent comments as the evidence for this section.
x) Remember, you haven't investigate the problem fully yet and don't know fully what the requirements are. You only know what the problem area is and may have an idea about how you will go about solving the problem. This means that you must not go into too much detail in Section 1.