Refining Android Requirements

Requirements Refinement

This skill takes raw requirements (from Jira tickets, Confluence pages, or free-text descriptions) and produces a structured, implementation-ready specification through systematic gap analysis.

Key principle: This skill identifies gaps and produces specifications. It does NOT propose solutions or architecture — that is the responsibility of the planning-android-implementation skill.

---

Step 1: Source Consolidation

Combine all input sources into a single working document. For each requirement, note its source:

- [Source: PM-12345] User must be able to configure timeout
- [Source: Confluence] Timeout range is 1-60 minutes
- [Source: User] Default timeout should be 15 minutes

Flag any contradictions between sources for immediate resolution.

---

Step 2: Gap Analysis

Evaluate the consolidated requirements against the following 5-category rubric. For each category, check every item and note whether it is covered, partially covered, or missing.

A. Functional Requirements

B. Technical Requirements

C. Security Requirements

D. UX/UI Requirements

E. Cross-Cutting Concerns

---

Step 3: Present Gaps

Organize all identified gaps into two categories:

Blocking Questions

Questions that must be answered before implementation can begin because they change the architecture, data model, or core flow.

Format each question as:

**G[N]** ([Category]) — [Question text]
  Context: [Why this matters / what depends on the answer]

Non-Blocking Questions

Questions that have reasonable defaults and can be resolved during implementation. Note the assumed default.

Format each question as:

**G[N]** ([Category]) — [Question text]
  Default assumption: [What we'll assume if not answered]
  Context: [Why this matters]

---

Step 4: Produce Specification

After the user answers blocking questions (and optionally non-blocking ones), produce a structured specification:

## Overview

[1-2 paragraph summary of the feature, its purpose, and scope]

## Functional Requirements

| ID | Requirement | Source | Notes |
|----|------------|--------|-------|
| FR1 | [requirement] | [source] | [any notes] |
| FR2 | ... | ... | ... |

## Technical Requirements

| ID | Requirement | Source | Notes |
|----|------------|--------|-------|
| TR1 | [requirement] | [source] | [any notes] |
| TR2 | ... | ... | ... |

## Security Requirements

| ID | Requirement | Source | Notes |
|----|------------|--------|-------|
| SR1 | [requirement] | [source] | [any notes] |

## UX Requirements

| ID | Requirement | Source | Notes |
|----|------------|--------|-------|
| UX1 | [requirement] | [source] | [any notes] |

## Open Items

Non-blocking items with assumed defaults that may be revisited:

| ID | Question | Assumed Default | Category |
|----|----------|----------------|----------|
| G[N] | [question] | [default] | [category] |

## Source Documentation

| Source | Type | Link |
|--------|------|------|
| [name] | Jira / Confluence / User-provided | [link if available] |

Output Guidelines

• Requirements use numbered IDs (FR1, TR1, SR1, UX1) for traceability through implementation
• Each requirement cites its source (ticket, page, or user-provided)
• Technical requirements use table format for structured key/value data
• Interface signatures are included as fenced code blocks when applicable
• Open items preserve the gap ID (G[N]) for cross-referencing