Change log template for project requirements

Published 22 October 2026

A change log records every change made to a project’s agreed requirements: which requirement changed, what it said before and after, which request it came from, who decided, when, and which version of the requirements it produced. In project management the name is often used for the change request log as well, so this template covers both: one entry per approved request, with a line for each requirement it changed. Below are what to record, the template, a filled-in example, how a change log differs from a change request log, a decision log and a release changelog, and how to keep one in Excel, Confluence or Jira.

Keep meticulous records of requesting and receiving approvals on everything and keep a detailed change log in place for each artefact.

— r/businessanalysis, 2022

What a change log records

Karl Wiegers puts the rule that makes the log trustworthy in one line: “Every incorporated requirement change shall be traceable to an approved change request” (Change Happens). Every line in the log has a request; every approved request that changed a requirement has lines in the log.

Change log template

Copy it into a document or a spreadsheet. Square brackets are yours to fill in.

CHANGE LOG
Project:       [name]
Requirements:  [document], now at
               version [x.y]

[date]  [CR-n]  [title]
Decided:  [name, role]
Version:  [x.y] -> [x.y]
Why:      [the reason]

  [ID]   [added / changed / deleted /
         deferred]
  Was:   [old wording, or "new"]
  Now:   [new wording, or "removed"]
  Also:  [criteria, tests, documents
         updated]

  [ID]   ...

Change log example

The customer portal from the other templates on this site, where customers see and pay their company’s invoices. The requirements were agreed as version 1.0 on 28 January; here is the entry for the part payments change, with two of its six lines in full:

17 Jun  CR-10  Pay part of an invoice
Decided:  finance lead (client)
Version:  1.3 -> 1.4
Why:      large invoices stayed on
          bank transfer

  FR-014  changed
  Was:   A signed-in customer can pay
         any open invoice of their
         company by card.
  Now:   ... can pay all or part of
         any open invoice ...
  Also:  three new tests: a part
         payment; the last part pays it
         in full; an amount above the
         balance

  FR-016  changed
  Was:   One reminder, seven days
         after the due date, for every
         open invoice.
  Now:   ... for every invoice not
         paid in full.
  Also:  acceptance criterion 4;
         RULE-06 version 2

The whole log, one row per requirement changed:

CR-6 (a blog, declined) and CR-8 (push notifications, deferred) are not in it: they changed no requirement. They are in the change request log, with their decisions. Filtering the rows by one ID gives that requirement’s history — the subject of how to track changes to requirements. Counting the rows per month against the baseline gives requirements volatility.

Change log vs change request log

The two names are often used for the same thing. The accepted answer to “Is Change log the same as Change Request log?” on Project Management Stack Exchange: “A change request log is synonym with change log, although the most used term is change log” (Project Management Stack Exchange, 2021).

On a project with written requirements, it helps to keep the two halves apart, even in one file:

A request that is declined has a line in the first log and none in the second. A request approved as a swap — one feature in, another of the same size out — has lines in both, even when the cost and the dates do not move. Another answer on the same question insists on it: “The “puts and takes” have to be documented formally and agreed upon” (Project Management Stack Exchange).

A release changelog is a different thing: “A changelog is a file which contains a curated, chronologically ordered list of notable changes for each version of a project,” in the definition of Keep a Changelog. It describes the software as shipped; the change log on this page describes the requirements as agreed.

Change log in Excel or Google Sheets

One row per requirement changed, with these columns: date, change request, requirement ID, type, was, now, why, decided by, version from, version to, also updated. Then:

• Repeat the change request on every row it produced, so filters work.
• Never delete or edit a row. A mistake gets a new row that corrects it.
• Protect the sheet so that only the person who keeps the log can add rows.
• Filter by requirement ID to see one requirement’s history, or by change request to see everything one change reached.

Change log in Confluence and Jira

In Confluence, one way is a change log table at the bottom of each requirements page, as the requirements in Confluence note suggests; another is one log page for the project. Page history is not a change log: it shows what was edited, not why or on whose decision.

In Jira, keep each change request as an issue and link it to the requirement issues it changes. The issue history records every field edit; the change log records the decisions. The difference matters when someone asks why a requirement says what it says — see requirements in Jira.

How to keep a change log

1. One log per project, where the client can read it.
2. Write the entry when the change is approved, with the request number and the new version.
3. Never edit an entry. Correct it with a new one.
4. Every requirement change gets an entry, including the ones agreed on a call and done as a favour — written down after the fact. Why those matter most is in informal requirements changes.
5. Read it at every sign-off. The entries since the last baseline are what the client is agreeing to this time.

Logging a change and updating the requirements are one job, not two. Asked “Does a change request change the requirement specification?”, one answer on Project Management Stack Exchange replied: “Yes, you do because otherwise nobody will be able to track the changes of the system, and know how your system is supposed to work” (Project Management Stack Exchange, 2013).

Where Specroot fits

This is the problem Specroot works on: every change to the agreed requirements kept with the request it came from, the decision, and the versions before and after — so that the change log is a record of what happened, not a spreadsheet someone has to remember to fill in. Specroot for agencies and consultancies.