2116
Системный Анализ и Требования / Источники требований, полнота требований, взаимосвязь с целями
« : 14 Марта 2007, 00:55:28 »
Часто встречаю ТЗ как некий структурированный список требований.
Когда вижу список, всегда возникают вопросы:
А) откуда взялось данное требование?
Б) Насколько оно обосновано?
В) Достижению какой цели оно служит?
Г) А вдруг какие-то требования упущены?
Да, есть ряд методик по выявлению требований, основная из которых - куча мала - мозговой штурм - понакидаем мнения разных людей разных компетенций, thousand lemmings cannot be wrong, collaboration rules и всё такое. Потом этот поток сознания отсортируем по кучам, выявим дубликаты, разрешим противоречия - типа получим что-то более менее целостное и внушительное. Но - devil's in details - не всегда есть возможность привлечь многих людей и самое главное - заданные мной вопросы остались без ответа!
Есть другой хороший подход - сценарии использования, пользовательские истории и т.д. - Они позволяют компактно свернуть требования и связать их по целям в единые цепочки. Это клёво. За это честь и хвала Якобсону с Коберном. НО. Остаются нефункциональные требования, про которые Якобсон что-то неуверенно мямлит в Use-cases Patterns. Остаётся риск того, что какие-то use-case'ы будут невыявлены. Остаётся вопрос о взаимосвязи целей Пользователя с Целями Заказчика.
"Система должна иметь пользовательскую документацию" - это нужно или нет? Чьё это требование, чьи целям служит? Каким именно? Где они обозначены?
"Система должна иметь документацию по внутреннему устройству" - это чьё? Кто сказал? Почему это решается чьим-то волюнтаристским решением, а не исходя из целесообразности (соответствия конкретной цели, которая иначе не будет достигнута)?
Отдельно стоит рассказать про проблемы ГОСТ 34.602 и главное - как их преодолевать. Но об этом позже.
А пока - как выстроить полный, взаимосвязанный набор требований нужной степени детальности, не ограничивая реализацию и не оставляя провалов в связи с целями системы? Как обеспечить целостное видение системы, а не набор утверждений, висящих в воздухе?
NB: в дополнение - мой полугодичной давности пост "Типовые ошибки ТЗ".
Когда вижу список, всегда возникают вопросы:
А) откуда взялось данное требование?
Б) Насколько оно обосновано?
В) Достижению какой цели оно служит?
Г) А вдруг какие-то требования упущены?
Да, есть ряд методик по выявлению требований, основная из которых - куча мала - мозговой штурм - понакидаем мнения разных людей разных компетенций, thousand lemmings cannot be wrong, collaboration rules и всё такое. Потом этот поток сознания отсортируем по кучам, выявим дубликаты, разрешим противоречия - типа получим что-то более менее целостное и внушительное. Но - devil's in details - не всегда есть возможность привлечь многих людей и самое главное - заданные мной вопросы остались без ответа!
Есть другой хороший подход - сценарии использования, пользовательские истории и т.д. - Они позволяют компактно свернуть требования и связать их по целям в единые цепочки. Это клёво. За это честь и хвала Якобсону с Коберном. НО. Остаются нефункциональные требования, про которые Якобсон что-то неуверенно мямлит в Use-cases Patterns. Остаётся риск того, что какие-то use-case'ы будут невыявлены. Остаётся вопрос о взаимосвязи целей Пользователя с Целями Заказчика.
"Система должна иметь пользовательскую документацию" - это нужно или нет? Чьё это требование, чьи целям служит? Каким именно? Где они обозначены?
"Система должна иметь документацию по внутреннему устройству" - это чьё? Кто сказал? Почему это решается чьим-то волюнтаристским решением, а не исходя из целесообразности (соответствия конкретной цели, которая иначе не будет достигнута)?
Отдельно стоит рассказать про проблемы ГОСТ 34.602 и главное - как их преодолевать. Но об этом позже.
А пока - как выстроить полный, взаимосвязанный набор требований нужной степени детальности, не ограничивая реализацию и не оставляя провалов в связи с целями системы? Как обеспечить целостное видение системы, а не набор утверждений, висящих в воздухе?
NB: в дополнение - мой полугодичной давности пост "Типовые ошибки ТЗ".