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

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

Сходить на тренинг.
Один день вместо двух месяцев. На выходе очень хороший результат.
Впрочем, если у вас времени вагон, то тренинг не ваш метод.

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

Предложение Сергея вполне разумно. Ясно, что оно стоит денег, но если чтение книг в течение 2 месяцев не принесло результата, возможно, Вам нужен учитель.

Кстати, а какие книги Вы читали? Кстати по отделу кадров вполне неплохо (правда не полно) написано здесь: http://book.uml3.ru

Кстати. Главное не уметь писать, а уметь верифицировать требования. А вот это, насколько я знаю, нет нигде, кроме как на моем тренинге. Я думаю как тестировщик и верификация для меня всегда стояла на первом месте. Но из-за отсутствия литературы мне понадобилось очень много лет, чтобы научиться. Коберн верификации уделяет непозволительно мало внимания. А у остальных этого, насколько я знаю, просто ничего нет.

За много лет конференций мне известны три доклада по верификации. Теперь появился четвертый: http://analystdays.ru/ru/talk/45151

Предложение Сергея вполне разумно. Ясно, что оно стоит денег, но если чтение книг в течение 2 месяцев не принесло результата, возможно, Вам нужен учитель.

Кстати, а какие книги Вы читали? Кстати по отделу кадров вполне неплохо (правда не полно) написано здесь: http://book.uml3.ru

Я с вами полностью согласен, что если изучение не приносит результата, то нужен человек, который сможет помочь разобраться в изучаемом материале.
Список прочитанных мною книг:

• Дж. Рамбо и М. Блаха - UML2.0 Объектно - ориентированное моделирование и проектирование
• Карл Вигерс и Джой Битти - Разработка требований к программному обеспечению
• Эрик Эванс - Предметно - ориентированное проектирование
• С.А. Орлов и Б.Я. Цилькер - Технологии разработки программного обеспечения
• Алистер Коберн - Современные методы описания функциональных требований к системам

Все книги хорошие, но за одним исключением, они ориентируется на большие проекты, которые делают копании, с не малочисленным персоналом.
Чтобы не разводить холевар, я понял из прочитанных мною книг, самые важные этапы Анализа требований:

• Модель объектов, которая строиться на диаграмме классов
• Древо функций
• Составление сценариев использования
• Составление концептуальной модели проекта
• Делим проект на итерации

Буду рад, волне аргументированной критике.

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

И мне кажется, что начинать надо с концепции системы - что это такое, зачем она нужна и что она будет уметь делать и чего не будет.
Затем основные(высокоуровневые функции)
Ну а дальше либо пользовательские истории либо варианты использования с дальнейшим их описанием.

Но это мое ИМХО.

Буду рад, волне аргументированной критике.

В книге Дж. Рамбо и М. Блаха - UML2.0 Объектно - ориентированное моделирование и проектирование достаточно точно и ясно описан процесс проектирования по мнению авторов.

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

ФТ хорошо получать из описания бизнес-процесса (бизнес-процессов), одни или несколько шагов БП могут стать вариантом использования.

С другой стороны можно пойти от модели объектов-предметной области, на самом деле это переплетающиеся шаги. Главное, что нужно начать с того, что понятнее и быстрее позволяет двигаться к цели.

А так есть два подхода -
подход сверху вниз, от цели к ее декомпозиции на функции
подход снизу вверх, от элементарных частей к цели.

В реальности мы используем одновременно оба подхода. НО если вы используете объектно-ориентированный подход, то в большей части идете по второму подходы, т.е. описываете систему как некоторую совокупность взаимодействующих объектов, которые выполняют требуемые функции и проявляют требуемое качество

Ориентация на use cases тоже по сути подход снизу вверх, в котором определяются действующие лица (т.е. окружение системы) и определяются сценарии использования ими системы.

Отдел кадров:  сначала понять кто будет взаимодействовать с ИС Отдел кадров - какие люди, какие организации, какие системы. В принципе это просто контекстная диаграмма аля DFD например.

Далее для каждого такого действующего лица определяем эти сценарии использования (т.е. задачи). В результате получим кусочки функциональности, которыми должна обладать ИС ОТдел кадров:

Сотрудник ОК: Прием на работу, Перевод на другую позицию, Увольнение сотрудника, Оформить больничный, Вести кадровые данные и т.п.
и т.п.
Кроме того, диаграмма классов позволяет понять, все ли сценарии учтены, ведь по сути для каждой сущности нужно предусмотреть ввод, изменение, удаление - как минимум, поиск....