There is a kind of spinning-in-place that happens often in requirements definition. You ask “please tell us the flow of the work,” and you get “roughly, it goes like this.” It survives in the minutes, but it cannot be used for design.
The cause of that spinning is not clumsy questioning.It is that the question is abstract.An abstract question can only be answered abstractly.
In this instalment we write about counting what we did not understand and putting it on the table.
We counted what we did not know, up to 37 items.
While handling a prototype, there are always places where your hand stops. I do not know what belongs in this field. It is not decided who moves this forward when it is in this state. I do not know where this number comes from.
We wrote out every place where we stopped. The result was37 items. And out of those 37, we pulled out the ones to raise at the preparatory meeting and organised them as requests.
What matters here is less the content of the items than the fact that they were counted. “There are still things that are not pinned down” leaves neither the customer nor us able to see how much is left. The instant it is counted as 37, it turns intowork that can be worked through.
With the real thing in hand, questions become concrete.
These 37 items were not produced by reading a specification.They came from operating something that works and recording where it got stuck..
That difference is decisive. A question built from a specification becomes “how do you manage progress on a project?” A question built from the real thing becomes “on this screen, in this state, who moves next, and what do they look at to decide?”
The latter gets a concrete answer. And the answer that comes back can be used directly in design.The quality of an interview is settled less by the interviewer’s skill than by whether the real thing is in the room.
This is what it means to say AI-driven development changes the early stage. Traditionally, “the real thing exists only after design is finished.” So early-stage interviews had no choice but to build questions out of imagination. Once the order is swapped,the interviewer’s weapons change.
Take requirements from two directions.
We decided to extract requirements in two directions.
One is starting from the customer’s documents. Pick up every requirement written in the material we received, without omission, and list it. That is the obvious thing to do.
The other is working backwards from how it will be operated. Who changes the setting for this function, and when? Does the person who wants to change it have the authority? After it is changed, how does past data appear?Things that are never written in documents but always become necessary once it is running — those we put forward from our side.
Doing both directions changes the number of requirements extracted. Starting only from documents means “this cannot be done” surfaces the moment operation begins. It is not the customer’s fault.Nobody can write the fine detail of operation before they start using it..
Do not make them call a vendor “just to add one value.”
Of everything decided in this period, here is the one likely to matter most.We made every term used in the business manageable as a setting.
This had been raised as a problem with the current system: you only want to add one option, but it requires a vendor and a modification. It costs money and time, so the site gives up and absorbs it in their process.And the number of fields nobody manages keeps growing.
So we made it possible to add, rename and reorder the names of categories and states from the screen. If the customer can add them, there is no need to call us.
There is one point we decided carefully here.Options no longer needed are “disabled,” not “deleted.”They disappear from the choices when entering something new, but display and aggregation of past data stay as they are.
The reason is simple. Erasing a value that was chosen in the pastamounts to rewriting history.A case that was in that state last year must remain in that state last year. Even the word on screen was unified to “disable” rather than “delete.”
What you do not know is faster counted than hidden.
Early in requirements definition there is a mountain of things not understood. Proceeding while leaving them vague is more anxious, and it jams later too.
Count them, put them in a table, show them to the other side.That way the customer is reassured too. Work whose remainder is visible is work whose progress can be seen.
Next time: bringing the prototype closer to the real build. Passing a demo and surviving being rebuilt turned out to be two different things.
* The counts in this article are our own side’s work records. Nothing identifying the customer or the system is included. Approach and time required vary with the scale and structure of the project.
Series “Project Diary” (7 parts)Part 1: 82 fixes to the prototype on the day we won the projectPart 2: Cutting our own company introduction out of the first meeting’s agendaPart 3: Counting what we did not understand and putting it on the table (this article)Part 4: Bringing the prototype closer to the real buildPart 5: Killing “it looks like it worked but nothing happened”Part 6: Cutting promises we could not keep out of the materialPart 7: Dropping the paper comparison and deciding by measurement