Добрый день!!
В этой теме я хотел бы попробовать с вашими подсказками и рекомендациями пройти стадии выявления требований, анализа и проектирования.
Еще одно допущение: допустим, что ценность и необходимость программы уже доказана.

Умышленные Допущения и Ограничения:
На данный момент пользователи могут использовать следующие типы архивов: ZIP, RAR, TAR. Пользователи располагают свободными и коммерческими программами для работы с RAR и TAR. Но вот с ZIP бесплатных программ нет.   


Уважаемые участники и жители форума! По возможности и при желании высказывайте свои предложения, замечания и критику.

Если вы хотите создать продукт для рынка, то классическая инженерия требований (requirements engineering) вам в этом слабо поможет, смотрите методы из продуктового управления (product management).

Современные техники создания продуктов с нуля предполагают такие фазы работ:
1. Найти и доказать ценность продукта
2. Построение бизнеса по созданию и развитию продукта

Работа по поиску и обоснованию ценности продуктов сводится к выработке и проверке гипотез о проблемах людей и возможных решениях этих проблем людей.

Формулировка проблемы «Отсутствие возможности работы с ZIP архивами» мне кажется надуманной.

Простой способ это проверить — выйти на улицу и спросить у первых попавшихся 30 человек, есть ли у них такая проблема.

Технари часто формулируют проблему, как отсутствие того решения, которое у них уже есть в голове.

Велосипед решает не проблему отсутствия велосипеда, а проблему дешёвого и здорового перемещения.
Отвёртка решает не проблему отсутствия отвёртки, а проблему сложности надёжного скрепления материалов.
И т.д.

В базовой литературе формула продукта (как заказного, так и для открытого рынка), имеет 4 компонента:
1. Чью проблему решаем
2. Какую проблему
3. Каким образом
4. Чем наше решение лучше конкурентов.

Ответ на вопрос «чью проблему» позволяет получить предварительную оценку размера аудитории.
Ответ на вопрос «какую проблему» позволяет уточнить размер аудитории и получить представление о важности и сложности проблемы.

Проблемой называется не любая ситуация, а лишь такая, которая ведёт к значимым для носителя проблемы последствиям. Отдельный философский вопрос — является ли неосознаваемая проблема проблемой или нет.

Проблемы
P1. Отсутствие возможности работы с ZIP архивами
…
 Ведь по сути моя программа ничего "оригинального" не предлагает. Все то же, что есть у конкурентов (платных)

Может я чего-то не понимаю, но вроде 7-zip:
А. Бесплатная
Б. Мультиплатформенная
В. Работает с ZIP
Г. В целом терпимо

на маке у меня есть https://itunes.apple.com/ru/app/the-unarchiver/id425424353?mt=12

Добрый день, Denis.
Спасибо, что откликнулись и написали свои мысли по моей теме.
Скорее всего я не совсем верно обозначил суть задачи...
Задача заключается в следующем: понять и попрактиковаться с помощью участников этого форума в выявлении требований к ПО, созданию UseCase. Хотелось бы конечно спросить мнения живущих на форуме людей по поводу диаграмм классов и взаимодействия, кооперации... Но это позже.
В качестве примера я взял программу, которая будет работать с ZIP архивами и придумал вымышленную ситуацию в которой нет бесплатных программ по работе с ZIP. Все это конечно есть и куча написано платных и бесплатных программ...
Предлагаю опустить работы по выявлению рынка, стратегии продукта и т.д. Просто по умолчанию решено делать архиватор. Вот я и решил попрактиковаться в анализе и проектировании на примере реализации несложной программки.  Думаю понятнее стало теперь)))
в Итоге вот что получается:
Необходимо разработать архиватор для работы с ZIP архивами. Постановщик требований, аналитик, архитектор, программист - это все я.
 

Может я чего-то не понимаю, но вроде 7-zip:
А. Бесплатная
Б. Мультиплатформенная
В. Работает с ZIP
Г. В целом терпимо

Это все верно, но для примера допустим, что этой программы нет)

Современные техники создания продуктов с нуля предполагают такие фазы работ:
1. Найти и доказать ценность продукта
2. Построение бизнеса по созданию и развитию продукта
Работа по поиску и обоснованию ценности продуктов сводится к выработке и проверке гипотез о проблемах людей и возможных решениях этих проблем людей.

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

Необходимо разработать архиватор для работы с ZIP архивами. Постановщик требований, аналитик, архитектор, программист - это все я.
 

Хорошо, делайте, а мы посмотрим:)

ок, тогда я бы рекомендовал доработать разделы
1. Цели создания ПО
2. Назначение ПО
3. Контекст применения
и переформулировать ключевые свойства.

«Работать с ZIP» — это не фича, не потребность и не задача.

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

В заказной разработке определить рамки ПО помогает заказчик, который приоритизирует с помощью аналитика проблемы и фичи и с помощью ПМа обрезает рамки по срокам и деньгам.

В вашем случае вы можете решить волюнтаристски, какие фичи делать.

Рекомендую делать не более 5-ти фич.

ок, тогда я бы рекомендовал доработать разделы
1. Цели создания ПО
2. Назначение ПО
3. Контекст применения
и переформулировать ключевые свойства.

Денис, я верно понимаю, что мне необходимо разработать документ VISION?