Форум Сообщества Аналитиков

×


Нефункциональные требования...(Прочитано 63112 раз)
Нефункциональные требования - как то плохо себе представляю.
Производительность системы, атрибуты качества...хм...

А насколько правильно будет, в параграфе нефункциональных требований к системе
прописывать требования о внесении изменений в структур БД ?



Re: Нефункциональные требования... Ответ #1 : 01 Декабря 2009, 19:40:34
Нефункциональные требования - это все, что невозможно описать в виде сценариев использования.
Так пожалуй будет проще.

А структура БД относится к области проектирования, а не анализа. Если вас интересуют именно требования, то ищите то, которое породило необходимость изменений в структуре БД. Там и выясните, функциональное оно или нет.



Re: Нефункциональные требования... Ответ #2 : 02 Декабря 2009, 13:25:12
А структура БД относится к области проектирования, а не анализа. Если вас интересуют именно требования, то ищите то, которое породило необходимость изменений в структуре БД. Там и выясните, функциональное оно или нет.

Тоесть, пример:
создание справочника
- Функциональные требования:
  - Добавлять записи в справочник;
  - Редактировать записи;
  - Удалять записи;
- Нефункциональные требования;
  - должен хранить:
     1. ФИО;
     2. Должность;
     3. Стаж.
  - ФИО - только символы русского алфавита;
  - Стаж в дня.

Так ли я понял ?



Re: Нефункциональные требования... Ответ #3 : 02 Декабря 2009, 13:42:55
Не, неправильно.
У пользователя же нет задачи "добавить запись".
У него задача "Записать ФИО, должность, стаж в днях".
Они все функциональные.



Re: Нефункциональные требования... Ответ #4 : 02 Декабря 2009, 13:48:34
нет, не правильно.

Это Функциональные требования. Подробнее читаем FAQ
Цитировать
- Функциональные требования (functional requirements) определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда они называются требованиями поведения (behavioral requirements), они содержат положения с традиционным «должен» или «должна»: «Система должна по электронной почте отправлять пользователю подтверждение о заказе».
- Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта
и SWEBOK - перевод: Сергей Орлик и Юрий Булуй
Цитировать
По мнению авторов, в определенной степени, систематизируя работы Вигерса, Лефингвелла и Видрига, Коберна, а также других экспертов, необходимо привести классификацию различных категорий (видов) требований и связанных с ними понятий, важнейших с точки зрения их понимания и дальнейшего практического применения:
...
Группа функциональных требований
...
Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа нефункциональных требований (Non-Functional Requirements)
Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д. На самом деле, достаточно часто можно видеть недостаточное внимание такого рода требованиям со стороны сотрудников ИТ-департаментов и, в частности, технических специалистов, вовлеченных в проект. Business Rules Group дает понимание бизнес-правила, как “положения, которые определяют или ограничивают некоторые аспекты бизнеса. Они подразумевают организацию структуры бизнеса, контролируют или влияют на поведение бизнеса”. Бизнес-правила часто определяют распределение ответственности в системе, отвечая на вопрос “кто будет осуществлять конкретный вариант, сценарий использования” или диктуют появление некоторых функциональных требований.

В контексте дисциплины управления проектами (уже вне проекта разработки программного обеспечения, но выполнения бизнес-проектов и бизнес-процессов) такие правила обладают высокой значимостью и, именно они, часто определяют ограничения бизнес-проектов, для автоматизации которых создается соответствующее программное обеспечение.
Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, …), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.
Я не волшебник, я только учусь...



Re: Нефункциональные требования... Ответ #5 : 02 Декабря 2009, 14:21:19
У пользователя же нет задачи "добавить запись".
У него задача "Записать ФИО, должность, стаж в днях".
Почему вы так решили?...
Следуя описанию, которое привел автор, мы можем выделить как минимум три действия:
1. Добавление записи
2. Редактирование записи
3. Удаление записи

В этих действиях цель пользователя не определена. Т.е. для чего добавляется запись, для чего она редактируется и для чего удаляется - нам неизвестно. Таким образом можно предположить существование более общих сценариев, в которые входят перечисленные действия.

И потом, я лично до сих пор не поняла, что такое "требование о внесении изменений в структуру БД".
Кому требуется вносить измнения? Зачем требуется? Когда требуется? Кто их вносит?



Re: Нефункциональные требования... Ответ #6 : 02 Декабря 2009, 14:45:09
Цитата: ida
И потом, я лично до сих пор не поняла, что такое "требование о внесении изменений в структуру БД".
Кому требуется вносить измнения? Зачем требуется? Когда требуется? Кто их вносит?

Я вас запутал =(
Имел ввиду, что: требования к атрибутам объекта, на основе которого в модели БД появиться таблица, это требования нефункциональные.



Re: Нефункциональные требования... Ответ #7 : 02 Декабря 2009, 14:59:44
Цитировать
- Нефункциональные требования описывают цели и атрибуты качества. Атрибуты качества (quality attributes) представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся:
* легкость и простота использования
* легкость перемещения
* целостность
* эффективность и устойчивость к сбоям
* внешние взаимодействия между системой и внешним миром
* ограничения дизайна и реализации. Ограничения (constraints) касаются выбора возможности разработки внешнего вида и структуры продукта

При чем атрибуты объекта?  В определении четко сказано, что нефункц. треб. описывают цели и атрибуты качества.
Требования к атрибутам объекта на, мой взгляд, как раз функциональное требование.



Re: Нефункциональные требования... Ответ #8 : 02 Декабря 2009, 15:11:11
При чем атрибуты объекта?  В определении четко сказано, что нефункц. треб. описывают цели и атрибуты качества.
Требования к атрибутам объекта на, мой взгляд, как раз функциональное требование.

Видимо я чего то непонимаю...
А могли бы вы привести пример нефункциональных требований ?



Re: Нефункциональные требования... Ответ #9 : 02 Декабря 2009, 15:25:32
Система должна обеспечивать безотказную работу в режиме 24*7
Время формирования ... отчета не должно превышать ... минут
Система должна позволять одновременное выполнение следующих процессов ...
etc



Re: Нефункциональные требования... Ответ #10 : 02 Декабря 2009, 15:28:10
Видимо я чего то непонимаю...
А могли бы вы привести пример нефункциональных требований ?
система должна быть разработанная с использованием языка с++



Re: Нефункциональные требования... Ответ #11 : 02 Декабря 2009, 15:50:43
Вот пример... не факт что Best Practies, но хоть что-то
Я не волшебник, я только учусь...



Re: Нефункциональные требования... Ответ #12 : 03 Декабря 2009, 11:17:02
Спасибо, а то я тут чуть дров не наломал. :)



Re: Нефункциональные требования... Ответ #13 : 07 Декабря 2009, 14:33:16
Как-то это странно...
С чего это вдруг такое требование
Цитировать
Система должна обеспечивать безотказную работу в режиме 24*7
                              обязательно должно быть нефункциональным?
Конечно, если речь идет о банке тушенки, то 24*7 -- нефункциональное требование. В том смысле, что без разницы, когда ее можно открыть и употребить, в среду или в пятницу, в 8 вечера или в 4 утра.

Но та же фраза 24*7 может звучать и иначе, когда речь идет, например, об атомном реакторе или круглосуточно работающей межбанковской или биржевой торговле. Когда система не может остановиться ни на секунду. А ведь требуется проводить разного рода регламентное обслуживание, подметать, продувать, чистить от мусора... А в это время все должно работать. Представьте себе проблему: запроектировать систему так, что ее нельзя остановить даже для ее же собственного обновления. Понимаете, 24*7 может означать, что даже апгрейд делается на работающей системе и как-то обновляются куски кода, задействованные в данный же момент. И все это без останова. И все с гарантией, что не хряпнется. Пользователи ничего не должны заметить. У них просто появятся новые фичи при следующем запросе к системе.

Уровень именно функциональной сложности системы, следующий из требования 24*7, может быть огромным. В системе появится куча модулей, созданных только для выполнения этого требования.

А тогда можно ли требование 24*7 называть нефункциональным?
Анатолий Дегтярёв ака tolldo

Ночь наиболее темна перед самым рассветом



Re: Нефункциональные требования... Ответ #14 : 07 Декабря 2009, 15:28:41
Как-то это странно...
С чего это вдруг такое требование                              обязательно должно быть нефункциональным?
Конечно, если речь идет о банке тушенки, то 24*7 -- нефункциональное требование. В том смысле, что без разницы, когда ее можно открыть и употребить, в среду или в пятницу, в 8 вечера или в 4 утра.

Уровень именно функциональной сложности системы, следующий из требования 24*7, может быть огромным. В системе появится куча модулей, созданных только для выполнения этого требования.

А тогда можно ли требование 24*7 называть нефункциональным?
Можно и нужно, иначе мы дойдем до включения требований безопасности информации в функциональные




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19