Software Engineering Tutorial Full Course Lecture 1 Build Software People Can Trust

Software Engineering Tutorial - Full Course, Lecture 1: Build Software People Can Trust

Full tutorial link > https://www.youtube.com/watch?v=36YhAfCZrB4

Start the Software Engineering full course with Lecture 1 of 14. A booking screen says Confirmed, but can two people trust it for the same room and hour? Follow the fictional CampusRooms service to learn what makes software dependable.

Links:

SECourses Patreon: [ https://www.patreon.com/SECourses ]

Course repository and interactive lessons: [ https://github.com/FurkanGozukara/Software-Engineering-Full-Lecture-2026-2027-Fall ]

Lecture 1 PDF: [ https://github.com/FurkanGozukara/Software-Engineering-Full-Lecture-2026-2027-Fall/blob/main/site/pdf/week-01.pdf ]

SECourses Discord: [ https://discord.com/servers/software-engineering-courses-secourses-772774097734074388 ]

You will learn how to prevent conflicting confirmations, map system boundaries and stakeholders, test keyboard access, compare quality tradeoffs, find defects earlier, and keep support logs useful without collecting unnecessary information.

Main topics include requirements, shared decisions, dependencies, accessibility, correctness, privacy, maintainability, lifecycle feedback, testing and AI-assisted engineering.

Use the chapters to jump to each example and changed condition.

Chapters:

00:00:00 Meet CampusRooms and question a green confirmation

00:00:43 Ask what makes a booking confirmation trustworthy

00:01:44 Preview the fourteen weeks of engineering decisions

00:02:25 Connect familiar programs to dependable service behavior

00:03:38 Set five learning goals for this lecture

00:04:40 Follow two requests for the same room

00:05:41 Watch two screens confirm an overlapping booking

00:07:17 Read stored bookings and expose the conflict

00:08:18 Judge software behavior by its real consequences

00:09:19 Use one shared decision to protect bookings

00:10:31 Compare honest rejection with a false promise

00:11:48 Draw the system boundary around internal modules

00:12:38 Trace booking requests across identity and storage

00:13:42 Separate message types and clarify external dependencies

00:14:45 Keep confirmed bookings when notification delivery fails

00:16:23 Map stakeholders beyond the person clicking Reserve

00:17:28 Include support staff and future software maintainers

00:18:49 Find the Reserve button using only keys

00:19:51 Replace a painted control with accessible behavior

00:20:50 Treat accessibility as part of working software

00:21:37 Compare two designs beyond their response speed

00:22:41 Require correctness before comparing other quality attributes

00:23:15 Compare privacy and the cost of change

00:24:00 Name quality attributes using standard engineering vocabulary

00:24:51 Tighten response targets while preserving booking correctness

00:25:22 Optimize storage lookup or show an honest wait

00:26:13 Follow one defect through the engineering lifecycle

00:27:32 Revise the model and check notification behavior

00:28:42 Catch the same defect during integration checks

00:29:53 Discover missing behavior during a requirements conversation

00:31:03 Turn confident claims into specific testable checks

00:31:51 Check overlaps adjacent bookings and different rooms

00:32:34 Test simultaneous requests instead of assuming correctness

00:33:35 Inspect a support log containing unnecessary information

00:34:28 Trace privacy harm support effort and future costs

00:35:28 Keep only the fields needed for diagnosis

00:36:16 Add a room identifier for a justified question

00:37:17 Match engineering questions to useful visual representations

00:38:34 Choose a dependency map for boundary questions

00:39:17 Use sequence diagrams to explain event order

00:40:11 Check changes drafted by an automated assistant

00:40:55 Review eight principles for building dependable software

00:42:15 Answer four questions about the central ideas

00:43:26 Prepare for requirements and the next lecture

00:44:11 Explore practical tools for the course representations

00:44:31 Review key terms for discussing engineering decisions

00:45:06 Find the readings and standards behind the lesson

00:45:27 Connect dependable behavior to the course ahead

This video is for anyone learning to design, test and maintain software. Basic familiarity with functions and conditions helps; no installation is needed for this lecture. Later lectures follow the fourteen-week roadmap in the repository.

Music: Infinity, Serene View, Romantic 05, Relaxation 04, Digital Clouds, Your Breath, Stylz, Down the River, Vastness, Opalescent, Curiosity, Pilates and Yoga (Mixkit, Stock Music Free License).

For course updates and questions, see the pinned comment, Patreon, Discord and comments below.

Video Transcription

• 00:00:00 Greetings everyone. Today I am going to introduce  you to software engineering through 1 small  

• 00:00:07 service called Campus Rooms. It is a fictional  room booking service, and this is its booking  

• 00:00:13 screen. Everything on this screen is a teaching  example.Look at what the screen asks for. The  

• 00:00:21 room is C101, the date is today, and the  time is 10 to 11. Below the fields there is  

• 00:00:27 a Reserve button, and nothing else.So let's  do what any user would do. I click Reserve,  

• 00:00:34 and a green message appears: Confirmed,  C101, 10 to 11. Your booking  

• 00:00:40 is saved. A confirmation message is on its  way.Here is the question of this week. What  

• 00:00:46 would you need to see before you trust this  message? Option A, the green tick. Option B,  

• 00:00:53 the stored calendar for the room. Option C, what  happens at the door at 10.Keep your answer in  

• 00:01:01 mind, because the 1st scene tests it. Now I  click the button What does this course build,  

• 00:01:07 and the course thread appears on the right. Let  me read it with you.Every habit in this course  

• 00:01:13 is also what it takes to direct and check an  automated engineering assistant: a precise rule,  

• 00:01:20 an independent check, a bounded permission, and a  reviewable change. Keep that thread in mind.Below  

• 00:01:27 it, where this applies. A throwaway calculation  on your own machine needs none of this. A shared  

• 00:01:34 booking service that other people depend on  needs all of it. The care you take grows with  

• 00:01:41 the consequences of a failure.And the last note:  the 14 weeks are an order for learning,  

• 00:01:48 not 14 separate phases of a project. A  real project comes back to requirements, design,  

• 00:01:54 checks and operation again and again.Working code  becomes an engineered system when its behavior,  

• 00:02:02 its users, its changes and its consequences are  understood, not only its happy path. That is the  

• 00:02:09 frame of this whole lecture, and each scene widens  it a little.Check out the tutorial description to  

• 00:02:15 see the chapters, so you can jump to any scene. To  move between pages I use the arrow buttons at the  

• 00:02:21 top right. I click the next page button now.This  page starts from a program you already know. Think  

• 00:02:28 of a calculator, a to do list, a game, or a script  you wrote or used every week. Hold that program  

• 00:02:36 in your head for a moment.Now ask 3 questions  about it. What does it do when everything goes as  

• 00:02:43 planned? What could make it fail outside that  happy path: a 2nd user, a lost connection,  

• 00:02:51 a rule that changes, a wrong assumption?And  the 3rd question: who else is affected when  

• 00:02:58 it fails? Only you, or people who never saw the  code? That question is the heart of this course,  

• 00:03:05 because engineering starts when other people  depend on your program.To follow this lecture  

• 00:03:12 you need to read a short function, an if  statement and a list. No particular language,  

• 00:03:18 framework or tool is needed, and there is  nothing to install for today.The 2nd  

• 00:03:23 card repeats where this applies and the thread. A  shared booking service needs all of these habits,  

• 00:03:30 because a failure lands on people who never  clicked the button. The thread ties every habit  

• 00:03:35 to directing an automated assistant.On the right  you see what you will be able to do by the end of  

• 00:03:43 this lecture. 1st, distinguish a locally correct  function from a dependable user facing service.  

• 00:03:50 2nd, identify stakeholders, system boundaries,  and competing quality concerns.3rd, explain why  

• 00:03:58 delivery and maintenance belong in the engineering  lifecycle. 4th, separate an observation,  

• 00:04:03 an assumption, and evidence for a claim. And  5th, explain 1 decision by its benefit, cost,  

• 00:04:11 and affected people.Along the way you will meet  7 words: stakeholder, requirement, constraint,  

• 00:04:18 quality attribute, evidence, lifecycle and trade  off. Each 1 appears after the scene that shows  

• 00:04:24 what it means, and the last page collects  them.1 more note on the order of the weeks:  

• 00:04:31 it is an order for learning, not a project plan.  So let's go to the 1st scene, where 2 people  

• 00:04:38 book the same room.This is the 1st anchor scene,  and its title is a claim: 2 green confirmations  

• 00:04:46 cannot both be right. Ari and Bo both want room  C101 from 10 to 11, on the same  

• 00:04:54 day.On the left is Ari's booking screen, on the  right is Bo's, and in the middle is the stored  

• 00:05:01 calendar of the room. Right now the calendar  is empty, and every control here is real.Look  

• 00:05:07 at the condition card. In this baseline, each  screen checks its own copy of the room calendar  

• 00:05:15 and decides alone. Both copies say 10 o'clock  is free, and you can see that in the calendar  

• 00:05:22 copy field of each screen.The controls sit at the  top right: Step moves the scene 1 state forward,  

• 00:05:30 Back returns, Replay restarts this condition, and  Reset returns to the baseline. In this scene I can  

• 00:05:37 also click the Reserve buttons directly.So Ari  goes 1st, and I click Reserve on Ari's screen,  

• 00:05:46 which checks its own copy, finds 10 o'clock  free, and shows Confirmed. In the stored calendar,  

• 00:05:54 Ari's booking now appears in the 10 o'clock row,  on the left.Now Bo. Bo's copy of the calendar  

• 00:06:02 still says free, because nobody updated it. So  when I click Reserve on Bo's screen, Bo's screen  

• 00:06:08 also shows Confirmed, and a 2nd block lands in  the same hour.2 green confirmations for 1 room  

• 00:06:16 and 1 hour. Each screen did exactly what it was  built to do, and each screen looked right. This  

• 00:06:25 is the moment where most people stop looking,  and that is the mistake this scene is about.I  

• 00:06:33 press Step, and the scene asks you to decide. Both  screens say Confirmed. What evidence would let you  

• 00:06:40 decide whether the system worked? Read the 3  options and pick 1 before I continue.Option A is  

• 00:06:47 the 2 screens themselves, and that is only  appearance. Option B is the stored calendar,  

• 00:06:54 the record the service actually keeps. Option  C is what happens at the door, the consequence  

• 00:07:01 for real people. B and C are evidence.Think  of a concert ticket app that sells the same  

• 00:07:07 seat 2 times. Both buyers see a green tick, and both  are wrong. The ticket on the phone is appearance;  

• 00:07:14 the seat map the venue keeps is the record.Let's  step to the stored calendar. The 2 blocks now  

• 00:07:21 carry a red hatch and a badge: rule R1 broken,  2 confirmed bookings overlap. Rule R1 is  

• 00:07:28 labeled example assumption because it belongs to  this teaching example.Rule R1 says a room has  

• 00:07:35 no overlapping confirmed bookings. Intervals are  half open, so 10 to 11 and 11 to 12  

• 00:07:42 are adjacent, not overlapping. The stored record  breaks this rule.1 more step, and we arrive at  

• 00:07:49 the door. At 10 o'clock 2 people arrive at room  C101. 1 of them was promised something  

• 00:07:57 the service could not deliver. The screens were  the appearance; the door is the consequence.Read  

• 00:08:04 the right side of this strip: the false promise  costs the person who arrives 2nd, no room,  

• 00:08:10 no warning. Nobody saw an error message, and still  the service failed the people it was built for.The  

• 00:08:18 last step reveals the principle. Each screen  ran without an error, but judged against the  

• 00:08:23 intended outcome, 1 booking per room and hour,  the behavior failed. Engineering judges behavior,  

• 00:08:30 not appearance.In short: judge what the system  does, not what the screen says. When a screen  

• 00:08:36 says success, ask which stored, authoritative  state supports that message. Without that state,  

• 00:08:42 you have appearance only.Now compare this with a  tiny local utility, a script that renames files  

• 00:08:51 on your own laptop. If it makes a mistake, only  you notice, and you fix it in a minute. The same  

• 00:08:58 double booking mistake in a shared service  lands on strangers.That is why process grows  

• 00:09:06 with consequence. A disposable calculation needs  no rule and no check, and a shared booking service  

• 00:09:12 needs both. The size of the software is not the  point; who depends on it is.Now let's change 1  

• 00:09:20 condition and keep everything else the same.  I click 1 shared decision. Same 2 people,  

• 00:09:26 same room, same hour, but now neither screen  decides. Every request goes to 1 shared booking  

• 00:09:32 decision that reads the stored calendar.Notice  the new card above the calendar: shared booking  

• 00:09:39 decision, reads the stored calendar, waiting for  a request. And the calendar copy fields are gone  

• 00:09:44 from both screens, because the screens no longer  keep their own copy.Ari clicks Reserve again. The  

• 00:09:51 request travels to the shared decision, which  finds 10 o'clock free, stores the booking,  

• 00:09:57 and answers Confirmed. Look at the decision  card: free, stored, Confirmed.Now Bo clicks  

• 00:10:04 Reserve. The shared decision finds Ari's booking  in the same hour and answers: not available,  

• 00:10:10 room conflict. Bo's screen shows the rejection and  offers 11 to 12, or room C202.In  

• 00:10:18 the calendar you see 1 confirmed booking and 1  dashed rejection, with the badge rule R1 kept.  

• 00:10:25 Bo did not get the room, but Bo got the truth, and  2 alternatives to choose from.I press Step to  

• 00:10:32 compare the 2 outcomes. On the left, the false  promise: 2 confirmations, rule R1 broken,  

• 00:10:39 2 people at the door, and a double booking to  undo later.On the right, the honest rejection:  

• 00:10:46 1 confirmation and 1 clear rejection, rule R1  kept where the bookings are stored. Bo loses  

• 00:10:54 a minute at booking time and picks another  slot or another room. Nothing to undo,  

• 00:10:59 nobody misled.1 question stays open on  purpose: how does the shared decision stay  

• 00:11:07 correct when both requests arrive in the very  same instant? That is the question for week 6,  

• 00:11:15 so for today we keep it as an open assumption.The  final step names the principle for this condition:  

• 00:11:23 the rule is kept where the bookings are  stored, not on each screen. The screens  

• 00:11:30 now report a decision instead of making 1. That  is the difference between design 1 and design  

• 00:11:37 2.That completes the 1st anchor scene. Next we  widen the frame, because the Reserve button is not  

• 00:11:44 the whole system. I click the next page arrow.This  bridge scene is a context map. The dashed line is  

• 00:11:52 the boundary of the booking service, with 5  modules inside: Booking, Policy, Room Catalog,  

• 00:11:59 Notification, and Storage. The team writes and  deploys these.Outside the boundary live the people  

• 00:12:07 and systems the service depends on: students and  staff on the left, campus identity above them,  

• 00:12:15 room records on the right, and notification  delivery below. None of these belong to the  

• 00:12:20 team.Before any arrow appears, decide: which  parts of this map can the team change directly?  

• 00:12:29 Everything on the map, only what is inside the  dashed boundary, or the boundary plus the sign in  

• 00:12:35 provider? Keep your answer.I press Step, and the  1st interaction is drawn: a booking request with  

• 00:12:43 room, start and end, coming from the users into  the service. A request is something a person asks  

• 00:12:50 for. The service decides what happens to it.Step  again: the identity assertion, who is signed in,  

• 00:12:57 comes from campus identity. An assertion is a fact  another system vouches for. The service trusts it,  

• 00:13:06 but only within limits, and it never  treats an assertion as a request.Step:  

• 00:13:12 room facts arrive from room records. Does the  room exist, what is its capacity, and does it  

• 00:13:18 have step free access. This is reference data  the service reads but does not own.1 more  

• 00:13:25 step draws 2 arrows at once. The service hands  a message to deliver to notification delivery,  

• 00:13:32 and the confirmation message travels from  the provider back to the user. The work is  

• 00:13:38 handed over only after the decision is stored.So  a notification reports; it does not decide. Step  

• 00:13:46 reveals the tags: the request asks, the identity  assertion vouches, the notification reports, and  

• 00:13:51 the room facts are reference data. 3 kinds,  treated differently.Why does the kind matter? If  

• 00:13:58 the service treated an assertion like a request,  anyone could ask to be signed in as someone else.  

• 00:14:06 If it treated a report like a decision, a lost  message would cancel a booking. Kinds protect  

• 00:14:14 behavior.The answer to the question appears  with the last step: changeable by the team,  

• 00:14:20 only what is inside the boundary. Every arrow that  crosses the line is a dependency: the team relies  

• 00:14:26 on it and does not control it.A system boundary  identifies responsibility and dependencies;  

• 00:14:33 it does not make external behavior disappear.  In short, what sits outside your boundary still  

• 00:14:39 reaches your users. So let's see that happen  with the changed condition.I click Notifications  

• 00:14:46 unavailable. Same boundary, same arrows, and  1 dependency outside the boundary is down:  

• 00:14:51 notification delivery is marked with a dashed red  box, and its arrows are crossed out. Room storage  

• 00:14:57 is unchanged.Now decide again. Notification  delivery is unavailable. Which outcomes remain  

• 00:15:05 possible for Ari? None, no booking without a  message. The booking is stored and confirmed,  

• 00:15:12 and the message is delayed. Or the booking  waits until the provider is back.Step shows  

• 00:15:19 the outcomes. Still possible: the decision is  made and stored, Ari's screen shows Confirmed,  

• 00:15:26 and it says the message is delayed. Not possible  right now: the message reaching Ari.This is rule  

• 00:15:33 R4: a failed notification does not undo  a confirmed booking, and the pending message  

• 00:15:39 stays visible and recoverable. Confirmation and  notification are 2 separate facts, and a good  

• 00:15:46 service keeps them separate.Your own program has  a boundary too. A local script depends on the file  

• 00:15:52 system, the clock and the network, and none of  them are yours. Naming those dependencies is the  

• 00:15:58 1st step to deciding what happens when 1 of  them fails.The last step gives the principle for  

• 00:16:08 this condition. The boundary did not move and the  dependency did not vanish. Naming it is what lets  

• 00:16:15 the team decide what the user sees while it is  down. Let's move on to the stakeholders.The 2nd  

• 00:16:23 anchor scene: the same screen can serve 1 person  and exclude another. On the left, Ari at the top  

• 00:16:31 of a stakeholder map, connected to the booking  screen. On the right, an empty table.Decide 1st:  

• 00:16:39 who is affected by this screen besides Ari,  who clicks Reserve? Only the person booking,  

• 00:16:46 the people who book and run the rooms, or everyone  who books, runs, supports or maintains the  

• 00:16:51 service?Step adds the 1st person: a student who  needs step free access. Their concern: can I find  

• 00:16:59 and reserve a room I can reach? The system must  answer: do room records carry access attributes,  

• 00:17:06 and can the task be completed by keyboard.Step:  room staff handling closures. Their concern:  

• 00:17:14 how do I take a room out of service for a period?  The system must answer who may record a closure  

• 00:17:22 and what happens to affected bookings. That  question stays open until week 14.Step:  

• 00:17:29 support staff diagnosing mistakes. Their concern  is simple: why did this booking fail? The system  

• 00:17:34 must record a request identifier and an outcome  category. Remember this row, because scene 7  

• 00:17:41 is built on it.Step: a maintainer interpreting old  decisions, months or years later. Their concern:  

• 00:17:49 why was it built this way? The system must answer  where the decision record is. Code without its  

• 00:17:56 reasons is very hard to change safely.Step  again, and the map is complete: 5 people  

• 00:18:03 around 1 booking screen. Each concern became a  question the system must answer, about room data,  

• 00:18:10 closures, records and decisions. Only 1 of them  ever clicks Reserve.Why include support staff in  

• 00:18:16 a stakeholder map? Because their diagnostic needs  influence observability, documentation, privacy,  

• 00:18:24 and recovery decisions. If you forget them  now, you will meet them later, in the middle  

• 00:18:29 of an incident.Now the mouse route. Step, and the  callout shows it: click the room, click the time,  

• 00:18:37 click Reserve, read Confirmed. Task completed.  With a mouse, the polished screen works perfectly,  

• 00:18:44 and that is exactly why the next comparison  matters.I change the condition to Keyboard only.  

• 00:18:51 Same screen, no mouse. A yellow focus ring shows  where the keyboard is, and each step presses Tab.  

• 00:18:59 Decide: can the booking be completed with the  keyboard alone?Step: Tab, and the focus ring  

• 00:19:07 lands on the room list. Step: Tab again, and  the focus ring lands on the time fields. So  

• 00:19:14 far the polished screen behaves like any form,  and the keys pressed are listed below it.Step:  

• 00:19:20 Tab, and the focus ring skips Reserve and leaves  the page. The polished Reserve is a painted box,  

• 00:19:27 not a control. Reserve is not reachable, and the  task cannot be completed. Read the red callout:  

• 00:19:34 the focus landed in the browser toolbar.Many  people use the keyboard only: someone with a  

• 00:19:41 motor impairment, someone with a screen  reader, and many power users. For all of  

• 00:19:46 them the polished screen simply does not book  a room, however good it looks.Step brings the  

• 00:19:52 corrected screen in beside it. It looks the  same. Tab reaches the room list and the time  

• 00:19:58 fields exactly as before, so appearance tells  you nothing about the difference.Step: Tab,  

• 00:20:04 and the corrected Reserve is a real button, so  the focus ring lands on it. That is the whole fix:  

• 00:20:11 a real button instead of a painted box. Same  colors, same words, different element.Step: Enter,  

• 00:20:20 and the corrected screen shows Confirmed. The  status message is announced, so a screen reader  

• 00:20:26 speaks it too. This is rule R5: the core  task can be completed by keyboard, with status  

• 00:20:34 and error information you can perceive.The final  step compares on task completion, not appearance.  

• 00:20:40 The polished screen completes 0 of 1 bookings  by keyboard, the corrected screen 1 of 1. Same  

• 00:20:48 appearance, different service.The name for this  difference is accessibility: you can complete  

• 00:20:54 the task however you use the service, with a  mouse, the keyboard only, or a screen reader.  

• 00:21:01 The reference is the Web Content Accessibility  Guidelines, version 2.2.You can run this  

• 00:21:07 check on your own screens today: put the mouse  away and press Tab through the whole task 1 time. If  

• 00:21:14 the focus ring skips a control or leaves the page,  you have found your painted box.The principle:  

• 00:21:22 quality depends on the people and conditions  included in the definition of success. In short,  

• 00:21:28 if someone cannot finish the task, it does not  work. Let's move to the next page, where faster  

• 00:21:34 meets better.Faster is not a complete description  of better. 2 fictional designs answer the same  

• 00:21:44 booking request. Design 1: the screen confirms  from its own copy of the room calendar. Design  

• 00:21:51 2: the screen confirms after 1 shared  decision checks the stored bookings.Decide  

• 00:21:58 which is better before their behavior is revealed.  Design 1, because it answers faster. Design 2,  

• 00:22:05 because it checks the stored bookings 1st.  Or, it depends on what better has to include.The  

• 00:22:13 stated constraints sit on the right: an  answer within 2 seconds, and correctness,  

• 00:22:19 rule R1, required in every case, not traded for  speed. Both values are example assumptions.Step  

• 00:22:26 reveals the 1st quality attribute, response  time until an answer appears. Design 1 answers  

• 00:22:32 in about 0.1 seconds, design 2 in  about 0.4. Both values are inside  

• 00:22:38 the 2 second target.Step: correctness when  2 requests overlap, rule R1. Design 1  

• 00:22:47 can produce 2 confirmations; design 2 produces  1 confirmation and 1 rejection. Read the chip:  

• 00:22:54 condition of acceptance. This row is not a score,  it is a gate.Step: recoverability after a wrong  

• 00:23:03 confirmation. With design 1 someone must find  and undo the double booking later. With design  

• 00:23:10 2 there is nothing to undo, because the wrong  confirmation never happened.Step: privacy of other  

• 00:23:17 people's bookings. In design 1 every screen  holds a copy of the whole room calendar, so  

• 00:23:23 every device sees everyone's bookings. In design  2 only the decision reads the calendar.Step:  

• 00:23:29 change effort when the booking rule changes. In  design 1 every copy of the rule in every screen  

• 00:23:35 changes. In design 2 1 decision point changes.  Think about how many installed apps you would have  

• 00:23:42 to update.The last step gives the principle. Under  a 2 second target both designs are fast enough.  

• 00:23:50 Correctness is a condition of acceptance, so  design 1 is out before speed is even compared.  

• 00:23:56 Faster described 1 attribute; better needs  the stated constraints.A card also names the  

• 00:24:02 standard vocabulary. The ISO 25010  standard, 2023 edition,  

• 00:24:08 lists 9 product quality characteristics,  among them performance efficiency, reliability,  

• 00:24:14 security, interaction capability and  maintainability.The rows of this table,  

• 00:24:20 in those names: response time is performance  efficiency, correctness is functional suitability,  

• 00:24:27 recoverability is reliability, privacy is  security, and change effort is maintainability.  

• 00:24:32 Use these names with other engineers.Note  1 distinction from the 1st caption: each  

• 00:24:39 row says how well the service does what it must.  A feature you could add or drop, like a calendar  

• 00:24:46 export, is a different kind of thing and does not  belong in this table.Now the changed condition:  

• 00:24:53 I click Target 0.3 seconds. Design  2 answers in about 0.4 seconds  

• 00:25:00 and misses this target. Correctness is still  required. What do you change? 3 options,  

• 00:25:06 and the table fills as we step.Step: option  1, answer Confirmed before the shared  

• 00:25:12 decision returns. It breaks rule R1, hides the  delay, and brings back 2 confirmations. It meets  

• 00:25:19 the number by giving up the rule.Step: option  2, look up the room's day faster by indexing  

• 00:25:27 the stored bookings by room and day. About  0.25 seconds in the example,  

• 00:25:32 and the shared decision still decides. The rule  is kept and the target is met.Step: option 3,  

• 00:25:39 show Checking availability, then the answer. The  wait is visible, and nobody is misled. The rule  

• 00:25:46 is kept and the delay is honest. Sometimes the  right engineering answer is a clear message, not  

• 00:25:53 a faster path.The final step: 2 options keep the  rule and deal with the target; the 1st hides a  

• 00:26:00 delay by giving up the rule. An optimization that  preserves the rule is engineering; 1 that hides  

• 00:26:08 the delay is a return to design 1. Next page.The  3rd anchor scene: a failure can teach the next  

• 00:26:16 requirement. We follow 1 defect: a notification  failed and the user saw no message. The question  

• 00:26:22 is where it is 1st noticed, and what has to  change afterwards.The loop has 7 stages, Need,  

• 00:26:30 Model, Implementation, Checks, Release, Operation,  and Revision, drawn in a circle. The arrows form a  

• 00:26:38 loop, not a line, and the middle says it: feedback  loops, not a conveyor.Decide: where would you  

• 00:26:45 1st notice that a failed notification leaves  the user with no message? While talking about the  

• 00:26:53 need, at an integration check, or in operation,  when a user reports it? The baseline takes the  

• 00:26:59 last option.Step. A user reports it: the booking  was stored, the message never arrived, and the  

• 00:27:07 screen said nothing. The incident card appears  at Operation, and the rework list on the right  

• 00:27:13 is still empty.Step: the card moves to Revision.  Incident handling: someone reads the record, finds  

• 00:27:21 the failed notification job, and tells the user.  2 kinds of rework already: incident handling and  

• 00:27:28 user communication. The dashed line carries what  was learned.Step: back to Need and Model. The need  

• 00:27:35 is restated: a booking whose message failed must  say so. The model gains a message state: sent,  

• 00:27:43 delayed, failed. 3 kinds of rework, and we  have not written a line of code yet.Step: on to  

• 00:27:50 Implementation and Checks. A new check: when the  notification fails, the booking stays confirmed  

• 00:27:56 and the screen shows the delayed message. The  solid lines carry the change forward. 4 kinds  

• 00:28:02 of rework.Step: Release. The change ships, and  the comparison table appears. Count the rework:  

• 00:28:10 incident handling, user communication,  message state, check, release. 5 kinds,  

• 00:28:17 and the user found the defect, which is the worst  way to find 1.The last step explains 2 words.  

• 00:28:25 Iteration is going around the loop again to  revisit understanding. Increment is the usable  

• 00:28:31 capability each pass adds. The principle: the  lifecycle is a network of feedback loops, not  

• 00:28:38 a 1 way conveyor ending when code runs.Now the  same defect with earlier feedback. I click Found  

• 00:28:46 at a check. The integration check runs the booking  with the notification provider switched off. Where  

• 00:28:53 does the card start now? Think before I step.An  integration check runs the real modules together,  

• 00:29:00 here the booking with the notification provider,  instead of 1 function alone. That is why it can  

• 00:29:05 see a silent screen that a unit level check of  the booking function would never notice.Step:  

• 00:29:12 the screen stays silent during the check, and that  is the moment of discovery. The card appears at  

• 00:29:18 Checks, before any user sees it. Nobody had  to apologize to anybody.Step: back to Model  

• 00:29:25 and Implementation: 1 message state and 1  check. 2 kinds of rework, no incident handling,  

• 00:29:31 no user communication. Compare the highlighted row  in the table with the operation row below it.Step:  

• 00:29:39 Release, with the message state in place. The path  is shorter and the list is shorter. Same defect,  

• 00:29:46 same fix, less undoing, because the feedback  arrived before the change reached anyone.And the  

• 00:29:54 earliest feedback: I click Found in conversation.  While writing rule R4, someone asks a simple  

• 00:30:00 question: what does the user see when the message  fails? That question is the whole discovery.Step:  

• 00:30:09 the card appears at Need. Rework: 1 sentence  added to rule R4 and 1 acceptance example.  

• 00:30:17 Nothing built yet has to be undone, because  nothing was built.An acceptance example is a  

• 00:30:23 concrete case written next to the requirement:  when the message fails, the screen says delayed  

• 00:30:29 and the booking stays. Later it becomes a check,  and that is the arrow you see from Need toward  

• 00:30:35 Checks.Step: the example flows into Model and  Checks as they are written. Compare the 3  

• 00:30:42 rework lists: the same defect, 3 different  amounts of undoing. The earlier you learn,  

• 00:30:49 the less you redo.So testing does not happen  only at the end. A question at the need stage  

• 00:30:55 is already a check, and it is the cheapest 1  you will ever run. Let's go to the next scene,  

• 00:31:01 about evidence.What would make you believe this  works? 3 claims sit in the 1st column:  

• 00:31:08 it looks right, it passed 1 example, and it  met the stated checks under these conditions.  

• 00:31:14 Which would you accept, and why?Step: it looks  right. The check that supports it: someone  

• 00:31:20 read the screen after 1 booking. Left  uncertain: nothing about the stored calendar,  

• 00:31:27 other people, or other rooms. This claim is  where the opening page left us.Step: it passed  

• 00:31:34 1 example. The check: Ari books C101  on an empty calendar, and the stored calendar  

• 00:31:41 shows 1 booking. Left uncertain: other times,  other rooms, an existing booking in that hour,  

• 00:31:48 and 2 people booking at the same moment.Step: it  met the stated checks. The check: interval cases,  

• 00:31:56 overlap, adjacent, other room, and the 2 at  once case at the storage boundary. Left uncertain:  

• 00:32:02 3 people, a lost response, a different  clock.The last step names the principle: each  

• 00:32:08 check supports its claim under its own conditions.  Write the conditions next to the claim, and the  

• 00:32:15 3rd column is never empty. A check supports a  bounded claim.In practice this means naming the  

• 00:32:22 conditions in the test itself: 1 user, empty  calendar, room C101. Then anyone reading  

• 00:32:30 the test knows exactly what it showed and what it  never touched.Let's change the workload. I click  

• 00:32:36 2 in the same moment. The 3 claims and  their checks stay. The counterexample appears  

• 00:32:44 at the bottom: Ari and Bo both request C101  from 10 to 11 in the same moment.Step:  

• 00:32:52 the claim it passed 1 example is unchanged, and  so is its check. What the new workload exposes is  

• 00:33:00 an assumption: that only 1 person books at a  time.Step: the 3rd claim named its conditions,  

• 00:33:07 and its checks include the 2 at once case at the  storage boundary, so it covers the new workload.  

• 00:33:14 The habit of this course: state the evidence and  its limits together.So does passing 1 booking  

• 00:33:21 example establish correctness for simultaneous  requests? No. The evidence does not cover that  

• 00:33:27 interaction condition. A test shows what it  tested, so say what it covered. Next page.Who  

• 00:33:35 carries the cost of an engineering shortcut?  Here is a support log entry written to answer  

• 00:33:41 1 question: why did Ari's booking fail?  Ari's request failed with a storage timeout,  

• 00:33:48 and the entry as 1st written keeps 7  fields.3 fields answer the support question:  

• 00:33:56 the request id, req4f9c, the time,  and the outcome, failed with a storage timeout.  

• 00:34:03 They are marked needed. The other 4 describe  Ari: the user, the room and slot, the purpose,  

• 00:34:10 and the full request.Decide: the log holds  everything the screen sent. Who benefits  

• 00:34:15 from all these fields, and who takes the risk?  Support, because more detail helps them; users,  

• 00:34:21 because they get faster help; or nobody needs  most of it, and the users carry the risk.Step:  

• 00:34:29 the consequence map starts with the users. Logging  everything means personal details sit in a log  

• 00:34:35 many people can read. With a minimal record,  the log holds a reference, not their story.Step:  

• 00:34:44 support effort. Logging everything means reading  through personal detail to find the failure. With  

• 00:34:51 the minimal record, support finds the request  by its id in 1 step. More data made their job  

• 00:34:58 slower, not faster.Step: data exposure. 1 copied  log file exposes names and purposes, a counselling  

• 00:35:06 session in this example. With the minimal record,  1 copied log file exposes ids and categories,  

• 00:35:14 and nothing about the person.Step: future change.  When you log everything, reports and tools grow  

• 00:35:20 around the personal fields, and removing them  later breaks things. With the minimal record,  

• 00:35:25 a field is added when a question needs it.Step,  and the left card becomes the minimal diagnostic  

• 00:35:32 record, with 3 fields and their written  reasons. Request id finds the request again,  

• 00:35:38 time places the failure, and outcome category  names the failing part.Ari's purpose never enters  

• 00:35:46 the log, and support still finds every request by  its id in 1 step. Step reveals the principle:  

• 00:35:54 the people in the log did not choose the logging  design, yet they carry its risk.The choice belongs  

• 00:36:02 to the engineers, and so does the consequence. In  your own projects, log identifiers and categories,  

• 00:36:10 and keep names and purposes out unless a written  question needs them.Now the changed condition.  

• 00:36:18 I click Is it 1 room? The support question  changes: is the failure specific to 1 room?  

• 00:36:25 Which single field does the record now need:  room id, the user, or the purpose? Start from  

• 00:36:32 the minimal record.Step: room id, C101, is  added with its reason, because the question groups  

• 00:36:40 failures by room. The slot, the person and the  purpose stay out: deliberate collection is 1  

• 00:36:47 field with 1 written reason.Collecting  everything by default needs no reason and  

• 00:36:53 answers no question better than a minimal record.  Step: the record grew by 1 justified field, and  

• 00:36:59 every other personal detail still stays out.Your  shortcut becomes someone else's cost. That closes  

• 00:37:08 the responsibility scene, and the last scene  of the lecture is the map of the whole course,  

• 00:37:14 so let's open the next page.1 domain, many  kinds of explanation. The same booking service,  

• 00:37:22 8 questions, and the representation that  answers each 1. This is the map of the course.  

• 00:37:28 Decide 1st: could 1 flowchart answer all  of these questions equally well?Step reveals  

• 00:37:35 the 1st pair. Week 2: how would we know this  requirement is satisfied? A requirement card with  

• 00:37:42 its acceptance example. Week 3: which states  can a booking be in, and what moves it? A state  

• 00:37:48 diagram.Step to week 5: who depends on this? A  dependency graph. Week 6: what happened 1st? A  

• 00:37:55 sequence diagram. 2 questions about 1 booking,  and 2 pictures, because each question needs a  

• 00:38:01 different structure.Step. Week 8: which cases  did we check? A test table. Week 10: what travels  

• 00:38:09 with a change before release? A release path.  Again, a table for coverage and a path for a  

• 00:38:16 journey.Step to week 11, what did we observe  and when, answered by an incident timeline,  

• 00:38:23 the last picture. Week 13 asks: the same  change is drafted by an automated assistant, so  

• 00:38:30 which of these are no longer needed, and the tile  answers none.Step: ask who depends on the booking  

• 00:38:37 decision, and the dependency graph lights up:  components and the edges between them. A sequence  

• 00:38:43 diagram would show the same booking, but it  answers a different question.A flowchart would be  

• 00:38:49 the wrong tool here: it shows steps in order, and  this question is about which parts rely on which.  

• 00:38:56 The right picture is the 1 whose structure  matches the question.The last step of the baseline  

• 00:39:03 gives the principle: the booking behavior  stays fixed through all 14 lectures;  

• 00:39:09 the representation changes with the question.  Choose a representation for the question,  

• 00:39:14 not a diagram style for the whole course.Let's  ask a different question. I click What 1st?  

• 00:39:21 Same booking, different question: what happened  1st when Ari booked? Which representation  

• 00:39:28 answers it? Think about order, because order is  what this question is about, and only 1 picture  

• 00:39:34 shows order.Step: the sequence diagram lights up,  with the request, the decision, the storage write,  

• 00:39:43 and the answer in time order. The dependency  graph has the same boxes and no order, so it  

• 00:39:49 cannot answer this question.Step: 2 questions,  2 representations, 1 unchanged service. So  

• 00:39:56 which representation answers what happens after a  timeout? A state model if you ask about possible  

• 00:40:04 states, or a sequence or timeline view if you ask  about 1 particular interaction.Now change the  

• 00:40:12 actor instead of the question. I click Assistant  drafts. The same booking change is drafted by an  

• 00:40:19 automated assistant rather than a colleague.  Which representations and checks are no longer  

• 00:40:24 needed?Step, and the answer is none: requirement  card, state diagram, dependency graph, sequence,  

• 00:40:32 test table, release path and incident timeline  all still apply. They describe the system and its  

• 00:40:38 behavior, not who typed the draft, so changing the  actor changes nothing.Every tile turned green, and  

• 00:40:45 the assistant tile is highlighted. Week 13  examines this in full. That was the last scene,  

• 00:40:52 so let's collect the 8 principles on the next  page.8 principles, 1 per scene, and 4  

• 00:40:58 checks. Principle 1: engineering judges behavior  against an intended outcome and its consequences,  

• 00:41:05 not appearance alone. In short, judge what the  system does, not what the screen says.Principle  

• 00:41:12 2: a system boundary identifies responsibility  and dependencies; it does not make external  

• 00:41:19 behavior disappear. Principle 3: quality  depends on the people and conditions included  

• 00:41:26 in the definition of success. If someone cannot  finish the task, it does not work.Principle 4:  

• 00:41:33 compare alternatives under stated constraints;  some requirements are conditions of acceptance  

• 00:41:39 rather than points in a score. Principle 5: the  lifecycle is a network of feedback loops, not a  

• 00:41:47 1 way conveyor ending when code runs.Principle  6: a check supports a bounded claim,  

• 00:41:53 so always say what it covered and what it left  out. Principle 7: professional responsibility  

• 00:41:59 includes the consequences imposed on people who  did not make the technical choice.Principle 8:  

• 00:42:05 choose the representation for the question,  not a diagram style for the whole course.  

• 00:42:10 Now 4 checks; decide your answer before  I open each 1.Question 1: what is wrong  

• 00:42:16 with 2 successful overlapping confirmations? I  click it. They violate the intended exclusivity  

• 00:42:24 rule even when each screen and request appears  successful.Question 2: why include support staff  

• 00:42:31 in the stakeholder map? Click. Their diagnostic  needs influence observability, documentation,  

• 00:42:37 privacy, and recovery decisions. Everything in  scene 7 followed from that.Question 3:  

• 00:42:43 does passing 1 booking example establish  correctness for simultaneous requests? Click.  

• 00:42:49 No. The evidence does not cover that interaction  condition. This is the evidence scene in 1  

• 00:42:55 sentence.Question 4 asks which representation  answers what happens after a timeout, and I click  

• 00:43:03 it to see. The answer: a state model, or  a sequence or timeline view, depending on  

• 00:43:09 whether you ask about possible states or 1  interaction.Those are the 4 checks; if you  

• 00:43:16 missed 1, go back to its scene and step through  it. Now let's go to the last page, which shows  

• 00:43:22 what carries forward to week 2 and beyond.What  carries forward, and where to read more. Week  

• 00:43:30 2 starts from this request: make room booking  fair and easy. Read it 2 times. It sounds clear,  

• 00:43:37 and next week you will see how many different  systems it could describe.3 things are carried  

• 00:43:43 forward. The context map: the booking service  inside its boundary, 4 dependencies outside.  

• 00:43:49 The no overlap concern: 1 confirmed booking per  room and hour, rule R1, kept where bookings are  

• 00:43:57 stored.And the open assumptions: who may record a  room closure, what the user sees while a message  

• 00:44:05 is delayed, and how the shared decision behaves  when 2 requests arrive at once.In practice,  

• 00:44:12 in 2026, teams keep requirements and  incident reports in issue trackers such as GitHub  

• 00:44:19 Issues or Jira. They check accessibility with axe  or Lighthouse next to a keyboard walk through, and  

• 00:44:27 draw context maps in Mermaid or draw dot io.The  middle card lists the 9 terms used this week,  

• 00:44:36 starting with software engineering: making  and changing software that people depend on,  

• 00:44:42 over its whole lifetime, with the consequences  for other people counted in.Then stakeholder,  

• 00:44:49 accessibility, requirement, constraint,  quality attribute, evidence, lifecycle,  

• 00:44:54 and finally trade off, 9 terms in all. Notice  that evidence is defined with its scope, what a  

• 00:45:01 check showed together with the conditions it ran  under.On the right are the sources: the Software  

• 00:45:10 Engineering Body of Knowledge, the Computer  Science Curricula 2023, and  

• 00:45:16 Software Engineering at Google, chapter 1.  Then the Web Content Accessibility Guidelines,  

• 00:45:22 and the ISO 25010 quality  model.So that is lecture 1. Judge behavior,  

• 00:45:29 not appearance. Name your boundary and its  dependencies. Include every stakeholder in  

• 00:45:35 the definition of success. Treat correctness as  a gate, not a score.Learn as early as you can,  

• 00:45:42 state evidence together with its scope, own  the consequences of your shortcuts, and pick  

• 00:45:48 the representation for the question. Thank you  for watching, and I will see you in week 2.