Вопрос 4. Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы

Источники требований.

По характеру

Виды требований по уровням

Вопрос 3

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

1. Бизнес-требования — определяют назначение ПО, описываются в документе о видении (vision) и границах проекта (scope).

2. Пользовательские требования — определяют набор пользовательских задач, которые должна решать программа, а также способы (сценарии) их решения в системе. Пользовательские требования могут выражаться в виде фраз утверждений, в виде способов применения (use case), пользовательских историй (user story), сценариев взаимодействия (scenario).

3. Функциональные требования — определяют «как» (Ошибка! Не как, а что - "define what a system is supposed to accomplish" (см. англ. статью Functional_requirement)) реализовать продукт. Описывается в системной спецификации (system requirement specification, SRS).

1. Функциональный характер – это требования к системе.

2. Нефункциональный характер, это требования к системе, которые проистекают не из предметной области, не из среды, на которой пишем, а, например, из свойств автоматизируемого объекта (на станке с ЧПУ есть ограничение хода резца – 1 метр, например).

3. Системные требования: ограничения на программные интерфейсы, требования к атрибутам качества, применяемому оборудованию и ПО. Атрибут качества – это то, по чему оценивается качество.

4. Внешние и системные интерфейсы.

5. Ограничения.

1. Нормативное обеспечение организации – документы.

2. Текущая организация деятельности объектов автоматизации. Пользователи захотят делать на компьютере все так же, как делали и без него (перекладывать бумажки на столе слева-направо).

3. Модели деятельности. Диаграммы бизнес-процессов.

4. Представление ожидания потребителей и пользователей. Пользователь может потребовать радио, встроенное в пылесос. Нужно учесть сложность изменения представления пользователя – например, представление пожилых людей изменить сложнее.

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

6. Конкурирующие программные продукты.

Какие должны быть требования, их характеристика:

1. Единичность. Хорошее требование описывает только одну вещь.

2. Завершенность. Требование в одном месте описано и содержит всю необходимую информацию.

3. Последовательность. Требования не противоречат друг другу.

4. Атомарность. Требование не может быть разбито на ряд более детальных требований без потери завершенности или каких-либо других свойств.

5. Отслеживаемость. Требование полностью или хотя бы частично соответствует деловым нуждам. Не должно быть требований «с потолка снятых».

6. Актуальность. Требование до сих пор не устарело.

7. Выполнимость. Требование должно быть в принципе реализуемо.

8. Недвусмысленность. Требование должно быть определено

a. Кратко.

b. Не должно быть обращения к техническому жаргону.

c. Не должно быть скрытых формулировок. Когда выписываем требование, не нужно определять сущность.

d. Должно отражать объективные факты, а не чье-то мнение.

9. Однозначность, единственность интерпретации.

10. Утверждение при определении требований должно быть простым (не составным) и утверждение не должно быть неотрицательным.

11. Обязательность. Требование должно определять некоторый функционал, отсутствие которого приведет к неполноте решения. Необязательного требования быть не должно.

12. Проверяемость. Наличие требование может быть проверено.