Функциональные и нефункциональные инженерные требования

Лекция 4
Тема: Функциональные и нефункциональные инженерные требования. Функциональные и нефункциональные требования Требования к технологическому процессу Идентификация требований Требования Требования к изменениям
СТРОИТЬ ПЛАНЫ:

1. 
   Функциональные и нефункциональные инженерные требования.
   
2. 
   Функциональные и нефункциональные требования
   
3. 
   Требования к технологическим процессам
   
4. 
   Определите требования
   
5. 
   Проверить требования
   
6. 
   Изменение требований
   

Ключевые слова

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

Термин « спрос» не всегда используется в индустрии программного обеспечения. В некоторых случаях требование представляет собой весьма абстрактное описание услуги, которую должна предоставлять система, или ограничение системы. С другой стороны, это подробное формальное описание функции системы. Дэвис (Davis 1993) объясняет, почему существуют эти различия:
Если компания хочет заключить контракт на крупный проект по разработке программного обеспечения, она должна определить свои потребности достаточно абстрактно, чтобы решение не было ­предопределено заранее. Требования должны быть написаны таким образом, чтобы несколько подрядчиков могли предложить по контракту, возможно, предлагая разные способы удовлетворения потребностей заказчика. После заключения контракта подрядчик должен написать более подробное описание системы для клиента, чтобы клиент мог понять и проверить, что будет делать программное обеспечение. Оба этих документа можно назвать документами требований к системе ^f .
Некоторые проблемы, возникающие в процессе разработки требований, являются ­результатом невозможности четко разграничить разные уровни описания. Я использую термин «пользовательские требования » для описания абстрактных требований высокого уровня и системных требований для подробного описания того, что должна делать система. Пользовательские и системные требования ­можно определить следующим образом:

1. 
   диаграммы того, какие услуги система должна предоставлять пользователям системы, и ограничения, которые она должна выполнять . ­Требования пользователей могут варьироваться от подробных описаний функций системы до подробных и точных описаний функциональных возможностей системы.
   
2. 
   подробное описание функций, сервисов и операционных ограничений программной системы . Документ с системными требованиями ­( иногда называемый функциональной спецификацией) должен четко определять, что необходимо сделать. Это может быть частью соглашения между покупателем системы и разработчиком программного обеспечения.
   

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

1. 
   Система Mentcare должна составлять ежемесячные управленческие отчеты, показывающие стоимость лекарств, установленную каждой клиникой.
   

Спецификация системных требований

1. 
   В последний рабочий день каждого месяца составляется сводка рецептурных препаратов, их цен и рецептурных клиник.
   
2. 
   Система сформирует отчет после 17:30 последнего рабочего дня месяца для публикации.
   
3. 
   По каждой клинике будет составлен отчет с указанием индивидуальных наименований препаратов, общего количества рецептов, количества назначенных доз и общей стоимости рецептурных препаратов.
   
4. 
   Если лекарства доступны в разных дозировках (например, 10 мг, 20 мг и т. д.), для каждой дозировки создается отдельный отчет.
   
5. 
   Доступ к отчетам о ценах на лекарства должен быть ограничен авторизованными пользователями, указанными в контрольном списке разрешений руководства.
   

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

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

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