Ну прямо полноценную концепцию делать не надо, если у вас нет задачи обосновать инвестору эффективность проекта и логически доказать, что нужно делать именно эти фичи для достижения целей проекта.

Можно сделать её замену, которую я называю карточкой проекта.

Вот пример карточки, с заполнения которой мы начинаем на моём онлайн-курсе.

Ок, значит делаю "Карточку проекта".
Я просмотрел пример карточки и у меня возникли некоторые вопросы:
1. У меня получается, что заказчик отсутствует. Это может быть такое? В связи с этим вопросом автоматом вопрос про то, что писать в Целях заказчика?
2. про "Количество экранов" и "Количество отчетов". На данном этапе я точно не могу сказать сколько будет отчетов и экранов. По этому заполнил поля примерными значениями.
Еще получается, что конкурентов нет (Я же первый хочу создать бесплатный архиватор см. самое начало темы)

Карточку проекта я прикрепил.

Заказчик — это роль. Заказчик выбирает, чью и какую проблему решать. В вашем случае заказчиком выступаете вы сами или директор воображаемой вами компании-разработчика.

Цель для заказчика:   Предоставить бесплатный архиватор
Пользователи: Любые пользователи компьютеров

Вот вы говорите «Я, Роман Сидоркин, хочу предоставить ВСЕМ пользователям компьютеров бесплатный архиватор».

А зачем вам это? И зачем им это? Многие люди могут себе позволить платный архиватор. Многие пользователи хотят платить за софт, чтобы получить гарантии его работоспособности. Многие пользователи мобильных компьютеров (смартфонов) не нуждаются в бесплатном архиваторе.

Как говорится, максимальный охват аудитории — только у атомной бомбы. Чем Уже размер вашей аудитории, тем больше шансов, что вы сможете по-настоящему понять её потребности и решить её проблему.

Решаемая проблема:
•   Сложность просмотра и работы с ZIP архивами

Какая именно сложность? Проблема раскрывается через последствия. Если у проблемы нет последствий, связанных с нежелательными расходами ресурсов, таких как деньги, время и когнитивная мощность человека, то это не проблема.

При распаковке архива, созданного на Windows, на MacOS происходит порча имён файлов и пользователю трудно в них ориентироваться — а именно, он теряет несколько минут на выбор нужного файла и/или их ручное переименование (потеря времени)?

Встроенные средства ОС для работы с ZIP-архивами не поддерживают архивирование файлов объёмом больше 4Гб? А именно — ему приходится искать способы сначала разбить большой файл на несколько, а потом уже архивировать (потеря времени)?

Половине пользователей не удаётся понять, как сжать файл системными средствами и им приходится платить больше за трафик или хранилище в облаке или просить помочь знакомых (потеря времени, денег, репутации)? таскать на флешке с риском потери (потеря нервов, риск финансового ущерб)?

От того, какую проблему решаем, напрямую зависит состав фич.

Но если вам не интересна фаза бизнес-анализа, то можно идти дальше и делать контекстную диаграмму, например.

Денис, спасибо за ответы!
Вот что у меня получилось:
Заказчик – IT_USER (Я)

Решаемая проблема:
1.Потеря времени, связанная с необходимостью переименования распакованных файлов, в связи с порчей имен файлов, вызванная распаковкой архива.
2.Потеря времени, связанная с поиском способов разбиения большого файла на несколько в связи с невозможностью встроенными средствами Windows осуществления архивации файлов объемом больше 4Гб
3.Трудность освоения функционала по архивации и распаковке архивов ZIP встроенными средствами Windows.

В соответствии с Проблемами, получается следующий список Фичей:
1.   Устранение фактов порчи имен файлов в процессе распаковки
2.   Возможность задания размера сегмента, на которые будет делиться большой файл при архивации
3.   Простой и легкий интерфейс упаковки и распаковки файлов
4.   Возможность выбора степени сжатия, алгоритма сжатия.
5.   Поддержка шифрования и парольная защита архива, так и отдельных файлов в архиве

Но если вам не интересна фаза бизнес-анализа, то можно идти дальше.

Мне бы не очень хотелось долго сидеть на фазе Бизнес-анализа. Но пропустить её я не хочу. Поэтому я хочу наполнить документа "Карточка проекта" данными, которые минимально или хотя бы уместно подходили бы под мою задачу. Так сказать документ на троечку чтобы... Так как в данный момент бизнес-анализ не особо интересует...

Немного забегая вперед...
Вот обдумываю варианты использования. Получается что на верхнем уровне абстракции у меня есть следующие варианты использования:
1. UC "Упаковка файлов в архив"
2. UC "Распаковка файлов из архива"
3. UC "Тестирование архива"
4. UC "Удаление архива"

Я верно понимаю, что такие Варианты использования, как: "Просмотр содержания архива", "Шифрование архива", "Добавление файлов в Архив", "Обновление файлов в архиве" - не нужно описывать в верхнем уровне абстракции или все возможные расширяемые и включаемые Варианты использования нужно поместить на верхний уровень... Я думаю, что добавление элементов в диаграмму нужно осуществлять поэтапно...

На типовой диаграмме способов применения приложения показываются все группы сценариев, которые заканчиваются ценным для пользователя результатом, который он может пойти и применять уже за рамками приложения.

На типовой диаграмме способов применения приложения показываются все группы сценариев, которые заканчиваются ценным для пользователя результатом, который он может пойти и применять уже за рамками приложения.

Денис, я верно понял, что в моем случае на диаграмме вариантов использования будут следующие сценарии:
1. UC "Упаковка файлов в архив"
2. UC "Распаковка файлов из архива"
3. UC "Тестирование архива"
4. UC "Удаление архива"
5. UC "Создание само распаковывающегося архива"
6. UC "Шифрование архива"

Следующие сценарии, к примеру: "Задание параметров архивации", "Выбор файлов", "Просмотр содержимого архива" , не имеют сами по себе (отдельно от контекста) ценности для пользователя, верно? (связи я не расставляю пока что... просто набросок)

Ответить на этот вопрос однозначно нельзя. Я рекомендую формулировки способов применения в виде «Сделать <результат>», например, «Написать письмо», «Забронировать билет». В ваших формулировках непонятно как минимум, архив — это файл или виртуальное пространство типа vault? Зачем тестировать архив? Что это за дикие пользователи такие, для которых тестирование архивов является ценным результатом?

Способы применения не появляются из воздуха, лучше их выявлять из контекстных сценариев (или бизнес-процессов). Вы пропустили важные шаги.

В ваших формулировках непонятно как минимум, архив — это файл или виртуальное пространство типа vault?

Значит все же необходимо написать Vision, так как там есть раздел про термины и сокращения?

Способы применения. Их выявлять из контекстных сценариев (или бизнес-процессов). Вы пропустили важные шаги.

Что именно я пропустил? Подскажите мне, пожалуйста... Какого описания у меня нет?
Возможно стоит написать пользовательские требования?

А что, Варианты использования и сценарии не описывают уже требования к ПО? Ведь с них начинается разработка...

Use Cases — это и есть часть пользовательских требований (функциональных).

Для продуктов для домашнего пользования я рекомендую выделять use case'ы из контекстных сценариев.

Разработайте несколько описаний жизненных ситуаций для персонажей и из них станет понятно, какие юскейсы нужны.

Значит все же необходимо написать Vision, так как там есть раздел про термины и сокращения?

Термины и сокращения — это типовая часть ЛЮБОГО документа, а не только концепции. Если проект большой, делается в виде отдельного документа — Глоссария. В вашем случае вы можете или ввести определение по тексту и далее его использовать, или использовать более точные формулировки, типа «Создать упакованный ФАЙЛ».

Денис, я верно понимаю, что в моем случае лучшим выбором станет Гибкая методология разработки ПО? Я спрашиваю это в связи с тем, что Истории пользователей - артефакт, фигурирующий в AGILE и XP...

А кто сказал слово «история»?

Context Scenario, Usage Scenario, Use Case и User Story — это 4 разных человека. Я говорил про первый.