Why Requirements Become a Document
In one line
Defining requirements is not about producing a document but about turning what people say into verifiable sentences, and the reason we number them is that the number becomes the thread that runs through design, development, testing and acceptance.
A first scene from the field
It is week two of the project. The PM hands you a stack of meeting minutes and says, "Please organize these into a draft requirements definition document. We'll use it at Friday's review meeting."
The minutes contain a sentence like this.
"The order screen's lookup is a bit slow, so we'd like that improved, and it would be nice if the administrator could also get an Excel download. Oh, and with the security audit these days, we need to keep a login history too."
This one paragraph is three requirements. And none of the three can be developed as they stand. How many seconds does "a bit slow" mean? Does "also Excel" mean the screen as it is, or different fields? Does "login history" mean successes only or failures too, and how long is it kept?
Defining requirements is turning what people say into verifiable sentences.
Why we number them
Attaching an ID such as REQ-014 to a requirement in an SI project is not bureaucracy.
That one ID becomes the thread that runs through every later document.
REQ-014 (요구사항정의서)
→ SCR-032 주문조회 화면 (화면정의서)
→ PGM-118 OrderSearchService (프로그램목록)
→ TC-207 대량조회 성능 테스트 (단위테스트 시나리오)
→ ITC-041 주문-정산 연계 테스트 (통합테스트)
→ 검수확인서 항목 14번
When this chain breaks, three kinds of incident follow.
- A feature that was developed but that nobody tested — it is discovered as the first outage after go-live.
- A feature that was tested but was never in the requirements — nobody knows who asked for it. At acceptance you hear, "This is outside the scope of work, so why did you do it?"
- A feature that is in the requirements but was never developed — discovered right before acceptance. This hurts the most.
The tool that prevents all three is the Requirements Traceability Matrix (RTM). Rows are requirements and columns are deliverables. A blank cell is a risk.
What makes a good requirement sentence
The criteria commonly used in the field are roughly these.
- Verifiable (testable) — not "fast" but "within 3 seconds with 100 concurrent users". Without a number, you argue with the customer at acceptance. You always lose.
- Atomic — one thing per sentence. Split "look up and download to Excel" into two. Splitting is what makes progress reporting accurate. If you don't split, it is "90% done" forever.
- Has a source — who said it and when. Later someone says, "I never said that." This really happens. It always happens.
- Has a priority — high/medium/low. When the schedule slips, you push the 'low' items to the next phase first. A project that starts without priorities ends up with everything 'high' at the last minute.
Requirements will certainly change — that is why we do change management
The misunderstanding newcomers hold most often: "If you define the requirements well, they won't change." There is no project where they don't change. There are only unmanaged changes.
The minimal form of change management is a single-sheet change request log.
| Item | Why it is needed |
|---|---|
| Before / after change | Lets you reconstruct later what changed |
| Requester | Accountability: a business user at the customer, or our PL |
| Impact | Related screens, programs and effort (man-days). This is your bargaining chip |
| Approval status | Starting development before approval = unpaid development |
Don't develop before approval. This is the most expensive lesson in the SI business. Work that started as "it's urgent, let's do it first and document later" has no basis when it comes to settlement.
The task comparison table — the final weapon at acceptance
Public-sector projects use a task comparison table. It is a table that compares the task items of the request for proposal (RFP) with the actual deliverables, one to one. An acceptance meeting is effectively a session of reading this table line by line.
If you kept the RTM up to date throughout the project, the task comparison table is just a re-sorted version of it. If you didn't, the whole team spends nights tracing backward two weeks before acceptance. Which of the two you get is decided in the first month of the project.
How to keep a traceability matrix actually running
A requirements traceability matrix is easy to create but does not stay maintained. By mid-project the document and reality drift apart, and from then on nobody looks at it. Matrices that stay maintained have things in common.
Manage it in one place only. If the same item exists in a spreadsheet and in an issue tracker, both will be wrong. Pick one as the source of truth and only reference it from elsewhere. If you need a report, generate it from the source.
Never reuse a number. If REQ-042 is deleted and you give that number to the next requirement, old minutes and test documents start pointing at something else. Leave a deleted item in a deleted state.
Traceability is only useful in both directions. With only the direction from requirement down to test, you cannot answer "why does this test exist?". The reverse direction is what exposes tests attached to a requirement that no longer exists and features with no basis.
| Direction | Question it answers |
|---|---|
| Requirement → design → code → test | Was this requirement implemented and verified? |
| Test → requirement | What does this test guarantee? |
| Code → requirement | Who asked for this feature and why? |
Record changes as versions, not as numbers. If the content of REQ-042 changed, don't give it a new number; raise the version of that item, together with when, by whom and why it was changed. The argument at acceptance that "this isn't what it originally meant" is settled here.
A blank cell is a warning sign. Periodically pull out rows that have a design but no test, and rows that have a test but no requirement. The goal is not to fill the whole table; the reason a traceability matrix exists is to make the empty cells visible.
What you will do in this module
You extract requirements from an interview summary and number them, build a traceability matrix, and write a script that mechanically finds the missing requirements in a matrix provided by a partner vendor. You don't compare by eye — nobody can read a 500-row matrix by eye.