5. «Из этих примеров следует важное свойство требований: они дожны быть исчислимы.»
Прикол в том, что чтобы эти требования сделать такими, нужно: а) знать всё множество неповеденческих свойств (атрибутов) ПО/системы, а например в ISO 250X0 их под сотню б) понимать, как выбрать нужные свойства, т.к. описание/обсуждение/согласование каждого из них - это 1-10 часов (т.е. разработка требований ко всем возможным атрибутов может занять 1000 часов) в) нужно отдельно понимать, в чём эти свойства измерять (с этим в международных стандартов хуже) г) нужно выбрать такие метрики, которые в принципе можно измерить экономически рентабельным образом, и желательно не (только) в конце проекта д) нужно понять, как выбрать конкретное значение (сколько вешать в граммах), чтобы не угробить экономику проекта, задав избыточно ограничивающие требования.
И это для любого даже не новичка прям непосильный труд. Поэтому я немного облегчил задачи а, б, в и д выше своими таблицами Бредиса: Reply
1. Для огромного количества проектов она тоже непостижимо сложна.
2. Она игнорирует learning curve. Все "органолептические" оценки продукта в течение времени работы с ним меняются, и сильно. И иногда обучение можно заэнфорсить.
Вообще requirements, как и любая попытка формализовать реальность, всегда неточны и, собственно, весь аджайл (что очень не всегда понимают его адепты) - это попытка формализм ограничить. Попытка, исходящая из понимания, что детальность и глубина проработки стоят дорого. Часто - бессмысленно дорого.
В этом смысле попытка заформализовать один-то качественный показатель редко успешна и редко реально осмысленна, а уж много... да и отслеживать их...
Хотя, как всегда, это вопрос стоимости, сложности и критичности проекта.
1. Именно поэтому на обучении я даю рекомендацию взять на следующем проекте одну (из 12 рекомендуемых) самую главную для проекта метрику качества и поработать с ней. В следующем - ещё одну, и акт далее.
1. Не соглашусь. Поиск стейкхолдеров критически важен для проекта, но это просто шаг на пути к верным требованиям. Если требования можно получить без этого шага - так и надо сделать, и тогда шаг просто не нужен. Требования же краеугольны. Концепция в этом плане важнее, потому что она, де факто, является дополняющей к требованиям и да, я считаю, что без неё нельзя. Но опять же, успешный проект без концепции и с требованиями мне кажется более вероятным, чем наоборот.
2. Я реалист. Я не верю (за исключением некоторых специальных случаев) и теорема Геделя о неполноте меня поддерживает, в возможность зафиксировать полный список требований до подписания акта сдачи. Да и то. Но соглашусь с тем, что правильный подход - формировать список требований, проставлять приоритеты, и только потом вообще прорабатывать их.
Увы, я пишу довольно компактные посты from the top of my mind, тупо не всё вспоминается. Да и, конечно, не всё на эту тему я и знаю.
PS: Спасибо за комментарии. Совершенно неподъёмная тема для одного поста, но обойти нельзя и какая-то обзорная статья для этого цикла нужна. Если хватит времени и сил, то буду возвращаться к теме, обсуждая отдельные подтемы.
7. "Система должна обеспечивать возможность создания, модификации или удаления записи о сотруднике. (Надо понимать, что реализация этого требования в виде файла с логинами и паролями требованию соответствует.)"
Нет, не соответствует. а) Не все сотрудники будут иметь доступ к системе. б) Некоторые сотрудники будут иметь несколько аккаунтов. в) Есть аккаунты не привязанные к персоне. Например "Дежурный сотрудник саппорта". г) К системе будут иметь доступ не только сотрудники организации.
Если кто-то может понять такое требование как "файл с логинами и паролями", то требование сформулировано безобразно. А вообще, неправильная объектная модель (перепутать или слить в одну сущность "сотрудника" и "аккаунт") еще одна очень распространенная ошибка аналитиков. Приводит к тому, что софт придется выкинуть.
8. "Программа и методика испытаний" на мой взгляд полезнее ТЗ. Впрочем, решайте сами.
Соответствует. Мысль была именно в том, что требование сформулировать слишком общо.
Про объектную модель всё верно. Но речь-то не об этом же. Тем более, что реальных систем, в которых эти сущности слиты, миллион, а систем, в которых объектная модель этого участка жизни всеобъемлюща и идеальна - ноль.
Comments 28
Прикол в том, что чтобы эти требования сделать такими, нужно:
а) знать всё множество неповеденческих свойств (атрибутов) ПО/системы, а например в ISO 250X0 их под сотню
б) понимать, как выбрать нужные свойства, т.к. описание/обсуждение/согласование каждого из них - это 1-10 часов (т.е. разработка требований ко всем возможным атрибутов может занять 1000 часов)
в) нужно отдельно понимать, в чём эти свойства измерять (с этим в международных стандартов хуже)
г) нужно выбрать такие метрики, которые в принципе можно измерить экономически рентабельным образом, и желательно не (только) в конце проекта
д) нужно понять, как выбрать конкретное значение (сколько вешать в граммах), чтобы не угробить экономику проекта, задав избыточно ограничивающие требования.
И это для любого даже не новичка прям непосильный труд.
Поэтому я немного облегчил задачи а, б, в и д выше своими таблицами Бредиса: Reply
1. Для огромного количества проектов она тоже непостижимо сложна.
2. Она игнорирует learning curve. Все "органолептические" оценки продукта в течение времени работы с ним меняются, и сильно. И иногда обучение можно заэнфорсить.
Вообще requirements, как и любая попытка формализовать реальность, всегда неточны и, собственно, весь аджайл (что очень не всегда понимают его адепты) - это попытка формализм ограничить. Попытка, исходящая из понимания, что детальность и глубина проработки стоят дорого. Часто - бессмысленно дорого.
В этом смысле попытка заформализовать один-то качественный показатель редко успешна и редко реально осмысленна, а уж много... да и отслеживать их...
Хотя, как всегда, это вопрос стоимости, сложности и критичности проекта.
Reply
В agile тоже есть НФТ и вполне работают.
Reply
Reply
2. Я реалист. Я не верю (за исключением некоторых специальных случаев) и теорема Геделя о неполноте меня поддерживает, в возможность зафиксировать полный список требований до подписания акта сдачи. Да и то. Но соглашусь с тем, что правильный подход - формировать список требований, проставлять приоритеты, и только потом вообще прорабатывать их.
Увы, я пишу довольно компактные посты from the top of my mind, тупо не всё вспоминается. Да и, конечно, не всё на эту тему я и знаю.
6. Это был пример.
Reply
Reply
Нет, не соответствует.
а) Не все сотрудники будут иметь доступ к системе.
б) Некоторые сотрудники будут иметь несколько аккаунтов.
в) Есть аккаунты не привязанные к персоне. Например "Дежурный сотрудник саппорта".
г) К системе будут иметь доступ не только сотрудники организации.
Если кто-то может понять такое требование как "файл с логинами и паролями", то требование сформулировано безобразно. А вообще, неправильная объектная модель (перепутать или слить в одну сущность "сотрудника" и "аккаунт") еще одна очень распространенная ошибка аналитиков. Приводит к тому, что софт придется выкинуть.
8. "Программа и методика испытаний" на мой взгляд полезнее ТЗ.
Впрочем, решайте сами.
Reply
Соответствует. Мысль была именно в том, что требование сформулировать слишком общо.
Про объектную модель всё верно. Но речь-то не об этом же. Тем более, что реальных систем, в которых эти сущности слиты, миллион, а систем, в которых объектная модель этого участка жизни всеобъемлюща и идеальна - ноль.
Reply
Reply
Reply
>Приоритет: Критический, важный, желательный.
Интересно было бы узнать, как с этим работаете в рамках договоров Фикс прайс?
Reply
Leave a comment