Requirements and coverage

A requirement in Sekee is a thin reference row: usually a Jira issue, with its title, status and priority cached locally, occasionally a statement typed by hand. It deliberately has no status of its own.

Why it has no status

Because a status would have to be maintained, and a maintained status is a status that goes stale. Instead, everything the Requirements screen tells you is derived on every read from the evidence underneath it.

How coverage is worked out

Three inputs, per linked test case:

1. The latest verdict on that case from bug hunt runs — hidden hunt copies excluded, because a case taken out of a hunt is not something that hunt says about it
2. Open bugs raised against the case — Open or In progress
3. The last result of any automated test linked to the case

Then: worst wins, and "passing" means every linked test says so. One failing case, or one open bug, is enough to stop a requirement reading as covered.

Nothing anywhere stores a coverage word. There is no cache to invalidate and no job to re-run.

:::tip The most common cause of a requirement reading as uncovered A test case that was written for it and never linked to it. Coverage is derived from links, so an unlinked case contributes nothing. This is the failure the default AI rule exists to prevent, and what Test case review is for catching. :::

Adding a requirement

:::note Recently changed Requirements → Create (it was labelled Add requirement) now opens a page of its own rather than a dialog over the list. It used to be the same pop-up the test case view shows, which meant writing the only record of a requirement — a title and a full editor — inside a box that scrolls. The test case view still uses the dialog; see Linking test cases below. :::

Requirements → Create, which opens a full page — or press s n r from anywhere in the app. Pick where it comes from at the top:

• Write one — a one-line title and, optionally, a rich text description, so the row can be the actual record of the requirement rather than a label. This is the one to use when your requirements live in a document rather than a tracker.
• Jira issue — search your connected instance and pick the issue, or type an issue key and press Enter. The key, title, status and priority are cached on the row and refreshed on demand or by webhook.

Sekee starts you on Jira issue when the organization has Jira connected, and on Write one when it does not. If Jira is not connected the page says so and tells you who can connect it — and a key typed in the meantime is kept until then.

Cancel goes back to the list without saving.

Priority and tags

:::note Recently changed Priority and tags are new on requirements. :::

Priority — Highest, High, Medium, Low, Lowest, Jira's own default scheme. For a hand-written requirement it is yours to set, and defaults to Medium. For a Jira requirement it is cached from the issue and read-only here: edit priority in Jira and let it refresh. A Jira priority outside this five-word scheme is shown exactly as Jira has it, and for sorting and for the Insights charts it is mapped to the nearest of the five, or Medium when it cannot be placed.

Tags — free-form labels, using the same picker and the same normalising (lower-cased, trimmed, duplicates dropped) as a test case's tags. Tags are set when writing a hand-written requirement, or afterwards from editing it.

Both appear on Write one when you create a requirement; neither is offered for a Jira issue, because both belong to the issue instead.

Editing a hand-written requirement

:::note Recently changed Editing a hand-written requirement in the app is new. Before this, correcting a typo in one meant deleting the row and writing it again. :::

Owners, admins and members edit a hand-written requirement on its own page, the way a test case is edited: click the name to rename it, pick a priority from the top of the panel, hover the description for Edit, and add or remove tags at the bottom. Each one saves on its own. ⋯ → Edit at the end of a row in the list opens the page with the description ready to write in. A Jira requirement has no Edit: it is edited in Jira and refreshed, same as its description (below).

:::note Recently changed Editing used to be a dialog with all four fields in it, opened from an icon at the end of the row. Edit and Delete are in the row's ⋯ menu now, and Edit opens the requirement's page. :::

Descriptions written by an assistant

:::note Recently changed An assistant connected through the AI connector can now write the description of a hand-written requirement. :::

A requirement's description is on its page. When the words there came from an assistant rather than a person, it says Written by AI beside the heading.

Two things about that mark are worth knowing:

• It describes the text, not the requirement. Rewriting the description yourself clears it — unlike a test case's AI generated mark, which records how the case came to exist and stays true forever.
• It only ever appears on hand-written requirements. A Jira requirement's description belongs to the issue: Sekee caches it and refreshes it, and refuses to let an assistant edit it. Edit those in Jira and refresh here, or the next sync would silently throw the edit away.

An assistant writing a description replaces it, so a request to "add a sentence" means the assistant reads the description first and sends the whole thing back with the sentence in it. That is one read and one write rather than an append, and the practical consequence is that an edit made from a stale reading overwrites anything changed in between — worth knowing if two people are working on the same requirement at once.

Linking test cases

Link from either side: from the requirement, or from a test case's Requirements section. A case can prove several requirements and a requirement can be proved by several cases.

From a test case, Link requirement opens a dialog rather than a page, because picking one there is a step inside something else. It has a third choice the Requirements page does not: Already in Sekee, a searchable list of every requirement in the project, which is usually what you want — a requirement is often already here because somebody linked it from another case last week.

Automated tests are linked to test cases, not to requirements directly. That is the chain: requirement → test case → automated test → last CI result.

On a test case, hover a requirement to see what it says. The description scrolls inside the card rather than stopping after a few lines; Show more opens the whole requirement in a dialog, and Open requirement goes to its page.

Reading the screen

Each row shows the requirement, its cached Jira state, its priority, its Author, the cases linked to it, and the derived coverage. The author is the person who wrote the requirement here or linked it from Jira, not the issue's reporter in Jira. Priority is a sortable column. The standard toolbar filters by coverage, by project, by source, by priority and by tag.

:::note Recently changed The Coverage, Source and Priority filters start with nothing ticked, and nothing ticked shows every requirement. They used to start with every box ticked, so narrowing to, say, the uncovered ones meant unticking four boxes. Now you tick the one you want. The Author column is also new. :::

A requirement's own page

Click anywhere on a requirement's row in the list to open its page; the open icon beside the title says so when you point at the row. The page is laid out like a test case — one panel, with:

• its coverage and priority along the top
• the description in full, with Jira's attachments for a Jira requirement
• its tags

then, under the panel as a test case's steps are, a table of the test cases linked to it: how each last did in a bug hunt and in automation, and its open bugs. A row opens its test case; × unlinks it. At the top of the page, Link test cases, Refresh from Jira (Jira only), History, and ⋯ → Remove requirement. A hand-written requirement is edited right there (above).

Each requirement has its own address, so a link to one can be shared.

:::note Recently changed Requirements had no page of their own — the list was the only place to read one, and clicking a row opened its description underneath it. :::

Insights

Insights, in the toolbar, opens a panel built from the requirements currently on screen.

1. Coverage — a donut of uncovered, untested, passing, failing and blocked, with counts.
2. Coverage by priority — stacked horizontal bars, one per priority, highest first, split by coverage. It answers "are the important ones tested?"
3. Least-covered tags — the top 8 tags by number of uncovered or untested requirements.
4. Tests per requirement — a histogram of linked test case counts (0, 1, 2–3, 4+), which shows where coverage is thin rather than absent.

What flows back to Jira

If the integration is connected and link syncing is on, Sekee writes a remote issue link on the Jira issue for each linked test case — one per pair, updated rather than duplicated — with the case name and a one-line summary of the evidence. See Jira.