The Design and Realisation Process

Written once, marked four times

Your project is written up in four sections: system planning, system development, system realisation, and evaluation. Everybody reads that as four jobs done one after another. Plan it, develop it, build it, then say how it went. ⚠️⚠️ IT IS NOT FOUR JOBS. IT IS ONE DOCUMENT WITH A SPINE RUNNING THROUGH IT, AND THE SPINE IS THE DESIGN SPECIFICATION. Watch what each section actually does with it. ⭐ PLANNING DERIVES THE SPECIFICATION. You analyse the problem and turn it into a list of things the finished system must do. ⭐ DEVELOPMENT PROPOSES SUB-SYSTEMS TO SATISFY IT. Every design decision is an answer to something on that list. ⭐ REALISATION TESTS THE BUILT SYSTEM AGAINST IT. You are not testing whether it works in general. You are testing whether it does the things you said it would. ⭐ AND EVALUATION JUDGES THE FINISHED THING AGAINST IT, and proposes improvements. ⚠️ FOUR SECTIONS, ONE DOCUMENT, POINTED AT FOUR TIMES. Now the consequence, and it is the reason this is worth a whole module rather than a page of headings. ⚠️⚠️ A VAGUE SPECIFICATION CANNOT BE EVALUATED. SO THE QUALITY OF YOUR FINAL SECTION IS DECIDED IN YOUR FIRST WEEK, BEFORE ANYTHING IS BUILT. Suppose your specification says the system must be reliable, easy to use and safe. Every one of those sounds sensible, and at the end you have nothing to measure. Was it reliable? Compared with what? For how long? You will end up writing that it worked quite well, which is an opinion, and opinions do not score in an evaluation. ⭐⭐ NOW SUPPOSE IT SAYS THE SYSTEM MUST OPERATE CONTINUOUSLY FOR AT LEAST AN HOUR WITHOUT RESETTING. NOW THERE IS SOMETHING TO DO: RUN IT FOR AN HOUR AND WRITE DOWN WHAT HAPPENED. THE EVALUATION WRITES ITSELF, AND IT IS EVIDENCE RATHER THAN OPINION. ⭐ SO HERE IS THE TEST TO PUT EVERY SPECIFICATION POINT THROUGH, AND IT TAKES ABOUT TWO SECONDS: COULD SOMEBODY ELSE CHECK WHETHER THIS WAS MET, WITHOUT ASKING ME WHAT I MEANT? If yes, it is a specification point. If no, it is a wish, and it will cost you marks at the far end of the project where you cannot see it coming. One honest note about this module. The building itself is coursework and cannot be practised here. What can be practised is the thinking that decides whether the build can be written up well, and that is where most marks are actually lost.

Four sections, one thread

What each section of the report is for, and what all four have in common.

Tap the two you could actually test

Tap the TWO specification points that somebody else could check without asking you what you meant.

• The system must run continuously for at least one hour without needing to be reset
• The finished circuit board must fit inside the case supplied with the project brief
• The system must be reliable in normal use
• The system should be easy for anybody to operate

Nothing to evaluate against

A student finishes a working system, then writes an evaluation saying it worked quite well and was fairly easy to use. The build was sound. Why does the evaluation score badly, and when did that become inevitable?

• Because the specification was written in terms nobody could measure, so there was never anything to judge the system against. It became inevitable when that specification was written, not when the evaluation was
• Because the evaluation is too short and needed more detail
• Because the build must have had faults the student did not notice
• Because the student should have run more tests at the end

Five terms for the project report

Five terms, each defined by what it is. The first is the document every other section points at.

Match each vague point to what it needs

Two that follow from a testable specification

Select the TWO statements that follow from every section of the report pointing back at the specification.

• Time spent making requirements measurable at the start buys marks in a section written months later
• A design decision can be justified by pointing at the specification point it answers, rather than by saying it seemed sensible
• A specification should be kept general so that the finished system is more likely to satisfy it
• The evaluation is written last, so it is the last thing that needs thinking about

Writing a specification somebody else could check

You may already have met the systems approach, where any electronic system is read as sub-systems passing a signal along. ⚠️ THAT IS HOW YOU PROPOSE A SOLUTION. THIS IS HOW YOU DECIDE WHAT THE SOLUTION HAS TO DO BEFORE YOU PROPOSE ANYTHING. A method for turning a problem into a specification worth having. ⭐ START WITH WHO IT IS FOR AND WHERE IT WILL BE USED. Most requirements fall out of that: how it is powered, how big it can be, what it has to survive, who has to operate it. ⭐⭐ WRITE EACH REQUIREMENT SO THAT SOMEBODY ELSE COULD CHECK IT. That usually means a NUMBER, a NAMED CONDITION, or a NAMED ACTION. Not fast but within a stated time. Not small but fitting inside a stated space. Not easy to use but a named person completing a named task. SEPARATE WHAT IT MUST DO FROM WHAT YOU WOULD LIKE IT TO DO, and say which is which, because an evaluation that misses a desirable extra is a different thing from one that misses an essential. ⭐ INCLUDE THE PRACTICAL CONSTRAINTS YOU ACTUALLY HAVE, such as the components available to you and the time you have got. A specification that ignores them produces a development section full of decisions you cannot defend. AND WRITE THE SAFETY POINTS AS SPECIFICALLY AS THE REST. ⚠️ A RISK STATEMENT NAMES A PARTICULAR HAZARD AND WHAT WILL BE DONE ABOUT IT. FOLLOW YOUR CENTRE'S OWN RULES AND YOUR TEACHER'S INSTRUCTIONS FOR THE PRACTICAL WORK ITSELF; THIS MODULE IS ABOUT HOW THE THINKING IS RECORDED, NOT ABOUT HOW TO WORK SAFELY. ⚠️ THREE HABITS THAT COST MARKS HERE. ⚠️ THE FIRST IS DESCRIBING YOUR IDEA INSTEAD OF STATING REQUIREMENTS. ⭐ A SPECIFICATION SAYS WHAT THE FINISHED THING MUST DO. IT DOES NOT SAY WHAT COMPONENTS YOU HAVE DECIDED TO USE, BECAUSE THAT DECISION HAS NOT BEEN JUSTIFIED YET. ⚠️ THE SECOND IS THE UNFALSIFIABLE POINT. Must work correctly. Must be well made. Nothing could show these were not met, so nothing can show they were. ⚠️ AND THE THIRD IS EVALUATING THE EXPERIENCE RATHER THAN THE SYSTEM. ⭐ SAYING YOU ENJOYED THE PROJECT, OR RAN SHORT OF TIME, IS NOT AN EVALUATION OF THE BUILT SYSTEM. GO THROUGH THE SPECIFICATION POINT BY POINT AND SAY WHAT THE TESTING SHOWED FOR EACH. One last thing that students find surprising. A requirement you failed to meet is not a disaster in the write-up. Reporting it accurately, explaining why, and proposing a specific improvement is worth considerably more than claiming everything worked.

One brief, two specifications

Here is an invented brief, written for practice. A community garden wants something that warns a volunteer when the water level in a rainwater butt has dropped below a set mark, so that they know to refill it. It will sit outdoors under a lid. The group has offered a nine volt supply and a plastic case measuring one hundred and twenty millimetres across. ⚠️ THOSE TWO NUMBERS ARE PART OF THE INVENTED BRIEF. THEY ARE NOT STANDARDS AND NOT DEFAULTS. ⭐ STUDENT A WRITES THIS SPECIFICATION. The system must detect the water level. It must warn the user. It must be reliable and safe. It must be easy to use and should look neat. Read it kindly: every point is sensible and not one of them is wrong. ⚠️⚠️ NOW IMAGINE WRITING THE FINAL SECTION FROM IT. DID IT DETECT THE WATER LEVEL? YES. WAS IT RELIABLE? WELL, IT SEEMED FINE. WAS IT EASY TO USE? THE PERSON WHO BUILT IT FOUND IT EASY. Every sentence has become an opinion, and there is no way to turn any of them into a measurement now, because the thing has already been built. ⭐⭐ STUDENT B WRITES THIS INSTEAD. The system must give a visible warning within five seconds of the water falling below the marked level. It must run from the nine volt supply provided. The completed board must fit inside the one hundred and twenty millimetre case with the lid closed. It must operate outdoors under a closed lid without the warning being triggered by rain falling on the sensor. A person who has not seen it before must be able to tell, at a glance, whether the butt needs refilling. ⭐ NOW LOOK AT WHAT HAS QUIETLY HAPPENED. EVERY ONE OF THOSE CAN BE CHECKED BY SOMEBODY WHO DOES NOT KNOW WHAT THE STUDENT MEANT. Somebody with a stopwatch can settle the first. A ruler settles the third. The fourth can be tried with a watering can. The last can be tried on an actual person who was not involved. ⚠️⚠️ AND NOTICE THE FOURTH POINT PARTICULARLY, BECAUSE IT CAME OUT OF THE CONTEXT RATHER THAN OUT OF THE ELECTRONICS. IT SITS OUTDOORS UNDER A LID. STUDENT A NEVER ASKED WHAT THE WEATHER WOULD DO TO IT, AND THAT IS THE KIND OF REQUIREMENT THAT IS DISCOVERED BY THINKING ABOUT WHO USES THE THING AND WHERE. ⭐⭐ BOTH STUDENTS MAY WELL BUILD THE SAME CIRCUIT. ONE OF THEM CAN PROVE IT DID THE JOB AND THE OTHER CAN ONLY SAY SO, AND THE DIFFERENCE WAS DECIDED BEFORE EITHER PICKED UP A SOLDERING IRON.

Order the design and realisation process

Put these six stages into the order the project actually runs in.

• Analyse the problem, its context and who the system is for
• Write a design specification of requirements somebody else could check
• Propose a system of sub-systems to satisfy the requirements, and predict how it should behave
• Develop and test the sub-systems separately before combining them
• Build and test the whole physical system, recording what the testing actually showed
• Judge the finished system against each specification point and propose specific improvements

Build a testable specification point

Turn a wish into a requirement. Assemble the point.

The design process run

Five questions on the thread running through the report. Three lives.

Complete the design process facts

An early working version built to find out whether an idea actually functions is a _____. A statement, written before testing begins, of what will be measured and how is a _____. A judgement of the finished system against the requirements set for it is an _____. A statement of what could cause harm during the work and what will be done about it is a _____.

Which section does this belong in

A student has written: I chose this arrangement because the specification required a warning within five seconds, and the alternative I tried was slower. Where does that sentence belong, and why?

• In system development, because it justifies a design decision by pointing at the requirement it answers and at what was rejected
• In the evaluation, because it mentions how well something performed
• In system planning, because it refers to the specification
• In system realisation, because it describes something that was tried

Three evaluations to make honest

Three students are writing up. Each has done real work, and each is about to lose marks for the same underlying reason.

• A student writes an evaluation saying the system worked well, was reliable, and that they were pleased with the result. What should they do instead?
• A student discovers during testing that the system misses one requirement in certain conditions. They are considering leaving it out of the report. What would you advise?
• A student writes a specification that begins by naming the components they intend to use. What is the problem?

Explain why the specification comes first

A friend is starting their project and wants to get straight to building. Explain why the design specification is worth real time first, and how to write one that will still be useful at the end of the project.

• Explain what each of the four report sections does with the specification, so the thread through them is clear
• Explain why a vague requirement leaves nothing to write in the evaluation months later
• Give the test a specification point should pass before it is written down
• Give one example of a woolly requirement and rewrite it so somebody else could check it
• Explain why naming chosen components in the specification causes trouble in the development section
• Finish by explaining why a requirement that was not met is worth reporting accurately rather than leaving out