Comments 56
Что вы думаете о такой точке зрения, в которой нефункциональных требований не бывает? Тем более с таким категоричным разделением. То, что является «нефункциональными» требованиями для одного стейкхолдера, может быть основными для другого.
Я думаю, что мы должны в первую очередь определиться с терминологией.
Нефункциональные требования — это требования, которые определяют не функции, а характеристики системы: ее производительность, надежность, доступность, масштабируемость и ряд других параметров (здесь перечислены характеристики качества, но, как уже сказано в статье, есть и другие виды нефункциональных требований). Требование к времени отклика вашего приложения — это тоже нефункциональное требование («производная» от производительности). Думаю, пользователям вряд ли понравится, если реакции системы они будут ждать 4 минуты после нажатия на кнопку интерфейса. Но в течение 2-3 секунд они могут подождать. Это самый простой пример.
Нефункциональные требования самым непосредственным образом определяют архитектуру разрабатываемого приложения, поэтому определять их очень важно, хотя многие предпочитают этого не делать, полагаясь на то, что hardware и технологии, с которыми они работают, уже обладает какими-то характеристиками качества — следовательно, определенное качество уже можно гарантировать. Отсутствие должного внимания, уделяемого нефункциональным требованиям, часто приводило к серьезным последствиям — от перепроектирования системы до полного провала проекта.
Что касается «основных» и «не основных» требований — приоритеты задаются для всех требований, как функциональных, так и нефункциональных. Категория требований и важность — это просто две разные вещи. Как функциональные, так и нефункциональные требования могут иметь как высокий, так и низкий приоритет.
Нефункциональные требования — это требования, которые определяют не функции, а характеристики системы: ее производительность, надежность, доступность, масштабируемость и ряд других параметров (здесь перечислены характеристики качества, но, как уже сказано в статье, есть и другие виды нефункциональных требований). Требование к времени отклика вашего приложения — это тоже нефункциональное требование («производная» от производительности). Думаю, пользователям вряд ли понравится, если реакции системы они будут ждать 4 минуты после нажатия на кнопку интерфейса. Но в течение 2-3 секунд они могут подождать. Это самый простой пример.
Нефункциональные требования самым непосредственным образом определяют архитектуру разрабатываемого приложения, поэтому определять их очень важно, хотя многие предпочитают этого не делать, полагаясь на то, что hardware и технологии, с которыми они работают, уже обладает какими-то характеристиками качества — следовательно, определенное качество уже можно гарантировать. Отсутствие должного внимания, уделяемого нефункциональным требованиям, часто приводило к серьезным последствиям — от перепроектирования системы до полного провала проекта.
Что касается «основных» и «не основных» требований — приоритеты задаются для всех требований, как функциональных, так и нефункциональных. Категория требований и важность — это просто две разные вещи. Как функциональные, так и нефункциональные требования могут иметь как высокий, так и низкий приоритет.
.
Как так вышло, что бизнес-правила внезапно попали в нефункциональные требования? Они-то как раз определяют функции системы.
Разновидность ограничений. Это не функции системы, а то, что определяет, как конкретно эти функции должны быть реализованы.
Вигерс их относит к нефункциональным требованиям, и он, в общем прав, прав.
Вигерс их относит к нефункциональным требованиям, и он, в общем прав, прав.
«Если оплата по счету не поступила в течение 15 дней, заказ считается отменённым» — это как раз функция системы.
Что же касается Вигерса, то вы, простите, о каком издании говорите? Потому что в моем (второе издание, 2003-ий год в оригинале) бизнес-правила — это раздел 2.5 шаблона требований, «Design and implementation constraints», в то время как Quality Attributes — это раздел 5 того же шаблона. Собственно, во втором издании Вигерс уже не так активно делит требования на функциональные и нефункциональные.
А Макконнел, скажем, в Code Complete относит все и любые бизнес-требования к функциональным, а в нефункциональные попадает производительность, безопасность, поддерживаемость, надежность и тому подобные вещи.
Что же касается Вигерса, то вы, простите, о каком издании говорите? Потому что в моем (второе издание, 2003-ий год в оригинале) бизнес-правила — это раздел 2.5 шаблона требований, «Design and implementation constraints», в то время как Quality Attributes — это раздел 5 того же шаблона. Собственно, во втором издании Вигерс уже не так активно делит требования на функциональные и нефункциональные.
А Макконнел, скажем, в Code Complete относит все и любые бизнес-требования к функциональным, а в нефункциональные попадает производительность, безопасность, поддерживаемость, надежность и тому подобные вещи.
Вигерс Карл, Разработка требований к программному обеспечению, Москва, «Русская Редакция», Подписано в печать 03.12.03
Глава 1 стр. 8
Знаменитый рисунок, проводящий границу между функциональными и нефункциональными требованиями:
Думаю, что на основании этой картинки (там еще текст к ней есть) можно однозначно сказать, к какому виду требований относит Вигерс бизнес-правила.
Да, атрибуты качества — это, собственно, основная часть нефункциональных требований при разработке ПО. Поэтому ей уделяется так много внимания — это я про Макконнела. Про остальные виды нефункциональных требований вообще пишут мало. Про то, как их определять — практически никто.
Ну и Макконел — не аналитик, так сказать, в чистом виде, ему то, что не относится непосредственно к модели качества и метрикам, которые отражаются в коде, видимо, неинтересно.
Глава 1 стр. 8
Знаменитый рисунок, проводящий границу между функциональными и нефункциональными требованиями:
Думаю, что на основании этой картинки (там еще текст к ней есть) можно однозначно сказать, к какому виду требований относит Вигерс бизнес-правила.
Да, атрибуты качества — это, собственно, основная часть нефункциональных требований при разработке ПО. Поэтому ей уделяется так много внимания — это я про Макконнела. Про остальные виды нефункциональных требований вообще пишут мало. Про то, как их определять — практически никто.
Ну и Макконел — не аналитик, так сказать, в чистом виде, ему то, что не относится непосредственно к модели качества и метрикам, которые отражаются в коде, видимо, неинтересно.
Бизнес-правила — сущность (пусть и абстрактная) реального мира. Они существуют безотносительно наличия каких-либо систем. Например, правило, что одна стриптизерша не может работать более 2 часов подряд без перерыва будет существовать вне зависимости от того, автоматизирован ли стрип-клуб. Так что считать их непосредственно требованиями некорректно. Эффективней выделять их в отдельный раздел/документ и мапить на них требования, чтобы было понятно их происхождение.
Да, в общем, многое в требованиях является сущностью реального мира. И бизнес-правила, как один из типов ограничений — тоже. И в зависимости от наличия автоматизации и способа автоматизации некоторые бизнес-правила могут меняться.
Считать их разновидностью ограничений, диктующих нам, как реализовывать ту или иную функцию или группу функций — вполне корректно. Если предположить, что водораздел между функциональными и нефункциональными требованиями проходит по линии «что надо сделать (функциональные) — как надо сделать *нефункциональные)», то получится, что ограничения как раз попадают в нефункциональные требования.
Считать их разновидностью ограничений, диктующих нам, как реализовывать ту или иную функцию или группу функций — вполне корректно. Если предположить, что водораздел между функциональными и нефункциональными требованиями проходит по линии «что надо сделать (функциональные) — как надо сделать *нефункциональные)», то получится, что ограничения как раз попадают в нефункциональные требования.
Если предположить, что водораздел между функциональными и нефункциональными требованиями проходит по линии «что надо сделать (функциональные) — как надо сделать *нефункциональные)», то получится, что ограничения как раз попадают в нефункциональные требования.
Вот только приведенный вами пример бизнес-правила «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру» — это «что» надо сделать, а не «как».
Во втором издании эта картинка тоже есть, только текст под ней уже не так однозначен. Если вы обратите внимание, то заметите, что функциональные требования в картинке встречаются дважды — в качестве категории и в качестве пункта, так что не всегда очевидно, о чем именно пишет Вигерс.
Но на самом деле, я просто считаю, что разделение бизнес-требований на «функциональные» (пользовательские) и «нефункциональные» (правила) — надумано. Одно и то же требование иногда можно выразить и как правило, и как сценарий, но его суть же от этого не меняется? Так что для меня требования делятся на прикладные (т.е., то, что обеспечивает работу системы в соответствии с задачами и процессами заказчика) и качественные (собственно, все остальное).
Вообще, у Вигерса целая глава про бизнес-правила.
Но на самом деле, я просто считаю, что разделение бизнес-требований на «функциональные» (пользовательские) и «нефункциональные» (правила) — надумано. Одно и то же требование иногда можно выразить и как правило, и как сценарий, но его суть же от этого не меняется? Так что для меня требования делятся на прикладные (т.е., то, что обеспечивает работу системы в соответствии с задачами и процессами заказчика) и качественные (собственно, все остальное).
Про то, как их определять — практически никто.
Вообще, у Вигерса целая глава про бизнес-правила.
Да, собственно, как их классифицировать или делить на категории — это не столь уж принципиально.
Важнее — как их определять, и на что они влияют в системе.
Важнее — как их определять, и на что они влияют в системе.
Ну, вы же зачем-то пишете пост именно о нефункциональных требованиях, значит, у них есть что-то общее. Нет?
Есть, они типа те, которые не как другие :) (we who are not as others, говоря корявым языком детей бразильских дипломатов)
Так все требование не такие, как другие. С моей точки зрения, прикладные требования существенно более «не такие».
Какие такие прикладные? Это ваша собственная классификация? Зачем?
Я выше писал.
С моей точки зрения разница между группой «сценарии использования»+«бизнес-правила» и группой «атрибуты качества»+«ограничения» существенно больше, нежели между группами «функциональные требования» и «нефункциональные требования».
Это просто к тому, что «эти требования не такие как другие».
С моей точки зрения разница между группой «сценарии использования»+«бизнес-правила» и группой «атрибуты качества»+«ограничения» существенно больше, нежели между группами «функциональные требования» и «нефункциональные требования».
Это просто к тому, что «эти требования не такие как другие».
Специалисты различают вот такие виды требований:
1. Функциональные
2. Ограничения
3. Интерфейсы
4. Бизнес-правила
5. Атрибуты качества
Вот 2-5 условно для простоты называют «нефункциональные», это такой проф.жаргон.
Классификация 1-5 тоже такая, потому что она по факту удобна в работе, а не потому, что она идеальная в математическом смысле теории множеств.
1. Функциональные
2. Ограничения
3. Интерфейсы
4. Бизнес-правила
5. Атрибуты качества
Вот 2-5 условно для простоты называют «нефункциональные», это такой проф.жаргон.
Классификация 1-5 тоже такая, потому что она по факту удобна в работе, а не потому, что она идеальная в математическом смысле теории множеств.
Вот классификацию 1-5 я очень хорошо понимаю, а вот смысла совместно рассматривать 2-5 вместе — не вижу, потому что общего у них не так много, как кажется. Мы же не называем пп.1+3-5 «неограниченными» или 1-4 — «некачественными»?
Я понимаю, что это профжаргон, но какой в нем реальный смысл?
Я понимаю, что это профжаргон, но какой в нем реальный смысл?
Смысл в том, что про 1 в целом знают и понимают клиенты и айтишники.
А про 2-5 клиенты говорить не умеют, а айтишники не умеют задавать правильные вопросы и понимание важности отдельных категорий этих требований приходит постепенно, с опытом. Причём начинается с каких-нибудь «требований к интерфейсу», «требований к дизайну».
И ещё смысл жаргона в том, что узус формируется независимо от нашего мнения о нём.
А про 2-5 клиенты говорить не умеют, а айтишники не умеют задавать правильные вопросы и понимание важности отдельных категорий этих требований приходит постепенно, с опытом. Причём начинается с каких-нибудь «требований к интерфейсу», «требований к дизайну».
И ещё смысл жаргона в том, что узус формируется независимо от нашего мнения о нём.
В моем опыте как раз люди регулярно не могут отличить 1 от 4. Вот тот же пример из поста: «При отгрузке заказа менеджер должен запросить у бухгалтера товарно-транспортную накладную и счет-фактуру» — почему это бизнес-правило, а не функциональное требование к системе?
Это правда. Но потом получается, что разные люди понимают под жаргонными словами разные вещи.
И ещё смысл жаргона в том, что узус формируется независимо от нашего мнения о нём.
Это правда. Но потом получается, что разные люди понимают под жаргонными словами разные вещи.
Какие люди?
Клиенту и не нужно различать.
Айтишники должны были изучать дисциплину хотя бы software engineering requirements, где этот вопрос разбирается:
swebok.sorlik.ru/1_software_requirements.html
Если не изучали или не помнят, значит у них плохая подготовка.
Клиенту и не нужно различать.
Айтишники должны были изучать дисциплину хотя бы software engineering requirements, где этот вопрос разбирается:
swebok.sorlik.ru/1_software_requirements.html
Если не изучали или не помнят, значит у них плохая подготовка.
Если клиенты не различают, то как может быть так, что про 1 они говорить умеют, а про 4 — нет. Они же не различают? Не складывается.
Я не скрываю, что у меня далеко не идеальная аналитическая подготовка, но мне, тем не менее, интересно: приведенный пример — это бизнес-правило или функциональное требование? И почему?
Я не скрываю, что у меня далеко не идеальная аналитическая подготовка, но мне, тем не менее, интересно: приведенный пример — это бизнес-правило или функциональное требование? И почему?
Они не умеют 4 осознавать и выделять.
По моему мнению, это бизнес-правило, т.к. бизнес-правило — это закономерность выполнения бизнеса, которая существует вне зависимости от того, автоматизирована деятельность или нет.
Как его выделять:
Добивайтесь атомарности требований.
Разбиваете предложение на фрагменты:
1) «отгрузка товара» (функция)
2) «запрос накладной» (функция)
3) 2 должно происходить в процессе 1.
Вот 3, как видно из его формы, это правило, а не функция.
По моему мнению, это бизнес-правило, т.к. бизнес-правило — это закономерность выполнения бизнеса, которая существует вне зависимости от того, автоматизирована деятельность или нет.
Как его выделять:
Добивайтесь атомарности требований.
Разбиваете предложение на фрагменты:
1) «отгрузка товара» (функция)
2) «запрос накладной» (функция)
3) 2 должно происходить в процессе 1.
Вот 3, как видно из его формы, это правило, а не функция.
Ммм.
Отгрузка товара — это некий сценарий. Например: «получить список товара под отгрузку — найти местоположение на складе — свезтии к машине — загрузить — отправить машину» (happy path). Почему шаг «запросить накладную», который мы теперь добавляем между первым и вторым шагом, как-то отличается?
Иными словами, почему это правило не может просто быть выражено как еще один пункт сценария?
Отгрузка товара — это некий сценарий. Например: «получить список товара под отгрузку — найти местоположение на складе — свезтии к машине — загрузить — отправить машину» (happy path). Почему шаг «запросить накладную», который мы теперь добавляем между первым и вторым шагом, как-то отличается?
Иными словами, почему это правило не может просто быть выражено как еще один пункт сценария?
Откуда вдруг из-за угла выехали сценарии? Классические требования атомарны и не имеют связей предшествования/следования.
Да, можно выразить бизнес-правило в сценарии или диаграмме бизнес-процессов. Но для задач планирования и контроля разработки полезно иметь бизнес-правило записанным в явном виде в реестре.
Да, можно выразить бизнес-правило в сценарии или диаграмме бизнес-процессов. Но для задач планирования и контроля разработки полезно иметь бизнес-правило записанным в явном виде в реестре.
Если следовать намекам, которые дает нам русский язык, то нефункциональные требования — это те, которые определяют ВСЕ ЧТО УГОДНО, КРОМЕ функциональности.
Допустим, приведенное высказывание — это «бизнес-правило». Однако, система, проверяющая наличие запроса накладной в процессе отгрузки товара — это система, ФУНКЦИОНАЛЬНО отличная от системы, НЕ проверяющей и не требующей выполнения данного правила.
Тогда какое же это «нефункциональное требование»? Спасибо за пояснения…
Допустим, приведенное высказывание — это «бизнес-правило». Однако, система, проверяющая наличие запроса накладной в процессе отгрузки товара — это система, ФУНКЦИОНАЛЬНО отличная от системы, НЕ проверяющей и не требующей выполнения данного правила.
Тогда какое же это «нефункциональное требование»? Спасибо за пояснения…
Функция — это то, что преобразует вход в выход.
Ограничения на применение функций — это не преобразования входа в выхода.
Если в машине руль у водителя на потолке, то по набору функций машина та же самая.
Если одна функция должна запускаться вместе с другой — это не порождение 3-й функции.
Ограничения на применение функций — это не преобразования входа в выхода.
Если в машине руль у водителя на потолке, то по набору функций машина та же самая.
Если одна функция должна запускаться вместе с другой — это не порождение 3-й функции.
Я рассматриваю данное (обсуждаемое) бизнес-правило как ограничение, которое надо проверять в коде (проверка — это та же функциональность). А Вы, похоже, как констатацию (типа «в этой системе по другому не бывает»).
Если это просто констатация, то согласен, это НФТ (хотя и полезность его в этом случае вызывает вопросы)
Если это просто констатация, то согласен, это НФТ (хотя и полезность его в этом случае вызывает вопросы)
Вместо неработающей ссылки на пиратский файл отвратительно переведённого 2-го издания Вигерса можно поставить ссылку на свежее 3-е издание за 200 рублей в электронном виде на русском языке: www.litres.ru/dzhoy-bitti/karl-vigers/razrabotka-trebovaniy-k-programmnomu-obsespecheniu/
Третье издание тоже отличилось качеством перевода.
Начиная от кучи опечаток, в том числе на первой же странице, где перечислены посвящения:
заканчивая такими оборотами:
и т.д.
Начиная от кучи опечаток, в том числе на первой же странице, где перечислены посвящения:
Посвящается Крис.
– Крис Вигерс
заканчивая такими оборотами:
… за счет предъявления повелителям сайта ввести изображенные на картинке символы
и т.д.
мда, с посвящением трешак.
ну по крайней мере ключевые термины типа product vision переведены правильно
ну по крайней мере ключевые термины типа product vision переведены правильно
Я, конечно понимаю, что для «классических требований» термин «backlog» не ключевой, но бездумная копипаста «резерва проекта» с Википедии дискредитирует это издание гораздо сильнее, чем опечатка в посвящении и всякие «повелители сайта» по тексту.
Если бы переводчик потрудился заглянуть в те же «Пользовательские истории», то нашёл бы там «Журнал запросов на выполнение работ» – не первоклассный перевод, конечно, но хотя бы отражающий общую суть. Примечательно, что «Вильямс» открыто указывает переводчика А. Г. Гузикевича, тогда как у «Русской редакций» ничего подобного я не нашёл.
Такие известные книги, на мой взгляд, лучше всего переводить силами сообщества, потому как каждая ошибка перевода в терминологии и важных описаниях порождает массу когнитивных искажений со всеми вытекающими для отрасли последствиями.
Если бы переводчик потрудился заглянуть в те же «Пользовательские истории», то нашёл бы там «Журнал запросов на выполнение работ» – не первоклассный перевод, конечно, но хотя бы отражающий общую суть. Примечательно, что «Вильямс» открыто указывает переводчика А. Г. Гузикевича, тогда как у «Русской редакций» ничего подобного я не нашёл.
Такие известные книги, на мой взгляд, лучше всего переводить силами сообщества, потому как каждая ошибка перевода в терминологии и важных описаниях порождает массу когнитивных искажений со всеми вытекающими для отрасли последствиями.
Журнал запросов на выполнение работ — на мой взгляд, не самый удачный перевод. Лучше, мне кажется, журнал запросов на изменение.
У «Русской редакции когда-то была мода ставить в информацию об издании фамилию редактора. По крайней мере, свою я там видела, когда редактировала книги по SQL Server (администрирование и разработка). Иногда ставили фамилии переводчиков (по крайней мере я на этом настаивала, когда работала вместе с людьми, которые начинали свой путь в программировании с разработки движков для баз данных).
Теперь эта мода у „Русской редакции“ прошла — они переводят книги силами компании Логрус, занимающейся локализацией разных программных продуктов, в том числе и Microsoft. Работу переводчиков в Логрусе часто выполняют студенты. Что касается редактуры — похоже, что от нее и вовсе отказались.
У «Русской редакции когда-то была мода ставить в информацию об издании фамилию редактора. По крайней мере, свою я там видела, когда редактировала книги по SQL Server (администрирование и разработка). Иногда ставили фамилии переводчиков (по крайней мере я на этом настаивала, когда работала вместе с людьми, которые начинали свой путь в программировании с разработки движков для баз данных).
Теперь эта мода у „Русской редакции“ прошла — они переводят книги силами компании Логрус, занимающейся локализацией разных программных продуктов, в том числе и Microsoft. Работу переводчиков в Логрусе часто выполняют студенты. Что касается редактуры — похоже, что от нее и вовсе отказались.
Это не самый удачный перевод в первую очередь из-за того, что бэклог некорректно называть журналом. Термин «журнал» в техническом и околотехническом мире обладает устойчивой психологической инерцией — «документ с записями о событиях в хронологическом порядке». Бэклог же представляет собой приоритезированный список элементов не привязанный к какой-либо хронологии.
На мой взгляд, самый простой вариант термина это «список [название элементов]»: «список нереализованных компонентов продукта», «список компонентов для реализации в спринте». Или сокращённо: «список компонентов продукта», «список компонентов спринта». Если команда использует истории, то соответственно: «список историй продукта», «список историй спринта».
Что касается политики издательства в отношении переводов и редактуры, это ещё один веский довод взяться за такую работу силами сообщества. К примеру, у Agile Ukraine есть замечательная инициатива Agile Translations. Думаю, в сообществе русскоязычных аналитиков не меньше людей, у которых достаточно компетенции и желания заниматься такой полезной и интересной деятельностью. Осталось их организовать +)
На мой взгляд, самый простой вариант термина это «список [название элементов]»: «список нереализованных компонентов продукта», «список компонентов для реализации в спринте». Или сокращённо: «список компонентов продукта», «список компонентов спринта». Если команда использует истории, то соответственно: «список историй продукта», «список историй спринта».
Что касается политики издательства в отношении переводов и редактуры, это ещё один веский довод взяться за такую работу силами сообщества. К примеру, у Agile Ukraine есть замечательная инициатива Agile Translations. Думаю, в сообществе русскоязычных аналитиков не меньше людей, у которых достаточно компетенции и желания заниматься такой полезной и интересной деятельностью. Осталось их организовать +)
А что известно про юридические аспекты таких переводов?
Специально уточнил этот вопрос у организаторов сообщества. Переводы на сто процентов легитимны, поскольку делались с личного согласия авторов на безвозмездной основе. «Те, кто просят деньги, сразу пишут об этом на своих сайтах». Авторами переведённых книг являются граждане Швеции, ведущие активисты гибкой разработки Хенрик Книберг и Маттиас Скарин.
Даже если с переводами Вигерса могут возникнуть какие-то юридические проволочки, всегда остаётся возможность выслать издательству список найденных ошибок и параллельно постараться его максимально распространить в Сети. Пусть их учтут в следующем издании, а те, кто приобретёт нынешнее, будет проинформирован.
Даже если с переводами Вигерса могут возникнуть какие-то юридические проволочки, всегда остаётся возможность выслать издательству список найденных ошибок и параллельно постараться его максимально распространить в Сети. Пусть их учтут в следующем издании, а те, кто приобретёт нынешнее, будет проинформирован.
Вадим, учитывая, что между выпуском 2-го и 3-го изданий на русском языке прошло 10 лет, то информировать издательство об ошибках, которые можно учесть в следующем издании — на мой взгляд слишком благородная затея :) Если понадобится доптираж, оно вряд ли будет заморачиваться правками, а 4-е издание пока не светит, да и дяденька уже старенький.
В том то и дело, что, ввиду перечисленных обстоятельств, есть немалая вероятность того, что в ближайшие годы нынешнее третье издание будет оставаться одной из самых авторитетных и рекомендуемых книг по бизнес-анализу. А это чревато распространением всяких «резервов проекта» в довольно широких масштабах, чего лично мне очень не хотелось бы.
Поэтому если даже издательство посчитает невыгодным внесение правок в доптираж, то можно хотя бы попросить добавить ссылку на документ с известными ошибками в ту же аннотацию. То же самое можно попросить сделать онлайн магазины – добавить ссылку в описание товара. Ну, и продвинуть эту же ссылку через всевозможные тематические ресурсы. Думаю, комплекс подобных мер может дать некоторый ощутимый эффект.
Я бы с большим удовольствием и не меньшим пристрастием вычитал двадцатую главу +) Только уже осенью.
Поэтому если даже издательство посчитает невыгодным внесение правок в доптираж, то можно хотя бы попросить добавить ссылку на документ с известными ошибками в ту же аннотацию. То же самое можно попросить сделать онлайн магазины – добавить ссылку в описание товара. Ну, и продвинуть эту же ссылку через всевозможные тематические ресурсы. Думаю, комплекс подобных мер может дать некоторый ощутимый эффект.
Я бы с большим удовольствием и не меньшим пристрастием вычитал двадцатую главу +) Только уже осенью.
Как понять, какие из 50-100 возможных видов НФТ из общего предъявлять в конкретном проекте?
По требованиям есть более современные стандарты:
1. ISO IEC IEEE 29148-2011 Systems and software engineering — Life cycle processes — Requirements engineering
В нём есть рекомендуемые структуры документов и описания видов НФТ-требований (Раздел 9.5., например).
2.
ISO_IEC 25030.2007 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements
и
ISO_IEC 25010 2011 Quality Requirements Models — они посвящены атрибутам качества, как видно из названия
(Это развитие ISO 9126)
3. ГОСТ Р ИСО 9241-210-2012 Человеко-ориентированное проектирование
В нём наиболее качественно раскрыты атрибуты класса «Quality in Use», качество в использовании.
Рекомендую ознакомиться.
1. ISO IEC IEEE 29148-2011 Systems and software engineering — Life cycle processes — Requirements engineering
В нём есть рекомендуемые структуры документов и описания видов НФТ-требований (Раздел 9.5., например).
2.
ISO_IEC 25030.2007 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements
и
ISO_IEC 25010 2011 Quality Requirements Models — они посвящены атрибутам качества, как видно из названия
(Это развитие ISO 9126)
3. ГОСТ Р ИСО 9241-210-2012 Человеко-ориентированное проектирование
В нём наиболее качественно раскрыты атрибуты класса «Quality in Use», качество в использовании.
Рекомендую ознакомиться.
Путать стандарты качества ПО и модели качества (о которых я говорю, определяя атрибуты качества) и "стандарты по требованиям" - это распространенная ошибка.
Рекомендую больше так не делать.
Это всё связанные вещи, странно этого не понимать.
Странно не понимать того, что связанные вещи не заменяют одна другую и не тождественны одна другой. Странно не понимать русского языка в комментарии (вроде бы родной, но создается впечатление, что я по-японски пишу - не доходит; очевидно, нужно разъяснить).
Ну, надеюсь, сейчас дойдет: стандарты качества ПО - это общие подходы к построению системы качества, которая начинается с определения целей, с которым мы оное качество обеспечиваем и поддерживаем. От целей мы идем к набору атрибутов качества и метрик, и вот тогда уже у нас появляются нефункциональные требования.
Стандарты, в общем, разные, у них разные области применения, и один другой ни в какой степени не заменяет.
как человек, который 8 лет не мог ответить на комментарий, ты не в той позиции, чтобы читать мне нотации
чтобы перестать брызгать слюной, шипеть "некомпетентносссссть" и проч, рекомендую пройти курс психотерапии
в 21-м веке уже немодно быть воинственным социопатом и психопатом
"Мог" и "хотел" - это разные вещи, путать их не надо, особенно людям, советующим "пройти курс психотерапии".
"Считал нужным" - тоже вещь, отличная от "мог".
Не думаю, что лично хоть как-то заинтересована в продолжении этого скучнейшего диалога с человеком, не делающим различий между понятиями, различия между которыми очевидны.
Ну а о позиции - подумай, нужно ли мне как-то коммуницировать с тобой, и в чем моя здесь выгода? Здесь только ты лезешь в тредик с Особо Ценным Мнением, кто в какой позиции - очевидно, чтобы показать, что разницы между понятиями, которые смешивать никак не нужно, в твоей голове не существует.
Ну, ОК, твой внутренний мир и установки в твоей голове - твоя проблема, я решать ее не собираюсь. Живи дальше с ними, желаю удачи и всяческих успехов.
«В этой статье я расскажу о следующем: … откуда берутся численные значения для нефункциональных требований.»
Я не нашёл в этой статье. Покажите, в каком абзаце?
Во второй части будет.
А когда она будет?
Хороший вопрос.
Я думаю, что нынешним летом (но уже ближе к августу) я ее напишу.
Я думаю, что нынешним летом (но уже ближе к августу) я ее напишу.
Теперь уже прошло 2 года.
Может всё-таки поправить текст статьи и убрать ложное обещание?
Может всё-таки поправить текст статьи и убрать ложное обещание?
Есть новости?
в общем мы сами написали https://habr.com/ru/post/661331/
Sign up to leave a comment.
Нефункциональные требования к программному обеспечению. Часть 1