Общие требования к разработке программы

Стандарт был принят прошедшим летом, но вступит в силу только через год – с 1 июля 2017 года. Разработчиком стандарта является ЗАО «НПО «ЭШЕЛОН». Целевой аудиторией стандарта являются разработчики ПО, а также организации, выполняющие оценку соответствия.

В стандарте можно выделить следующие ключевые моменты:

• Стандарт устанавливает общие требования к содержанию и порядку выполнения работ, связанных с созданием безопасного ПО. Детали соответствующих процессов в стандартом не регламентируются.
• Меры по разработке безопасного ПО применяются в течение всего жизненного цикла ПО. Есть связь с процессами, описанными в ИСО/МЭК 12207-2010.
• Стандартом вводится базовый набор мер по разработке безопасного ПО. При невозможности реализации в среде разработки ПО отдельных мер из базового набора, разработчик имеет право реализовать компенсирующие меры.
• В стандарте предусмотрено целых 6 видов испытаний ПО: статический анализ и экспертиза кода, функциональное тестирование программы, тестирование на проникновение, динамический анализ кода и фаззинг-тестирование.
• Учитывается необходимость защиты инфраструктуры среды разработки ПО.
• Учитывается необходимость обеспечения конфиденциальности информации, получаемой в ходе анализа кода и тестирования ПО

Всего в стандарте описано 23 меры. По каждой мере четко описаны цели, результат реализации, а также требования к реализации меры (т.е. что именно нужно сделать). Радует, что все меры описаны достаточно однозначно.

Введение в разработку мобильных приложений

«Базовый набор мер» по ГОСТ Р 56939-2016 выглядит следующим образом:

1. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении анализа требований к программному обеспечению:

1.1. При выполнении анализа требований к ПО разработчик ПО должен определить требования по безопасности, предъявляемые к разрабатываемому ПО.

2. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении проектирования архитектуры программы:

2.1. Моделирование угроз безопасности информации.

2.2. Уточнение проекта архитектуры программы с учетом результатов моделирования угроз безопасности информации.

3. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении конструирования и комплексирования программного обеспечения:

3.1. Использование при разработке ПО идентифицированных инструментальных средств.
3.2. Создание программы на основе уточненного проекта архитектуры программы.

3.3. Создание (выбор) и использование при создании программы порядка оформления исходного кода программы.

3.4. Статический анализ исходного кода программы.
3.5. Экспертиза исходного кода программы.

4. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении квалификационного тестирования программного обеспечения:

4.1. Функциональное тестирование программы.
4.2. Тестирование на проникновение.
4.3. Динамический анализ кода программы.
4.4.

Разработка требований, их ЖЦ и качество. Основы разработки требований в ИТ-проектах. Денис Бесков

Фаззинг-тестирование программы.

5. Меры по разработке безопасного программного обеспечения, реализуемые при выполнении инсталляции программы и поддержки приемки программного обеспечения:

5.1. Обеспечение защиты ПО от угроз безопасности информации, связанных с нарушением целостности в процессе его передачи пользователю.

5.2. Поставка пользователю эксплуатационных документов.

6. Меры по разработке безопасного программного обеспечения, реализуемые при решении проблем в программном обеспечении в процессе эксплуатации:

6.1. Реализация и использование процедуры отслеживания и исправления обнаруженных ошибок ПО и уязвимостей программы.

6.2. С истематический поиск уязвимости программы.

7. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента документацией и конфигурацией программы:

7.1. Реализация и использование процедуры уникальной маркировки каждой версии ПО.
7.2. Использование системы управления конфигурацией ПО.

8. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента инфраструктурой среды разработки программного обеспечения:

8.1. Защита от несанкционированного доступа к элементам конфигурации.
8.2. Резервное копирование элементов конфигурации.
8.3.

Регистрация событий, связанных с фактами изменения элементов конфигурации.

9. Меры по разработке безопасного программного обеспечения, реализуемые в процессе менеджмента людскими ресурсами

9.1. П ериодическое обучение сотрудников.
9.2. Периодический анализ программы обучения сотрудников.

• Политика информационной безопасности в соответствии с ИСО/МЭК 27001.
• Руководство по разработке безопасного ПО.
• Перечень требований по безопасности (могут быть включены в ТЗ).
• Модель угроз безопасности.
• Проект архитектуры программы (логическая структура программы).
• Перечень инструментальных средств разработки ПО.
• Описание проектных решений, обеспечивающих выполнение требований по безопасности;
• Порядок оформления исходного кода программы.
• Регламент и протоколы статического тестирования программы.
• Регламент и протоколы экспертизы исходного кода программы.
• Регламент и протоколы функционального тестирования программы.
• Регламент и протоколы тестирования на проникновение.
• Регламент и протоколы динамического анализа кода программы.
• Регламент и протоколы фаззинг-тестирования программы.
• Эксплуатационная документация.
• Регламент передачи ПО пользователю.
• Регламент отслеживания и исправления обнаруженных ошибок ПО и уязвимостей программы.
• Регламент приема и обработки сообщений от пользователей об ошибках ПО и уязвимостях программы.
• Регламент доведения до пользователей информации об уязвимости программы и рекомендаций по их устранению.
• Журнал ошибок и уязвимостей программы.
• Регламент экстренного выпуска обновлений ПО.
• Регламент, протоколы и журналы поиска уязвимостей программы.
• Регламент доведения до пользователей сведений об уязвимостях программы.
• Регламент маркировки версий ПО.
• Регламент управления конфигурацией ПО.
• Регламент защиты инфраструктуры среды разработки ПО.
• Регламент резервного копирования конфигурации ПО.
• Регламент регистрации событий изменений конфигурации ПО.
• Журнал регистрации изменений конфигурации ПО.
• Программа обучения сотрудников в области разработки безопасного ПО.
• Журнал обучения сотрудников в области разработки безопасного ПО.

• продуманный набор мер, хорошее объяснение по сути каждой меры;
• разрешается использовать компенсирующие меры;
• предусмотрен широкий перечень проверок кода и тестирования ПО;
• связь с ГОСТ Р ИСО/МЭК 15408, ИСО/МЭК 12207-2010.

Интересуетесь, как ХАКЕРЫ обходят системы защиты? Подпишитесь на наш ТГ канал и хакеры будут обходить вас стороной.

Источник: www.securitylab.ru

Основные требования к разработке программы

В любом серьезном и самостоятельном исследовании все начинается с программы. Это стратегический план проведения исследования. Тщательно разработанная программа — гарантия успеха всего исследования.

В идеальном варианте программа теоретико-прикладного исследования включает следующие элементы:

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

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

Методологическая часть программы начинается с целеориентации исследования (а). В основе исследования лежит проблема. Она может проявляться в социальной дезорганизации, противоречии, конфликте интересов социальных групп, общностей, институтов.

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

Социальные проблемы отличаются по своей масштабам. Одни не выходят за рамки коллектива, организации, другие затрагивают интересы целых регионов, наций, этнических групп. Наконец, на высшем уровне социальная проблема может охватывать интересы всего общества в целом и даже носить глобальный характер. Например, проблема устойчивого развития, демографической революции, больших экологических сдвигов.
Следует различать практическую и научную проблему. Отличие заключается в том, что практическая проблема не требует новых знаний, а пути ее разрешения известны. Ставя перед собой проблему, надо соизмерять свои возможности. Кроме того, необходимо избегать в программе мнимых проблем. Например, текучесть кадров. Она достаточно хорошо изучена и описана в литературе.

Другое дело, что в каждом коллективе есть своя специфика. Уловить ее можно с помощью небольшого разведывательного исследования.
Формулировка проблемы влечет за собой выбор конкретного объекта исследования. Объект исследования — область социальной действительности (социальный процесс, сфера жизни, общность), содержащая проблему. Иными словами — все то, что явно или неявно содержит социальное противоречие и порождает проблемную ситуацию социального характера. Объект социологического исследования — это то, на что направлен процесс социологического анализа.

Помимо объекта выделяется также предмет исследования – наиболее значимые стороны объекта, подлежащие изучению. Как правилопредмет фиксируется в исходном теоретическом понятии и включается в формулировку темы исследования. Вспомним пирамиду В. Н. Шубкина, который изучал проблемы выбора профессии выпускниками школ. Проблемная ситуация заключается в противоречии между равными правами всех школьников в выборе профессии и сохраняющимся неравенством молодых людей из разных социальных групп и регионов в реализации этих прав. Объект исследования — школьники и их родители; предмет исследования — профессиональные планы школьников и конкретная реализация их на практике.

В программе обозначаются цель, задачи исследования. Они вытекают из сформулированной проблемной ситуации. Чаще всего цели и задачи исследования формулируются заказчиком. Конечно, цели могут быть основными и частными. Частные задачи вытекают из основных и являются средствами решения главных задач исследования.
Очень важно различать программные, основные, задачи исследования и те, что будут возникать в процессе его развертывания. По сути, каждая стадия развертывания программы и анализа полученных данных предваряется постановкой конкретных задач.

Основные задачи исследования отвечают его целевой установке, дополнительные ставятся для подготовки будущих исследований, проверки побочных гипотез и т. п.

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

При разработке программы социологического исследования важно выделить ключевые понятия, выражающие узловые моменты, точки изучаемой проблемы., т.е провести б) определение и интерпретацию теоретических понятий, а именно:

· соотнесение понятия с теоретической системой (выбор теории, описывающей явление)

· достижение однозначности в понимании (составление тезауруса)

· достижение точности понятия (спецификация понятий и определение новых).

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

в) эмпирическая интерпретация понятий включает переход от теоретических конструктов к эмпирически фиксируемым процессам. В ходе исследования происходит конкретизация теоретических понятий в различных аспектах проявления описываемого процесса по схеме ПОНЯТИЕ — ПОКАЗАТЕЛЬ — ИНДИКАТОР — (ИСТОЧНИК ИНФОРМАЦИИ — ИНСТРУМЕНТ). Например, какими показателями можно измерить процесс адаптации, отношение к учебе, труду, качество жизни и т. п.

Следующая важнейшая часть работы над программой – г) выдвижение рабочих гипотез исследования. Гипотеза — главный методологический инструмент, организующий весь процесс исследования. Гипотезы — это достаточно обоснованные предположения о структуре изучаемых объектов, характере их социальных связей, возможных подходах к решению социальных проблем.

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

Гипотезы делят на первичны е и вторичные. Вторичные гипотезы выдвигаются взамен первичных, если те опровергаются эмпирическими данными, полученными в ходе исследования. Иногда первичные гипотезы называют «рабочими» в том смысле, что они используются как строительные леса для возведения более обоснованных гипотез. Хорошее исследование обычно опирается на целую серию альтернативных гипотез, и проверка позволяет получить более высокие основания для принятия тех предположений, которые остаются после отбрасывания альтернатив.
Гипотезы бывают описательные и объяснительные. Описательные — это предположение о свойствах изучаемого объекта, о характере связей между его отдельными элементами. Объяснительные гипотезы содержат предположения о степени тесноты, плотности связей и зависимостей в изучаемых процессах и явлениях. Это наиболее сильные гипотезы, требующие экспериментальной проверки.

Есть некоторые общие правила, которым должна удовлетворять гипотеза:

§ Гипотеза не должна содержать понятий, которые не получили эмпирической интерпретации, иначе она непроверяема.

§ Гипотеза не должна противоречить ранее установленным научным фактам. К примеру, есть достаточно оснований выдвинуть такую гипотезу: «Чем разнообразней труд, тем больше удовлетворенность работника». Однако при определенном психофизиологическом типе личности именно однообразная и монотонная работа доставляет удовлетворение, а разнообразная — нет.

§ Гипотеза должна быть простой и не обрастать лесом возможных допущений и ограничений.

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

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

2) процедурно-методический раздел программы включает выбор методов получения информации, проектирование инструментов и выборки.

Методы получения информации:

· опрос ( анкетирование, интервью, экспертный опрос, социометрический опрос, социологическое тестирование)

· наблюдение ( стандартизированное и свободное, включенное и не включенное, открытое или инкогнито, лабораторное или полевое)

· анализ документов ( традиционный, формализованный, контент-анализ)

· эксперимент ( лабораторный или полевой, линейный или параллельный, констатирующий или формирующий)

· выборочный метод -метод получения информации, основанный на изучении небольшой части потенциальной совокупности объектов (генеральной совокупности), выводы которого затем распространяются на всю совокупность объектов.

Источник: studopedia.su

Особенности разработки требований к ПО. (Лекция 1)

Ошибки, допущенные на стадии сбора требований, составляют от 40 до 60% всех
дефектов проекта. Две наиболее распространенные проблемы,— определение и
управление требованиями заказчика. Масса проблем с ПО возникает из-за
несовершенства
способов,
которые
люди
применяют
для
сбора,
документирования, согласования и модификации требований к ПО.
Нигде более, как на стадии сбора требований, так тесно не связаны интересы всех
заинтересованных в проекте лиц с успехом проекта. К заинтересованным в проекте
лицам относятся:
заказчики, которые финансируют проект или приобретают продукт для
решениякаких-то бизнес-задач;
пользователи, которые взаимодействуют напрямую или не напрямую с
приложением (подкласс заказчиков);
аналитики требований, которые пишут требования и передают их разработчикам;
разработчики, которые создают, разворачивают и поддерживают продукт;
тестеры, которые определяют соответствие поведения ПО желаемому;
технические писатели, которые отвечают за создание руководствапользователей,
тренировочные материалы и справочную систему;
менеджер по проекту, который планирует процесс и руководит командой
разработчиков вплоть до успешного выпуска продукта;
сотрудники правового отдела,которые следят,чтобы продукт непротиворечил
всем действующим законам и постановлениям;
производственники, которые должны построить продукт, содержащий данное ПО;
сотрудники отдела продаж и маркетинга, выезднойслужбыподдержки и другие,
кому придется работать с продуктом и его пользователями.

3.

Образ и границы проекта никогда не определены ясно.
Заказчики очень заняты, чтобы работать с аналитиками и программистами над
требованиями.
Заместители пользователей — менеджеры по продуктам, по разработке,
менеджеры пользователей или маркетологи — вызываются говорить от имени
клиентов, но не точно представляют их потребности.
Требования существуют только в головах «экспертов», работающих в вашей
организации, и никогда не фиксируются в письменном виде.
Заказчики настаивают, чтобы все требования были критическими, без учета их
приоритетов.
Разработчики получают двусмысленную и неполную информацию, поэтому при
кодировании им приходится делать предположения.
Взаимодействие между разработчиками и заказчиками ограничивается
внешним видом пользовательского интерфейса и не затрагивает того, что же
действительно клиенты собираются делать с помощью приложения.
Ваши заказчики подписывают требования и затем постоянно изменяют их.
Проект разрастается, когда вы принимаете изменения требований, график при
этом нарушается, потому что никаких дополнительных ресурсов не выделяется
и никакие функции не удаляются.
Запросы на изменение требований теряются по пути: ни вы, ни ваши клиенты
не знают статус каждого запроса.
Заказчики настаивают на определенной функциональности, которую
разработчики и создают, однако эти возможности системы клиентам не нужны.
Технические требования хороши, а вот заказчики нет.

4. Оговоренные требования к ПО

• Одна из проблем, существующих в индустрии ПО, — это
отсутствие общепринятых определений терминов, которыми мы
пользуемся для описания нашей работы. Разные эксперты, говоря
об одном и том же документе, называют его и требования
пользователя, и требования к ПО, и функциональные
требования, и системные требования, и технологические
требования, и бизнес-требования, и требования к продукту.
Заказчики зачастую считают, что требования — это развитая
концепция продукта, предназначенная для разработчиков. Те, в
свою очередь, полагают, что в отношении клиентов это детальная
разработка интерфейса пользователя. Такое многообразие ведет
к сумятице и раздражающим проблемам во взаимодействии
сторон.
• Основной закон: требования должны быть документированы.

5. Особенности интерпретации требований

IEEE Standard Glossary of Software Engineering
Terminology (1990) определяет требования как:
1. Условия
или
возможности,
необходимые
пользователю для решения проблем или
достижения целей;
2. Условия или возможности, которыми должна
обладать система или системные компоненты,
чтобы выполнить контракт или удовлетворять
стандартам,
спецификациям
или
другим
формальным документам;
3. Документированное представление условий или
возможностей для пунктов 1 и 2.

6. Уровни требований

Требования к ПО состоят из трех уровней — бизнестребования, требования пользователей и
функциональные требования. Вдобавок каждая
система
имеет
свои
нефункциональные
требования. Модель на рис. 1 иллюстрирует
способ представления этих типов требований. Как
и все модели, она не полная, но схематично
показывает организацию требований. Овалы
обозначают типы информации для требований, а
прямоугольники — способ хранения информации
(документы, диаграммы, базы данных).

7. Взаимосвязи нескольких типов информации для требований

8.

Бизнес-требования (business requirements) содержат
высокоуровневые цели организации или заказчиков
системы. Как правило, их высказывают те, кто
финансируют проект, покупатели системы, менеджер
реальных пользователей, отдел маркетинга или
«провидец» продукта. В этом документе объясняется,
почему организации нужна такая система, то есть описаны
цели, которые организация намерена достичь с ее
помощью. Иногда записывают бизнес-требования в
форме документа об образе и границах проекта,
который еще иногда называют уставом проекта (project
charter) или документом рыночных требований (market
requirements document). Определение границ проекта
представляет собой первый этап управление общими
проблемами расползания границ.

9.

Требования пользователей (user requirements) описывают цели
и задачи, которые пользователям позволит решить система. К
отличным способам представления этого вида требований
относятся варианты использования, сценарии и таблицы
«событие — отклик». Таким образом, в этом документе
указано, что клиенты смогут делать с помощью системы.
Пример—«Сделать заказ» для заказа билетов на самолет,
аренды автомобиля, заказа гостиницы через Интернет.
Функциональные
требования
(functional
requirements)
определяют функциональность ПО, которую разработчики
должны построить, чтобы пользователи смогли выполнить
свои задачи в рамках бизнес-требований. Иногда именуемые
требованиями поведения (behavioral requirements), они
содержат положения с традиционным «должен» или
«должна»: «Система должна по электронной почте отправлять
пользователю подтверждение о заказе».

10.

Термином
системные
требования
(system
requirements)
обозначают высокоуровневые требования к продукту, которые
содержат многие подсистемы, то есть система. Говоря о системе,
мы подразумеваем программное обеспечение или подсистемы
ПО и оборудования. Люди — часть системы, поэтому
определенные функции системы могут распространиться и на
людей.
Бизнес-правила (business rules) включают корпоративные политики,
правительственные постановления, промышленные стандарты и
вычислительные алгоритмы. Бизнес-правила не являются
требованиями к ПО, потому что они находятся вне границ любой
системы ПО. Однако они часто налагают ограничения, определяя,
кто может выполнять конкретные варианты использования, или
диктовать, какими функциями должна обладать система,
(подчиняющаяся соответствующим правилам. Иногда бизнесправила становятся источником атрибутов качества, которые
реализуются в функциональности. Следовательно, вы можете
отследить
происхождение
конкретных
функциональных
требований вплоть до соответствующих им бизнес-правил.

11.

Функциональные требования документируются в спецификации
требований к ПО (software requirements specification, SRS), где
описывается так полно, как необходимо, ожидаемое поведение системы.
Относяться к спецификации, как к документу, хотя это может быть база
данных или крупноформатная таблица с требованиями, хранилище
данных в коммерческом инструменте управления требованиями .
Спецификация требований к ПО используется при разработке,
тестировании, гарантии качества продукта, управлении проектом и
связанных с проектом функциях.
В дополнение к функциональным требованиям спецификация содержит
нефункциональные, где описаны цели и атрибуты качества.
Атрибуты
качества
(quality
attributes)
представляют
собой
дополнительное описание функций продукта, выраженное через
описание его характеристик, важных для пользователей или
разработчиков. К таким характеристикам относятся легкость и простота
использования, легкость перемещения, целостность, эффективность и
устойчивость к сбоям.
Другие
нефункциональные
требования
описывают
внешние
взаимодействия между системой и внешним миром, а также
ограничения проектирования и реализации. Ограничения (constraints)
касаются выбора возможности разработки внешнего вида и структуры
продукта.

12.

Характеристика продукта (feature) — это набор логически
связанных функциональных требований, которые обеспечивают
возможности пользователя и удовлетворяют бизнес-цели. В
области коммерческого ПО характеристика представляет собой
узнаваемую всеми заинтересованными лицами группу требований,
которые важны при принятии решения о покупке — элемент
маркированного списка в описании продукта.
Характеристики продукта, которые перечисляет клиент, не
эквивалентны тем, что входят в список необходимых для решения
задач пользователей. В качестве примеров характеристик
продуктов можно привести избранные страницы или закладки
Web-браузера, контроль за орфографией, запись макрокоманды,
сервопривод стекла в автомобиле, on-line-обновление или
изменение налогового кодекса, ускоренный набор телефонного
номера или автоматическое определение вируса. Характеристики
могут охватывать множество вариантов использования, и для
каждого варианта необходимо, чтобы множество функциональных
требований было реализовано для выполнения пользователем его
задач.

13. Классификация требований клиента

14.

Процесс формулирования требований — их выявление (elicitation), когда
потребности и ограничения высказывают лица, заинтересованные в проекте.
Для начала подумайте, как вы собираетесь выявлять требования к проекту. И
составьте план.
План должен отражать:
-цели выявления требований (например, проверка рыночных данных,
исследование вариантов использования или разработка подробного набора
функциональных требований к системе);
-стратегии и способы выявления требований (например, сочетание опросов,
семинаров, встреч с клиентами, интервью и других приемов с возможным
использованием различных подходов для разных групп заинтересованных лиц);
-результаты выявления требований (например, перечень вариантов
использования продукта, подробная спецификация требований к программному
обеспечению, анализ результатов опроса или спецификация атрибутов качества
и производительности);
-график и смету ресурсов (определите, кто из разработчиков и клиентов будет
участвовать в различных операциях по выявлению требований; примерно
оцените усилия и время на выявление требований);
-риски, связанные с выявлением требований (укажите факторы, которые могут
нарушить график работ по выявлению требований, оцените опасность каждого
фактора и решите, как смягчить его или управлять им).

15.

Для лучшего восприятия — некоторые из различных видов требований,
рассмотрим программу подготовки текстов.
Бизнес-требование может выглядеть так: «Продукт позволит
пользователям исправлять орфографические ошибки в тексте
эффективно». На коробке CD-ROM указано, что проверка
грамматики включена как характеристика, удовлетворяющая
бизнес-требование.
Соответствующие требования пользователей могут содержать задачи
(варианты
использования)
вроде
такой:
«Найдите
орфографическую ошибку» или «Добавьте слово в общий словарь».
Проверка
грамматики
имеет
множество
индивидуальных
функциональных требований, которые связаны с такими
операциями, как поиск и выделение слова с ошибкой, отображение
диалогового окна с фрагментом текста, где это слово находится, и
замена слова с ошибкой корректным вариантом по всему тексту.
Атрибут качества легкость и простота использования (usability) как
раз и определяет его значение посредством слова «эффективно» в
бизнес-требованиях.

16.

Каких требований не должно быть
Спецификация
требований
не
содержит
деталей
проектирования или реализации (кроме известных
ограничений), данных о планировании проекта или
сведений о тестировании. Удалите указанные элементы из
требований, чтобы из этого документа было абсолютно
ясно, что надлежит построить команде разработчиков. Для
проекта, как правило, создаются требования других типов:
документ, где описана среда разработки, ограничения
бюджета, руководство пользователя или требования для
выпуска продукта и продвижения его в поддерживаемую
среду.

Источник: ppt-online.org