Очевидное-невероятное
Aug. 31st, 2010 10:18 pmИнтересно, какого фига требование "В сучае ошибки система восстанавливает своё состояние" заносится в раздел "Нефункциональные"?..
Короче, требования разделяются на функциональные, нефункциональные и "фиг знает как". Я б на английском написал, но у меня для последнего термина только варианты, образованные от известного слова на f.. придумываются.
Видимо, это от чтения примеров описания системы в глубоком немецком пассивном залоге. Хуже сегодня были только рекомендации немецкого министерства науки, где в трёх абзацах нудно объяснялось, что такое "документ".
Короче, требования разделяются на функциональные, нефункциональные и "фиг знает как". Я б на английском написал, но у меня для последнего термина только варианты, образованные от известного слова на f.. придумываются.
Видимо, это от чтения примеров описания системы в глубоком немецком пассивном залоге. Хуже сегодня были только рекомендации немецкого министерства науки, где в трёх абзацах нудно объяснялось, что такое "документ".
no subject
Date: 2010-08-31 08:54 pm (UTC)no subject
Date: 2010-08-31 09:04 pm (UTC)Не, честное слово, я читал перовисточники, откуда они свои серебряные пули напёрли. Мне это не интересно.
Да и клиенты вменяемые, на agile не пойдут.
no subject
Date: 2010-08-31 10:55 pm (UTC)Водопад - это просто модель выделения бюджета. Там всегда присутствуют обратные циклы. Впрочем, как и в любой спирали присутствуют линейные процессы.
no subject
Date: 2010-08-31 11:01 pm (UTC)Первая книжка по психологии программирования была у Вайнберга. Ну и много чего ещё за 20 лет издано.
no subject
Date: 2010-09-01 06:34 pm (UTC)Все требования подразделаются на
- функциональные,
- нефункциональные (иногда называют требованиями качества)
и
- граничные условия (а не "фиг знает как". )
Примеры граничных условий:
- Продукт должен выйти на австрийский рынок 1 апреля 2011 года.
- Система дожна поддерживать работу с MS SQL Server 2005 и более новыми версиями продукта.
Кроме того, существуют и немного другие классификации требований:
Например по CMMI SEI 2006
http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm
или по SPICE ISO/IEC 15504
http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm
no subject
Date: 2010-09-01 06:38 pm (UTC)Имеется ввиду Business Сonstraints или что-то ещё более интересное?
В принципе, делить можно как взбредёт в голову. В зависимости от задачи. К сожалению, взбредает как правило всякая чушь.
no subject
Date: 2010-09-02 05:33 pm (UTC)no subject
Date: 2010-09-02 05:41 pm (UTC)Кстати, знакомые делали сравнение роли требований в разных методологиях управления. Пока что наблюдается большой бардак, разброд и шатания.
no subject
Date: 2010-09-02 10:35 pm (UTC)Для того, чтобы в этом убедиться можно прочитать весь документ (см. страницу по моей ссылке), а можно просто посмотреть в словарь в конце документа. Там даны определения таких терминов как customer requirement, nontechnical requirement, product requirements, technical requirement. Имеенно это я и имел в виду когда писал "существуют и немного другие классификации требований"
no subject
Date: 2010-09-02 10:40 pm (UTC)no subject
Date: 2010-09-02 11:32 pm (UTC)"Короче, требования разделяются на функциональные, нефункциональные и "фиг знает как". Я б на английском написал, но у меня для последнего термина только варианты, образованные от известного слова на f.. придумываются."
А классификацию я дал для того, чтобы ты вспомнил нужный термин.
Человек же меня неправильно понял и я просто написал, что я имел в виду.
Кстати, посмотри внимательно ту классификацию и ты увидешь, что к нефункциональным требованиям относят самые разные группы ( требования е эффективности, надёжности, и пр.) а также требования к стабильности и требования к восстановлению после ошибок. И тогда ты не будешь писать
"Интересно, какого фига требование "В сучае ошибки система восстанавливает своё состояние" заносится в раздел "Нефункциональные"?.."
За сим и раскланиваюсь.
no subject
Date: 2010-09-03 05:19 am (UTC)Я не "пишу спецификацию", я "пишу спецификации" уже много лет и для различных фирм. А в книжках, по большей части, ерунда написана. Особенно в немецких.
В нефункциональной части имеют право стоять только нефункциональные параметры, типа статистики ошибок или наработки на отказ. В виде цифр.
no subject
Date: 2010-09-03 05:53 am (UTC)Совершенно верно - это определения терминов_модели, а не классификация требований! Эти термины используются в практиках модели и даны в Глоссарии именно для того, чтобы пользователи модели понимали - о чем речь в практиках. Т.е., например, определение customer requirements говорит о том, что это такое с точки зрения практик модели, а не что это такое как элемент какой-либо классификации. Есть определенная разница. Не знаю - удалось ли объяснить одним абзацем. :)
no subject
Date: 2010-09-03 05:58 am (UTC)no subject
Date: 2010-09-03 06:15 am (UTC)На мой взгляд самому исполнителю важно для себя иметь какую-то однозначную трактовку (классификацию) и всякий раз мэпить на неё то, что дает заказчик. Заказчика за (редким исключением) не перевоспитаешь и если он использует "гостовские" термины, значит он и будет на них опираться.
no subject
Date: 2010-09-03 06:26 am (UTC)Унификация не нужна, нужна таблица соответствий. А то каждый новый профессор изобретает собственный вариант велосипеда. Таблицы я видел, но их делали студенты для своих внутренних учебно-докторантских нужд.
Ну и ещё, написаны большинство книг по спецификациям таким ужасным языком, которым писать спецификации не рекомендуется. Понятно, что с их интерпретацией полный разброд.
no subject
Date: 2010-09-03 07:52 am (UTC)Пример, дана классификация требований на
- nontechnical requirement,
- technical requirement
Требование попадает в одну из вышеуказанных групп, классов и пр. Таким образом и дана классификация в рамках, деление на группы, классы,
И когда инженер или управленец занимается подготовкой предприятия к сертификации по CMMI ему приходиться пользоваться в том числе и этим делением на группы, этой классификацией. Как только мы начинаем писать документы согласно той или иной методике, эта классификация становиться явной, так как она предусмотврена в большинстве случаев в структуре документа.
Ещё одн пример, когда в математике даются определения, например, рациональных и иррациональных чисел, то выполняется их определённая классификация. Конечно, мы говорим потом о множестве рациональных чисел, а не о классе рац. чисел, однако именно через определения выполнено разделение объектов на два множества, то есть выполнена классификация.
no subject
Date: 2010-09-03 08:01 am (UTC)"И когда инженер или управленец занимается подготовкой предприятия к сертификации по CMMI ему приходиться пользоваться в том числе и этим делением на группы, этой классификацией. Как только мы начинаем писать документы согласно той или иной методике, эта классификация становиться явной, так как она предусмотврена в большинстве случаев в структуре документа."
Тут придерусь немного. CMMI не оговаривает строго - что и как должно выглядеть. И уж тем более это никак не влияет на "сертификацию" (в кавычках, т.к. нет такого процесса - "сертификация"). CMMI дает некое свое концептуальное представление (суть), а пользователям модели уже определять исходя из их реалий - что в их конкретном случае надо относить к тому или иному виду.
no subject
Date: 2010-09-03 04:41 pm (UTC)Ну сам же написал. :-( Не надо путать множества с классами. Тем более, когда множества ортогональны.
no subject
Date: 2010-09-04 08:59 am (UTC)http://www.5min.com/Video/Learn-about-Classification-of-Real-Numbers-286301229
no subject
Date: 2010-09-04 09:31 am (UTC)О чём я уже устал повторять.
no subject
Date: 2010-09-01 06:43 pm (UTC)Да, делить можно по разному, но есть более менее "стандартная" классификация и терминология применимая к тому или иному методу.
ЗЫ!! Я такой умный потому что сейчас к сертификации готовлюсь.
no subject
Date: 2010-09-01 06:44 pm (UTC)no subject
Date: 2010-09-01 06:49 pm (UTC)Граница - она между чем-то и чем-то.
Да, не стоит путать "умный" с "начитанный" ;-)
no subject
Date: 2010-09-01 06:49 pm (UTC)no subject
Date: 2010-09-02 11:25 am (UTC)2. Можно зайти с другой стороны, перечислить все критерии качества, по которым заказчик оценивает систему:
- функциональность,
- быстродействие,
- отказоустойчивость,
- переносимость,
- защищенность,
- масштабируемость.
В такой классификации, то что система восстанавливается после сбоев, относится к отказоустойчивости, т.е. нефункциональным требованиям.
no subject
Date: 2010-09-02 04:53 pm (UTC)В принципе то, что называется Disaster-Recovery Plan вполне себе функциональное описание. В нефункциональной части может стоять, что он должен быть в наличии. Но это немного в сторону от обсуждаемого вопроса.