owned this note
owned this note
Published
Linked with GitHub
# Computer Science Internal Assessment. Criterion A
:::success
This is part of a series of notes on the Internal Assessment on the Diploma Program of IB. **Last assessment 2026. (old syllabus)**
You can check the index with all the others and the rest of teaching material [here](https://hackmd.io/68GDv_RgT-yh9oERMvdnFw?both#Internal-Assessment-new-syllabus-May-2027)
:::
What is expected from the student in this criterion is deliver at least 2 files.
First in criterion A.pdf
a) Identify an scenario, with a client or an advisor
b) Declare the solution to the problem faced in the scenario.
c) Write a rationale of why that solution is a good and fitted solution.
d) Write **in a list** success criteria for that solution to be a success.
Then in the second file, it can be a pdf or an audio ther will be proof of consultation. Client's interview 1 is a good name for the file. (Or Advisor's interview 1)
:::danger
Remember to hide all the names in your internal, including the evidence of consultation
:::
Now, in detail
## The scenario
The scenario has to be framed as a problem that can be solved using some sort of program. Can be a website, a mobile app, a robot, a desktop program, a microcontroller system or a combination of them.
In this scenario the student needs to identify the **client** and, if applicable, the **advisor**
What do we mean by a scenario.
An scenario is a description of a problem, of a real life need that somebody (even the student) has. This happens in a _specific_ context.
:::danger
We cannot have scenario for "imaginary" or "potential" people that can use the product. For example, we cannot create a videogame for ages 10-14 because it's just a potential. We cannot also create a greenhouse robot for using in Venus since we're not going to Venus (even if it would be cool to imagine how to make it)
:::
A specific scenario can be solved using different solutions. After some discussion, the student will propose one. That will be the product developed.
## The client and the advisor
Once you have the scenario, we need to be specific about any client or relevant advisor.

:::warning
:warning: :warning: :warning:
Remember that personal information should be hided. If your client is your parent called Jesús Frías, in the Internal should be refered as "my parent", not by name. This includes the interviews.
:warning: :warning: :warning:
:::
The client is the person that has the problem that we're going to help with and has the details not about how to **create** the assigment but what is suposed to **do**.
:::info
In this case imagine a chef that needs an special type of knife. The chef know what are the requirements and specification of the knive but they are not suposed to know about metallurgy.

Chef that needs a knife _[source](https://www.flickr.com/photos/mexbeadyeyes/32441069667)_

Metallurgy _[source](https://www.stockvault.net/photo/205184/molten-metal)_
:::
With your client/advisor you need to have an interview (or several if you need more details and/or feedback). These interviews (can be in any language, can be just the record in an audio file) are not evaluated but they need to be there to prove that you have done them.
What you need to state in the scenario is that you understand the scenario and the needs from your client. For having extra marks quote your client/advisor regarding the scenario (the problem that they have), not the possible solution.
So the idea of doing this interview is finding the needs of the client and all the possible specifications. From that you will decide one of the possible solutions and what will be the success criteria that fits the needs of the client (or suggestions of the advisor)
## Proposed solution and rationale
The student will need to specify the solution that will fit the needs of their client. You will need to be very specific about it. "It's going to be a webapp done in $nameOfTheProgrammingLanguage using $nameOfTheFramework" or "it's going to be a game of $specifiType using $gameEngine".
Then a rationale is expected. Why are you using this (or these) tools and why do they fit for the scenario. This is important to get higher grades. For example, for doing a PH monitor system in a pool you can write something like "it's sensible to use a Raspberry Pi because it can hold in itself the Input from the sensor and also deploy a webapp to be accessed by other computers (or smartphones) used by my family. The framework for the webapp is () and I'm using it because ()""
## Success Criteria
These are a collection of success criteria that need to meet a few requisites.
* **Substantial.** The success criteria need to be part of the global function of the product. An example of substantial success criteria are features spected from the context. If I'm doing a system for measuring the PH of a pool, being able to measure it is a substantial part of the product. Stating that the color of a button of a menu should be red is specific, is testable but is not substantial enough.
* **Specific.** The success criteria need to be specific for the purpose of the IA. An example can be of very specific features is being able to show in the screen the data collected from the internet. Saying "the program will have no bugs" is testable, is substantial but is not specific enough.
* **Testable.** The success criteria need to be testable because later you need to do a test plan and actually test your program with no doubts. This is to avoid "the game is fun" or "it has an intersting aesthetic" that are very difficult to test. It's possible to test if the game has enough levels or options on the menu or if the aesthetic is something specific (for example the aesthetic is from vaporware aseshtetic, modernism or heavy metal).
You will need a list from 6 to 8 success criteria.
These success criterion can be thought of _features_ of your product. Your product probably will be able to be divided in different _features_ that also can be helpful for development (so you only work on a feature at a time).
:::info
:warning: :warning: :warning:
The success criteria are very important because they impact in 4 criteria of the IA. A, B, D and E.
:warning: :warning: :warning:
:::
### Ideas for your Success criteria
This is a non-exhaustive list of some examples.
* Usually for the products that include 1 hardware component (robotics, microcontrollers) there is 1 hardware success criteria. For example for a system to light a backyard we can have a success criteria "The product will be deployed so it can be inspected and the lights illuminate all the backyard properly"
* For the products that include a database, one of the success criteria is the posibility of doing the CRUD operations (Create, Read, Update and Delete). In the case of a recipe manager, one of the success criteria "the client can use the webapp to read/create/update and delete recipes directly from the web". Databases usually requires another consultation with the client/advisor to gather more information about the specifics of the scenario.
* Many webapps have different users with different privileges. This can be one of the success criteria. In an application for managing math homework from students a success criteria can be "There is 2 types of user, one that is a teacher who can update the homework and correct the homework submitted to the students"
* Also in many databases there is some kind of conclusion to achieve with the data. Displaying this data can be a success criterion. For example in a game created to train for being better at Valorant, having access to statistics of the different training course is substantial for the success of the product. These types of statistics usually requires another session with the client for getting more details on what is relevant in the scenario.
* In some cases the aesthetic is relevant, for example doing a videogame for a child. This can be one of the success criteria, but remember to keep it testable, specific and substantial. For example "The videogame should have an aquathic theme that resembles Finding Nemo" (in the scenario there should be some mention in why the Finding Nemo)
### Example of a game
Instead of "player can adjust the difficulty of the bots" you can write "there are different levels of difficulty for the bots that are going to change $a $b or $c "
Usually in games you can have one success criteria regarding aesthetics. These aesthetics should be also testable, specific and substantial. So instead "there is a good mood in the game for my little sister" this can be written as "the game should have an aesthetic similar to Cartoon Saloon movies and sounds"
## Word counting
This is one of the criteria that has word count. I reccomend to include the word count at the end of the document.
The word count of this criterion should be between 450 and 550 words approx. Excluding the SC (they don't seem to count to the limit)
## The boundaries from the IB guide

