1. Unit 6: Application Development
Cambridge Technical Level 3: IT

2. Assessment Overview

3. Keywords and Definitions

4. Referencing Use the Harvard method of citation
A citation is the part of the reference that you include within the main body of your work whenever you directly quote from, paraphrase, summarise or refer to work produced by another author.
In the Harvard style, the citation includes the author's surname and year of publication.
Use this website to help you create them:

5. Task 2: P2, M2 Requirements document – P2
Design an interview (or multiple) for your client and end users, using a range of question styles. Make sure you cover all aspects of the product – You should explain what type of questions you have asked at each stage in your design.
Conduct the interview with your client and at least 1 end user, summarise your results
Create a functional requirements document
Document a-c in a report including: your interview findings, functional requirements, constraints of the project, limitations of the project
Feasibility study and proposed solutions – M2
Identify (at least) two potential solutions for the product. Include details such as the requirements they cover and the key features.
Create a feasibility study for each of the ideas – present these in a report – make sure you conclude with which idea you are using
Create a presentation to show the potential solutions to your client

6. P2 - Interviews
In the requirements analysis phase, the current application (or method of providing the same service) should be investigated. You will need to find out what the client and all potential end users require the application to do. You may also need to investigate the current methods of carrying out tasks or functions.
There are several different ways of gathering user requirements:
Client and End User interviews
Observations
Analysis of existing documents and systems

7. P2 – Interview Questions
Interviews are usually face-to-face with the client or the end user. There are two different types of question that you can ask:
Open – allow the interviewee to explain, give their opinion, or reflect on something. The interviewee usually responds with longer answers that you may ask subsequent questions on for further discussion and expansion. The answers provided can give depth and understanding but are more likely to be based on opinions than facts – this means they can be difficult to compare or produce statistical data from.
Closed – limit the response from your interviewee to selectable options, for example yes or no questions. The interviewee is not expected to expand or explain their answers. These questions give you facts that are easy to answer. The answers provide data that can be easily assessed and compared – for example the number of yes / no answers to a particular question.

8. P2 – Planning an Interview
You should use a mix of open and closed questions to get both depth and analysis from your interviews.
Problem! – Leading Questions
Try not to ask questions that lead the interviewee to a specific answers. The wording of a question may guide them to an answer that you are looking for – this can skew your results!

9. M2 - Functional Requirements
Functional Requirements identify what the new application need to do:
Data and Information collected in the current system
Data and Information collected in the new system
Functions of processes that the new application should perform
Outputs from the application
Core functional requirements
Optional functional requirements
User interface requirements, including accessibility requirements

10. M2 – Functional Requirements
Description
Data and Information collected in the current system
Identify the data that the current systems make use of, how this is used and where it comes from.
Data and Information collected in the new system
The new application may require different data from the existing system. For example some data may no longer be required, or it may come from a different place. There may also be some new data.
Functions of processes that the new application should perform
A list of measurable processes stating every function that the application needs to carry out.
Outputs from the application
Each output needs to be clearly identified, along with where its information comes from (how it is generated) what the output will look like, and who or where it will go.

11. M2 – Functional Requirements
Description
Data and Information collected in the current system
Identify the data that the current systems make use of, how this is used and where it comes from.
Optional functional requirements
The are the functions that are not fundamental to the application. For example the application will work (and be acceptable to the client) without them.
User interface requirements, including accessibility requirements
The type of interface will need determining and any additional requirements, such as style of input, methods of output, and accessibility options.

12. Task: Writing Interview questions
Write a mixture of closed and open interview questions for your interview.
Remember you are trying to discover:
Data and Information collected in the current system
Data and Information collected in the new system
Functions of processes that the new application should perform
Outputs from the application
Core functional requirements
Optional functional requirements
User interface requirements, including accessibility requirements
For example:
Who will use the application and when will they use it?
Will they only use it at the school?
Will they be able to use it at home on their own?
Tell me how you currently teach children English
Do you use interactive applications during your teaching
Do the students study outside of school?
How do you support students outside of school?

13. Task: Conduct your interview
Interview your client
Don’t forget you can go off-script and ‘funnel’ your answers:
Funnelling – where you ask follow up questions to get a deeper understanding.
For example:
Tell me how you currently teach children English
Do you use interactive applications during your teaching
Do the students study outside of school?
How do you support students outside of school?

14. Task: Functional Requirements
Write a functional requirements document based on the findings from your interview(s) – this should include a summary of your findings.

15. M2 - Constraints
A constraint is a restriction that limits what the solution can do, or how it has to be built. A range of constraints need to be considered – for example:
Hardware constraints – the hardware that the application will run on or make use of. It may be a constrain as the client may specify the hardware. E.g. new hardware that has to be purchased, or may not be purchased by the application designer. This may limit what the solution can do, as the hardware may not be powerful enough to perform some actions.
Software constraints – this is the software the application will use or interact with. The solution may interact with other software packages and may need to get data into or out of these applications.
Platform constraints – the platform is the make of hardware / operating system. Software that runs on one platform may not run on another. This could be a constraint because the organisation may only have access to one platform or they may only design it for one but expect it to work on another.
Development constraints – this may include things like the software being used to produce the system, for example if the client is familiar and experienced with a set of specific software they may use that – or they may have no experience and so this will form a constraint.

16. Task: Explain the constraints
Add these to your functional requirements report.
Ensure you cover the following themes:
Hardware
Software
Platform
Development
Time / Expertise / Budget
Resources required / available
Access to end users for testing

17. M2 - Limitations
A limitation restricts what is implemented. The scope of the solution is a limitation – it may restrict it to specific functions and confine what it can 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

18. Task: Limitations
Explain the limitations for your project in the functional requirements report
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.

19. M2 – Feasibility Study
This determines if it is possible (or viable) to develop a product or undertake a project. This is conducted after the requirements, constraints, and limitations, are known.
Feasibility studies consider:
Technological requirements – what the product will require to make / to use. Does the technology exist? Do you have access to it?
Economic or financial costs of development – You client will have a budget – you will need to consider if the costs of the project can be met within the budget to see if it is financially viable to run the project. The minimum viable product will need to be identified – this may require excluding some optional requirements to bring the cost down.
Legal issues – is there potential to infringe the Data Protection Act? Or the Copyright act? Think about where your data will be saved – who will have access to it – what data will you collect?
Operational impact – How will the running of the organisation change because of the product? Will they need to change any business practices? For example how they set homework or how they teach their lessons?
Scheduling and Resources – The schedule is in the timing – how long will it take to produce? Is there a set timeframe that needs to be met? Will this mean any optional features aren’t included? Resources can be technological or human – will you have access to the people or the technology to complete your project?
Some of the above may be negotiable (e.g. cost and timings) and the outline solutions may show the client what is possible if there is some flexibility (for example if you had more of a budget).

20. Task – Presentation for possible solutions
There could be several different solutions you could use using different pieces of hardware and software – could you create a mobile application? A desktop application? A console application? Each different solution will meet some (or all) of the requirements, and each may have additional constraints or limitations. – Do you have access to mobiles, desktops, or consoles?
Task:
Identify (at least) two potential solutions for the product. Include details such as the requirements they cover and the key features.
Create a feasibility study for each of the ideas – present these in a report – make sure you conclude with which idea you are using
Create a presentation to show the potential solutions to your client – this should include the potential benefits of each solution, and a summary of the feasibility of each solution.