Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 47
Текст из файла (страница 47)
Требования к программному обеспечению 227 Кроме входящей и выходящей информации, также необходимо обратить внимание на некоторые другие характеристики системы. в тои числе на ее производительность и другие типы сложного новедення, а также на иные способы взаимодействия системы с ее средой (рис. 23.1). Вывод $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ Атрибуум сиотвмноб орали $ $ $ $ $ $ $ $ $ $ $ $ У Атрибутм системы эффективность надежность пропускная способность и тп Фунщин-- узсс.
23.1. Элементы сисиммм 1. Вводы пьспьс$$ьс Необходимо не только указать содержимое ввода, но и, если нужно, подробно описать устройства, а также протокол (форму, внешний вид и содержание) ввода. Как известно большинству разработчиков, этот класс может содержать значительный объем сведений и подвергаться частым изменениям, особенно в средах СШ, мультимедиа и 1псегпец 2. Выводи скстемм. Нужно описать поддерживаемые устройства вывода, такие как речевой вывод или видеотерминал, а также протокол и форматы генерируемой системой информации. 3.
с(ьункции системы. Отображение вводов в выводы и их различные коььбинации. 4. Лифибути сыапемьь Типичные неповеденческие требования, такие как надежность, удобство сопровол$дения, доступность и пропускная способность, которые должны учитывать разработчики. 5. Акп~иб~иьм п$сэммной феди. Это такие дополнительные неповеденческие требования, как способность системы функционировать в условиях определенных операционных ограничений и нагрузок, а татке совместимость с операционной системой. На протяжении ряда лет мы использовали это разбиение на категории и убедились в его работоспособности.
Оно способствует целостному и полному восприятию проблем требований. Таким образом, можно предложить следующее определение. Используя аналогичный подход, Дэвис (1)аь)э, 1999) отиетил, что для полного определения системы необходимо описать следующие нять основных категорий элементов. 228 Часть 5. Уточнение определения системы Полный набор требований к программному обеспечению можно задать, определив следующее: ° вводы системы; ° выводы системы; ° функции системы; ° атрибуты системы; ° атрибуты системной среды. В результате мы сможем оценить, является ли некая "вещь" требованием к программному обеспечению, проверив, соответствует ли она данному подробному определению. Взаимосвязь между функциями и требованиями к программному обеспечению Ранее мы потратили некоторое время на изучение "функций" системы.
Функции представляют собой описания желательного и полезно~о поведения. Теперь мы увидим, что существует соответствие между функциями и требованиями к программному обеспечению. В документе-концепции описаны функции на языке пользователя.
Требования к программному обеспечению, в свою очередь, описывают эти функции более подробно. Чтобы предоставить пользователю некую функцию, разработчики должны выполнить одно или несколько конкретн. Таблица 23.1. Треоованпя, связанные с некоторой ф)ч>кцней докул>сита-концепции Документ-концепция Программные требования Функция 6$. Система обнаружения неполадок будет предоставлять информацию аб обнару- женных дефектах, чтобы помочь пользовате- лю оценить состояние проекта Ьйб>3.!.
Информация будет предоставляться в аиде отчета-гистограммы, где по осн х откладывается время, а по осн у — количество обнаруженных дефектов Дн>унннюкнеекня эированных програмлщых требований. Друг>ьчи словами, функции помогают понимать и обсуждать систему на высоком уровне абстракции, но с нх помощью невозможно описать систему и создать на основании этого описания код. Для этой цели функции слишком абстрактны. йрограннкне ' Требования к программному обеспечению более конкретизированы.
° . '~ '" щ" ° Мы собираемсн на их основе создавать код; следовательно, они должны быть "тестируемыми", т.е. достаточно конкретными, чтобы можно было проверить, действительно ли система реализует некое заданное треоование. Предположим, мы разрабатываем систему обнаружения неполадок для конвейерного производства или органиэации, разрабатывающей программное обеспечение, В табл. 23.! представлена некая функция документа-концепции и связанный с ней набор требований. Эта связь и воз. можиость осуществлять трассировку функций к требовю>ням (и наоборот) лежат в осно. ве очень важного понятия в области управления требованиями, известного как "трассируемость" (>гасеа)>|! !>у).
(Эту тему мы будем обсуждать позднее.) Глава 23. Требования к программному обеспечению 229 Окончонэсмабс 22! Документ-концепция Программные требования 5йб3.2. Пользователь может ззлзвать времен- ной периол в лиях, неделях илн месяцах 5263.3. Пример отчета об обнаруженных де- фектах представлен на прилагаемом р»»суз»ке Дилемма требований: что или как Требования сообщают разработчикам, что должна делать система, и должны описывать системные вводы, выводы, функции, атрибуты. а также атрибуты системной среды. Но существует много другой информации, которую требования не д»мжнм содержать. В частности, не следует указывать не являющиеся необходима»ми подробности проектирования или разлила.
ции, а также информацию, связанную с управлением проектом. Кроме того, не следует описывать, как система будет тестироваться. Тогда требования будут сосредоточены на поведении системы и будут изменяться только тогда, когда меняется поведение. Исключение информации, связанной с управлением проектом Иногда из соображений удобства менеджер проекта может включить в набор требований информщ»ию, связанную с управлениел» проектол», а именно графики, планы управления конфи»урацией, планы испытаний, бюджеты и штатные расписания.
Как правило, этого следует избегать, так как изменения в Г этой информации (например, изменения графика) будут приводить к необходимости замены устаревших "требований". (Когда требования датируются, им меныве доверяют и чаще игнорирузот.) Кроме того, неизбежные дебаты относительно вопросов управления проектом следует отделить от обсул»деиия того, что долзсна делашь гиги»сма. Существуют различные заинтересованные лица, и у каждого из них свои цели. П ыа Бюджет тоже может выглядеть как требование; тем не менее это информац»ш другого рода не удовлетворяющая нашему определению и, следовательно, не относящаяся к системным или прогрзмл»ным требованиям. Бюджет- важная информация, особенно когда разработчики ре»ниот, какую стратегию реализации избрать, поскольку некоторые стратегии могут быть слишком дорогостоящими, а время их выполнения слишком длительным.
И б т все же это не требование. Аналогично описание процедур тестирования или приемю» (с помощью которых мы будем определять, что требования действительно выполнены) также не удовлетворяет определению и, следовательно, не является требованием. Как следует из нашей практики, все же иногда полезно включить некую дополнительную информацию. Например, часто составитель требования может "намекнуть", какой тест подойдет для разработанного им требования. В конечном счете, он имеет представление о том, какое именно поведение соответствует данному требованию, н разумно воспользоваться его помощью. 230 Часть 3, Уточнение определения системы Исключение информации, относящейся к проектированию Требования также не должны содержать информацию о системной архитектуре я тсхннчссколл проекте.
В противном случае можно ненамеренно ограничить команду в выборе наиболее подходящих для данного приложения вариантов проектирования. ("Эй, мы должны проектировать его таким способом; так сказано в требованиях.") Исключить из требований детааи, относящиеся к управлению проек. Прае ванна том и тестированию, достаточно просто. Но исключение деталей проск. тирования и реализации ооычно гораздо более сложная и тонкая работа, Предположим, что первое требование в табл. 23. ! сформулировано еле.
дуювнги образом: мЖ63.!. Информация об обнаруженных дефектах будет предоставляться в виде отчета-гистограммы, написанного на У(лпа! Ваз(с, причем основные прн. чипы будут откладываться по осн х, а количество дефектов — по оси у" (рис. 23.2). 50 45 3 40 лс 10 ааюд агдеплнлп саазапяющнх Рис. 23.2. Оечат.гиплахРамиа Хотя указание Ъ'Впа! Ваяс в качестве языка написания программы является достаточ.
ио явным нарушением наших рекомендаций (поскольку оно не представляет ни ввод, ни вывод, пн функцию, пи атрибут поведения), полезно задать вопрос: Укто принял решение, что гистограмма должна быть реализована на У(лпа! Вайс, и почеллу оно было принято." Возможны следующие ответы. ° Один нз технически ориентированных членов группы, определяя документ. концепцию, решил, что следует укззать Уииа! Вапс, так как это "наилучшее" реше. ние проблемы. ° Это может быть указание пользователя, Опасаясь, что разработчики могут применить нскунл более дорогостоящ)чо и менее доступную технологию, пользователь решает, что технология У — доступная и относительно дешевая, и хочет, чтобы использовали именно ее.
° Политическое решение, принятое организацией-разработчиком, может диктовать, чтооы все приложения разрабатывзлнсь на У(лпа( Вал)с. Чтобы пресечь все попытки проигнорировать данную политику, руководство настзнвает, чтобы упоминание 'лгллпз) Вамс было повсюду, где это возможно, включено в документы требований. Если технический разработчик решил включить упоминание о У(лиа! Вжл(с, поскольку просто предпочитает данный язык, опо, бесспорно, не является легитимным элементом списка требований. Если это требование предложено пользователем, ситуация несколько Глава 23. Требования к программному обеспечению 231 иная. Если клиент отказывается платить за систему, написанную не на Н!зиа! Ветс, лучше всего трактовать подобное пожелание как требование, хотя мзо поместим его в сне!!иаль.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
