Criterion A - Planning

Instructions and Advice

(Firstly, do include your interview as the last part of this, rather than as an appendix. And put a clear "Not to be included in word count" ahead of it.)

- And with all documents - for each stage - do put your name at the top.

Problem Statement - A not-too-long statement of the problem you identified client has. This should refer in no way to the solution.

Description of Scenario - This is where you put the problem in context. This too should focus not so much on the solution as it does on the situation itself that presents the problem. So put another way, it puts the problem in a certain context.

Don't go into too many details, since you have to be conscious of your overall extended writing 2000 word limit. On the other hand, if you were doing this for a company, you would have to be detailed enough so that someone else in the company in another part of the world, or decades on, would be able to figure out what problem it was that you were trying to address. So talk about the organization, and the individual; what they do currently, and how they do it.


At this point, the students should make a file called "On-going Questions for Client", where they keep track of things needed to clarify various situations. This can go as an appendix.


Rationale for the Proposed Product- Why is a computer program a good approach toward a solution to the problem? And maybe also, why is a GUI application a good solution, and why is Java a good language to be using?

Note the bolded statement in the IB instructions: "with reference to the student’s consultations with the client and/or adviser, justifying how the choice of this particular product is an effective solution." That's The Main Thing.

Remember to include the word count for this section also, since it is extended writing.

(But note that we are now saying we should put the interviews right in Crit_A and Crit_B documents, and make a CLEAR note for the moderators that they should not count it in the word count. For A, it is best at the end of the document, for B, it will have to go where the prototype is.)


Prototype of the Product - Go to Netbeans, make a new application sample form and make a "prototype solution", that is a mock up of how you envision the application working. It will not have any code, just GUI elements. The idea is that you will show this to your client in a second interview where you propose a solution to the problem that arose in your fisrt conversation. Prototyping is a very crucial step to any design scenario, as it is where the producer and client communicate back and forth about how the final product is to look and work. Changes at this stage are a whole lot easier to make compared to after tons of coding has been done.

Using the prototype in the second interview: In a multi-tab application, each tab should be printed out and shown during the second interview. You will go over how you expect the application to function, and get comments and suggestions from your client. Put these ideas on the printed out screen shots with pencil or colored pen. This is the surest way to show that you actually did interect with the client. In fact, seeing two hand-writing styles is great too.


Success Criteria for Product- Here, in a bulleted list, you write the things that will be accomplished to declare your program a success when it is finished.

Criteria for success include things such as the following:

- all specific things that it does, for example save records of whatever to a file. Most of your success criteria will be these things that it does. (But don't just list simple things like what will be able to be input; rather focus on the main functionality; the things that the program will ***do***.)

For this, think of all the buttons and all the menu items that your program might likely have; each one of them should perform some specific thing, which will be its own success criteria point.

- how user friendly your program is, so for example, it has drop-down menus to make its use easier, or it has a help menu, or it comes with user documentation. (It's possible that your user doesn't require a user friendly program, but usually this is a good thing to consider.)

Extra usability Features:

Help button - pop-up
Hover thing
Fields demonstrate how to fill them in and clear when clicked.
Example shown.
Example described right under a text field.
Help menu
Combo boxes & other GUI elements themselves
Separate website help
Separate Help window (but how to close and not close the first window.)

See "DossierXYZ" for this, and also MrRayworthInstruction …… (?)

- error/exception handling - there are lots of specific coding examples of exception handling you can do, which you will see when you get to the programming "P" stage. But for now just try to think of all the basic ways your program might be mis-used, causing general errors which you can handle. For example, if a user leaves a textField empty, or types in a letter instead of a number.

- and possibly:

- a certain maximum time the program takes for doing certain things, such as sorting a big database under a certain number of seconds. This may only be important if there will be sophisticated processing.

- a certain maximum amount of RAM memory the program takes up, or a certain maximum amount of storage memory the program and the data file takes up. This would only be important in cases of huge amounts of data, and/or the possibility of using the program on either old computers, or small devices such as smart phones.

***Importantly*** these success criteria should also stem from the interviews you had with your user. So one way or the other, reference your conversations with your client. This can take the following forms:

--> foot-notes within your Success Criteria, referring to the interview(s). For example, Dr. Smith indicated that this process has to occur quickly, while his patients are in the office. 1

--> direct quotes from your interview(s) within the Success Criteria. For example: As Dr. Smith stated in interview #1,"'We need to be able to do this quickly, while our patients are in our office ".

--> more general reference to the interview(s). For example. It was clear in my interview with the client that this needs to be done quickly.

To strike a balance between too few & too general, and too many & too specific, try to stick to things that the user either said, or would say if you did a second interview and pressed them on specifics. So the bulleted list that you end up with should be in the "client's voice" as it were, in language the user would/could use.

So not "the program will use a binary search of an array of records to search the database with a Big O of log2n". Rather, "the user will be able to quickly search for their favorite chocolate from the list the input."

A good approach to this would be to start each criteria for success with "The user will be able to…" or something along those lines. The point is that the success criteria should be addressed from the perspective of the user; things that the user experiences, and possibly how fast/easily they experience these things.


1. Dr. Alan Smith, Interview 1, Appendix 1a