Это должно более или менее «естественно» соответствовать требованиям.
Есть ли у вас четкое понимание того, что должно делать приложение, его масштаб и т. Д.?
Это действительно зависит от того, о каком размере проекта вы говорите: подход и строгость, которые нужно применять, отличаются для коммерческого создания программного обеспечения команды от личного проекта.
Тем не менее, некоторые общие советы:
1) На выбранном вами носителе (мне нравятся доски) начните перечислять варианты использования или истории пользователей. Продолжайте, пока не почувствуете, что получили самые важные / охватывающие 80%.
2) Когда вы убедитесь, что у вас есть «ЧТО» (варианты использования) кратко и более или менее достаточно определены, вы можете приступить к разработке «КАК» (объекты, алгоритмы и т. Д.). Я бы предложил уклон в сторону меньшей сложности: вам не нужна сложная и многослойная иерархия объектов, если она вам действительно не нужна (и даже тогда, вероятно, вам не нужна).
3) Я склонен применять правило «без кодирования» до тех пор, пока не будут выполнены # 1 и # 2, несмотря на одноразовые прототипы или исследования конкретных подходов. Очень легко начать разбирать код и обнаружить, что вы «пойманы в ловушку» объектной моделью, которую вы придумали, прежде чем вы полностью поймете, что именно вы создаете.
4) Когда вы закончите сбор требований, вы можете использовать любой из # подходов, чтобы начать разбивать функциональные блоки / объекты / роли / и т.д. Карты CRC - один подход; Я также имел успех с диаграммами классов и последовательностей UML.
Мне лично нравится делать много досок на UML; Я часто снимаю фотоаппаратом для архивации мышления / подходов. Это гораздо лучше, чем ничего, когда дело доходит до документации бедняка или ответа на вопрос «почему мы / не сделали ...» через 2 месяца.