Прошу заметить, все в рамках дозволенного, все по честному, все по правилам ;DЕсть в этом отчете раздел Раздел "Функции и задачи создаваемой АС", который содержит.
• 1) обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очередности внедрения,
...
Что вам мешает обосновать этот перечень функций путем использования вариантов использования Системы? ГОСТ не определяет методику формирования требований, он оставляет это на откуп аналитику, а там уже кому как нравится. Хочешь используй это, хочешь это... И это правильно.
Сорри, я не очень уловил мысль. С моей точки зрения, обоснование перечня автоматизируемых функций должно опираться, как вариант, на экономических расчетах (смотрим на процесс, автоматизируем только те функции, автоматизация которых даст в совокупности наибольший выигрыш процессу в целом, скажем, позволит сократить время/улучшить качество/ .... что в свою очередь может быть выражено в денежном эквиваленте), или на иных критериях (например безопасность). Не вполне понял как это связано с такой формой представления пользовательских требований как юзкейсы?
Давайте все-таки придерживаться здравого смысла 
Требования пользователя - это требования пользователя (согласитесь, с этим трудно поспорить 
). Но где вы видели пользователя, который вам сразу выдает features ?
Требования пользователя по ГОСТ <> Пользовательским требованиям по Вигерсу. Это скорее всего как раз то, что, например, в RUP называют stakeholder requests и на это есть отдельный артефакт (и шаблон документа). По сути, это набор "хотелок", который может относиться как к бизнес-процессам или к информационной системе в целом, так и к деталям ее реализации. Разного уровня и разных точек зрения.
Насчет пользователя, который сразу выдает features - это запросто. Просто пользователь может не знать, что он формулирует то, что системные аналитики называют фичей :-).
Простой пример. Пользователь говорит "хочу чтобы программа оценивала шанс продать товары из нашего каталога по выбранному клиенту на основании истории покупок и <пр. данных> о клиенте". Это по ГОСТ "требование пользователя" - очевидно, да. Это есть фича? Однозначно да, при условии, если это будет ОТЛИЧИТЕЛЬНОЙ особенностью данной системы, по сравнению с тем что было раньше или от аналогичного ПО :-).
...Моя точка зрения - это не проблема ГОСТа, это просто не его поле боя. Вы хотите получить от него то, для чего он просто не предназначен. 34-я серия определяет в основном перечень работ на различных стадиях и этапах разработки и перечень разрабатываемых документов. При этом, ГОСТ не запрещает вам определять свой перечень работ и документов, пожалуйста, согласовываете с заказчиком, прописываете в ТЗ и вперед. Во всем остальном вам дали свободу
Тогда какое от такого стандарта value, если я могу его кастомизировать до неузнаваемости? Я из него SCRUM с итеративной моделью ЖЦ сделаю, и что это считать ГОСТом? Тут куда не кинь - проблема ... по ГОСТ как раз написать плохо ТЗ можно, и никто не сможет доказать, что ТЗ написано плохо. В отличие от тех же юзкейсов, где есть определённые методики их написания. Возможно наличие таких методик для ГОСТа упростило бы ситуацию.
Просмотр сообщений