02 · Requirements · Night-shift notes
The process day shift described, night shift never walked
The business analyst writes down facts — night shift, over-receive, stock that does not match — and hands them to requirements to become rules that can be judged. He may record that night shift has no supervisor. He may not write that over-receive is therefore waved through.
22:40. Arrival 132 cases, document 120. The warehouse clerk received into stock first. Variance stayed in WeChat, to be patched tomorrow.
23:10. No supervisor. If the system requires supervisor confirmation before over-receive, this truck sits on the dock.
06:30. Day shift sees extra stock. The document is still pending receive. Nobody can point at which click caused it.
The business analyst collects facts. He does not invent rules on the floor
The requirements analyst has to write sentences a test can judge, but the raw material for those sentences is not “we usually do it this way” in a meeting room. The business analyst is responsible for bringing the raw material back: who, on which shift, against which document, actually did what when an exception hit. The mark of the role is being able to stay on the floor until the exception happens, and adding no solution of his own. He may record “night shift has no supervisor”. He may not write on his own “so over-receive should be waved through”. Wave-through or pending confirmation is a later choice for requirements and product. If the analyst smuggles a conclusion into the notes, engineering will treat the conclusion as a confirmed need.
A complete fact has at least five things: document number or photo, operator role, time, the state of the system or sheet at that moment, and the party's own reason. The reason has to be the original words. “For flexibility” is not original words. “The supervisor is asleep. If we don't unload, we block the next truck” is. Original words keep the disagreement, so the next person knows whom the rule will hurt.
Why he has to shadow a shift, and cannot only read the flow chart
Day-shift process is often complete: receive, count, over-receive request, supervisor confirm, putaway. Night shift has fewer people. The supervisor is not on duty. A cold store cannot leave goods outside the door. Both are true. Written into the same requirement they cancel each other. The business analyst's job is to bring both back, and mark each frequency. If thirty-five of forty over-receives in a month happen after 22:00, day-shift process cannot be the only fact. He also records the workarounds: patching the document in WeChat, changing the printed quantity, confirming with someone else's account. Workarounds are not to be praised. They are the paths most likely to be copied after go-live.
His difference from the User researcher is the object. The business analyst sits around documents and exceptions. The service is whether the rule covers the real shift. The user researcher sits around whether a person can finish the action. The service is the screen and the task. Both can stand on the dock the same night. The notes cannot be merged into one. After a merge, button size and over-receive privilege sit in the same requirement, and nobody can accept it.
Twelve cases over-received: the contradiction that has to go back
A DC night shift received 120 cases as 132. The business analyst did not suggest “allow ten percent over-receive”. He recorded: the warehouse clerk thought not unloading would block the next truck; day shift thought stock was already high while the document was still open, and finance could not explain it; the supervisor thought only he could approve over-receive, and admitted he was not there after 22:00. All three sentences were true at once. He also recorded the system as it stood: one click had already added the stock, while the document state had not changed. That is a fact. The verdict on blame does not happen on the recording floor. It waits until engineering has read the logs.
Only after the notes go to the Requirements analyst does a sentence that can be judged appear: before 22:00 over-receive needs supervisor confirmation; after 22:00 it enters pending-confirmation stock first, does not enter available quantity, and if the supervisor has not confirmed the next day the document's new putaway is frozen. That sentence is not something the business analyst said offhand on the dock. If he had said it then, night shift would have treated it as a DaXi Technology promise. The analyst's discipline is to send the contradiction on as it is, and to write in the notes that he promised no handling.
When the facts are not enough, he shadows another shift. He does not fill the form with extra day-shift interviews. A form that is full but has no night shift will still write requirements as if the company only ran in daylight.