Одна статья по требованиям не может раскрыть тему, так что не понятно до конца, что именно добавлять.
Думаю, с точки зрения пользы для Процесса Завалишина можно добавить две самых главных вещи, которые в свое время нам всем принесли больше всего неприятных минут, часов и дней:
1. Требования -- это инструмент коммуникации -- передачи ожиданий заказчика в команду и к самому заказчику год спустя, который уже свои ожидания изменил, естественно. Сегодня, в отличие от СССР с его ЕСКД/ЕСПД мы всегда явно регулируем потоки информации между бумагой, живым общением и умолчаниями, оценивая риски и стоимость выбранной степени детализации и полноты изложения требований. Как следствие, недостающая живая коммуникация должна быть запланирована (то есть что-то не писать -- это не бесплатно, как могло показаться), а риски снижения детализации и полноты, связанные с будущими разногласиями и рассогласованием разных звеньев работы должны находиться под управлением менеджера проекта.
2. Требования -- это не однородная масса, они классифицируются по видам требований и объектам требований (на самом деле это не все, но тут лишь главное). Из видов для начала достаточно разделять функциональные и нефункциональные. А вот за смешивание объекта требований в одном списке надо сильно бить по рукам. Требования (в упрощенной классификации) могут быть: - к улучшаемой бизнес-системе и ее процессам -- это бизнес-требования - к создаваемой или изменяемой автоматизированной/информационной системе (люди+железо+софт) -- системные требования - к программному средству, изделию, продукту или комплексу
Это вообще разные требования, их нельзя смешивать в одном документе или в одном разделе документа. Если считается, что БТ приходят снаружи и вообще не наше дело, то смешение требований к системе и к программе -- частое явление, которое в первую очередь мешает сделать требования полными и непротиворечивыми.
Думаю, с точки зрения пользы для Процесса Завалишина можно добавить две самых главных вещи, которые в свое время нам всем принесли больше всего неприятных минут, часов и дней:
1. Требования -- это инструмент коммуникации -- передачи ожиданий заказчика в команду и к самому заказчику год спустя, который уже свои ожидания изменил, естественно. Сегодня, в отличие от СССР с его ЕСКД/ЕСПД мы всегда явно регулируем потоки информации между бумагой, живым общением и умолчаниями, оценивая риски и стоимость выбранной степени детализации и полноты изложения требований. Как следствие, недостающая живая коммуникация должна быть запланирована (то есть что-то не писать -- это не бесплатно, как могло показаться), а риски снижения детализации и полноты, связанные с будущими разногласиями и рассогласованием разных звеньев работы должны находиться под управлением менеджера проекта.
2. Требования -- это не однородная масса, они классифицируются по видам требований и объектам требований (на самом деле это не все, но тут лишь главное). Из видов для начала достаточно разделять функциональные и нефункциональные.
А вот за смешивание объекта требований в одном списке надо сильно бить по рукам.
Требования (в упрощенной классификации) могут быть:
- к улучшаемой бизнес-системе и ее процессам -- это бизнес-требования
- к создаваемой или изменяемой автоматизированной/информационной системе (люди+железо+софт) -- системные требования
- к программному средству, изделию, продукту или комплексу
Это вообще разные требования, их нельзя смешивать в одном документе или в одном разделе документа.
Если считается, что БТ приходят снаружи и вообще не наше дело, то смешение требований к системе и к программе -- частое явление, которое в первую очередь мешает сделать требования полными и непротиворечивыми.
Reply
Reply
Leave a comment