1. «Представитель заказчика должен иметь возможность редактировать документ на этапе согласования»
2. «Руководитель подразделения должен иметь возможность изменить контрагента на этапе согласования».
Опишем эти два требования в виде концептов, концепты сгруппируем в четыре указанных в топике категории: объект, субъект, действие, условие.
Требование 1:
Объект: документ
Субъект: представитель заказчика
Действие: редактировать
Условие: на этапе согласования
Требование 2:
Объект: контрагент
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования
Попарно сравнивая концепты мы заметим, что совпадают 2 из 4, т.е. семантическое расстояние будет равно 0.5
Предположим, что у нас уже реализовано третье требование: «Руководитель подразделения должен иметь возможность изменить телефон контрагента на этапе согласования».
Здесь видно, что телефон контрагента имеет отношение к контрагенту (телефон является частью сущности контрагент, по большому счету), то между этими концептами можно установить степень «похожести» 0.5 (установим экспертным путем). Рассчитаем семантическое расстояние:
Требование 3:
Объект: телефон контрагента
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования
Оно равняется 0,875
Видим, что требования 2 и 3 более близки, чем требования 1 и 2. Когда реализованных требований больше трех уже можно выбирать, какую реализацию допиливать до нужного функционала.
Очень красочно описана жизнь программиста. Но если ты не фрилансер и вынужден работать в команде, то лучший график — график, подходящий всем, а не в ночные часы. А если компания еще и с филиалами в других городах, то это единственно верный график, потому что не программистами одними живет компания.
Мне не хватает достойного аналога IBM Rational Rose, WebSphere и Lotus Domino Designer. Если для первых двух еще можно как-то приспособить Dia и Umbrella, то для последнего придумать нечего. Только VirtualBox…
IBM предлагает линейку продуктов, которая замечательно интегрируется между собой. И да, мы ее используем — IBM ClearQuest для багов, IBM RequisitePro для требований и IBM Rational Rose для моделирования. Проекты, в которых это гораздо более управляемы чем те, в которых требования документируются просто в ворде и через него же согласовываются.
Это самое то место, где теория расходится с практикой. Согласен, и ITIL не идеален, но дает хорошую почву для начала работы и чем ближе ваши требования будут к описанным в стандарте, тем легче будет описанные там же методики использовать в реальных проектах.
В общем смысле, по всем 10 пунктам можно вообще сказать одно — требование должно быть написано так, чтобы разработчик мог понять, что он должен разработать, а тестировщик протестировать.
Заказчик обычно не знает, чего он хочет. И тем более не знает, если это не разработка новой системы, а адаптация какой-либо системы под нужды заказчика.
Заказчик в первую очередь заинтересован в том, чтобы его бизнес шел в гору, а не в том, чтобы у него была система. Если он не может сам адекватно объяснить, что от системы требуется, то задача аналитика (как бизнес-консультанта) ему навязать решение в конце-концов.
Как раз для того, чтобы каждую неделю систему не переделывать и нужно управлять требованиями. Здесь много топиков с текстом а-ла «сначала пишите ТЗ, потом делайте». ТЗ — тоже в определенной степени документ, регламентирующий требования. Согласитесь, когда оно жестко прописано разрабатывать гораздо легче.
1. «Представитель заказчика должен иметь возможность редактировать документ на этапе согласования»
2. «Руководитель подразделения должен иметь возможность изменить контрагента на этапе согласования».
Опишем эти два требования в виде концептов, концепты сгруппируем в четыре указанных в топике категории: объект, субъект, действие, условие.
Требование 1:
Объект: документ
Субъект: представитель заказчика
Действие: редактировать
Условие: на этапе согласования
Требование 2:
Объект: контрагент
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования
Попарно сравнивая концепты мы заметим, что совпадают 2 из 4, т.е. семантическое расстояние будет равно 0.5
Предположим, что у нас уже реализовано третье требование: «Руководитель подразделения должен иметь возможность изменить телефон контрагента на этапе согласования».
Здесь видно, что телефон контрагента имеет отношение к контрагенту (телефон является частью сущности контрагент, по большому счету), то между этими концептами можно установить степень «похожести» 0.5 (установим экспертным путем). Рассчитаем семантическое расстояние:
Требование 3:
Объект: телефон контрагента
Субъект: руководитель подразделения
Действие: редактировать
Условие: на этапе согласования
Оно равняется 0,875
Видим, что требования 2 и 3 более близки, чем требования 1 и 2. Когда реализованных требований больше трех уже можно выбирать, какую реализацию допиливать до нужного функционала.
php_flag display_errors offи подобные…
IBM предлагает линейку продуктов, которая замечательно интегрируется между собой. И да, мы ее используем — IBM ClearQuest для багов, IBM RequisitePro для требований и IBM Rational Rose для моделирования. Проекты, в которых это гораздо более управляемы чем те, в которых требования документируются просто в ворде и через него же согласовываются.
В общем смысле, по всем 10 пунктам можно вообще сказать одно — требование должно быть написано так, чтобы разработчик мог понять, что он должен разработать, а тестировщик протестировать.
Заказчик в первую очередь заинтересован в том, чтобы его бизнес шел в гору, а не в том, чтобы у него была система. Если он не может сам адекватно объяснить, что от системы требуется, то задача аналитика (как бизнес-консультанта) ему навязать решение в конце-концов.
Как раз для того, чтобы каждую неделю систему не переделывать и нужно управлять требованиями. Здесь много топиков с текстом а-ла «сначала пишите ТЗ, потом делайте». ТЗ — тоже в определенной степени документ, регламентирующий требования. Согласитесь, когда оно жестко прописано разрабатывать гораздо легче.