И. Соммервилл - Инженерия программного обеспечения (1133538), страница 33
Текст из файла (страница 33)
Описание базы данных должно ото. 6ражать логическую структуру данных, с которыми будет работать система, и отношения между ними В документе аоэможно использование различных указателей. Это может быть обычный алфавитный указатель, указатель диаграмм или указатель системных функций Указатели Конечно. информация, акзючаемая а спецификацию, зааисит от типа рззрабатыааемого программного обеспечения и от выбранной технологии разработки. Например, если при разработке будет использоваться эволюционный подход, многие разделы спецификации, перечисленные з табл. 5.4, будут излишни. Если же разрабатываемое ПО является только частью большой системы, состоящей из взаимодействующих аппаратных и про граммных систем, тогда по необходимости требования будут очень подробными н детализироаанными. В этом случае спецификация может иметь значительный объем н будет содержать больше раэделоз, чем перечислено з табл.
5.4. Для больших документов необходимо делать оглавление и подробныс указатели для поиска необходимой информации. ф$ аь ей ЬЬ4, то'бгйгсйие'того,' что бистемп дшпмз делатн' 'и такке огреие и рзелиз~йик~..„',":!ФЯ =:и. йе ° ".Фунщиананыпмфттгебоеания-.описание сережхж;'предостнвляемьц снщщюй, 'и способое ения,вычйслйтрльных'операций..Требоеажя предметной облести-. зто фунщиональные тре- ~:.„:„- ='збсеенйя," вцгпмй$у|фкнкп из.харектеристик той,предметной области, где будет зксплуетиро":."-;;-"аться "рэйьзребзтщвуия",жтема..':.".".!;,,'„ , ° ",гькйефункскйоьваьныое тсрвбования - зто огрченичениц наклздыеаемые на систему, нз процесс разра- ~ „;,фботкисистемй1пс:тмсьв енршние требоезния.
Они описйеекп свойства систеиы е целом. ,:;:ь',,~~фйшгьюнетельсуиепсрэебовэннв предназначены для людей,'которые будут зксплуатнроеать систему, ч$$фЯйи должйь~пйсртьоя.лсуестненным языком с использованием таблиц и димрзмм, простык для '- яеосприятненМууя '",е'фбСищеииь~е упгзебоеанйя должны' мзксимально точно описыезть фунщии, еыполняемые системой. Дня 'уменьшенпн неточности ФоРмулировок системные требоеания иогут записываться с поиощыо структурироЫйыьязыве, Зго может быть струкгурироезннзп форма естественного языке, язык, построейнмй''йп"','обйом' акого.йибудь языка программирования еысокого уровня, либо специальнйй'языктдф'сгнйтифиуироеания'требоеаний.
ь Спецйфмпгцнр::Фрчебомнегй-,.зго,официельное изложение системньц требований. Этот документ строф этекййбрззом'фобы его могли использовать как заказчики программного продукта, так й~теэрзбпьтрйёЯОЙВйге',"::. л: =".-'„:: ';,; 126 'Часть кк, Требомаииж Упражнения 5,1. Обсудите проблемы, возникающие при формулировании пользовательских и системных требований на естественном языке, и покажите на небольших примерах, как струаурированный естественный язык помогает избежать этих проблем. 5,2. Исследуйте точность формулировок следующего требования, описывающего автоматизированную систему продажи билетов. 5.3, Автоматизированная система продажи железнодорожных билетов.
Пользователь указывает пункт назначения, вставляет кредитную карточку и вводит личный идентификационный номер, Система выдает проездной билет и снимает с кредитной карточки сумму, равную стоимости проезда в укаэанный пункт. Когда пользователь нажимает начальную кнопку, отображается меню возможных пунктов на.
значения с указанием стоимости проезда до каждого пункта. После выбора пункта назначения польаователю предлагается вставить кредитную карточку. Затем проверяется кредитная карточка, после чего пользователю предлагается ввести личный идентификационный номер. По окончании операций с кредитной карточкой выдается проездной билет. бий Перепишите требование предыдущего лунка, используя структурный подход, списанный в этой главе.
5.5. Запишите системные требования для системы продюки билетов с помощью языка, основанного на языке программирования бата. Обратите внимание на обработку ошибок пользователя, 5,6. Опишите три типа нефункциональных требований, которые мокнут иметь место в программных системах.
Приведите примеры кахщого типа требований. 5.7. Запишите нефункциональные требования для описанной выше автоматизированной системы продажи билетов, характеризующие надежность системы и время ее ответа. 5.6. Какими свойствами должен обладать язык програмыирования, чшбы его маюю было применить для написания спецификаций интерфейсов? В этом аспекте рассмотрите возможности языков С, Зача и Аба.
5жк Поясните, как в спецификации системных требований можно проследить взаимосвязь между функциональными и нефункциональными требованиями. 5.10. Вы устроились на работу в фирму, которая заказала разработать некую программную систему в той организации, где вы работали ранее. Вы обнаружили, что фирма-заказчик интерпретирует некоторые системные требования не так, как органиэация-разработчик. Подумайте, что вы должны делать е такой ситуации, Вы знаете, что стоимость программной системы возрастет, если не будет устранено разночтение системных требований, С другой стороны, вы связаны обязательством неразглашения сведений о своей предыдущей работе.
Разработка требований ,Ц ь 1'д зэ знать основные процессы разработки требова иий и отношения между инни; ознакомиться с методами формирования и аиа лиза требований; понимать важность аттестации требований: знать, почему необходимо управление требова ниякш. гт' О О 6.1. Анализ осуществимости 6.2. Формирование н анализ требований 6.3.
Лтгсстация требований 6.4. Управление требованиями Цель настоящей главы — описать процесс разработки требований к ироелтируемой системе, Прочитав эт1 главу, вы должны: 128 к1асть П. Требования Разработка требований — это процесс, включающий мероприятия, необходимые для созд;т. ния и утверждения документа, содержащего спецификацию системных требований.
Различают четыре основных атапа процесса разработки требован ийт анализ технической ощпцествимости создания стктемы, формирование и анализ требований, специфицирование требований и соз. дание соответствующей документации, а также аттестация этих требований. В этой главе рассмотрены все перечисленные этапы, за исключением специфицирования и документирования, которые описаны в главе 5. На риц 6.1 показаны взаимосвязи между этими этапами и документы, сопровождающие каждый этап процесса разработки системных требований. Ркс. 6. й П1тпвгссутлтутпбптки эфеймлнкк На рис.б.1 показаны этапы формирования, документирования и проверки требований, Но поскольку в процессе разработки системы в силу разнообразных причин требования могут меняться, управление требованиями, т.е.
процесс управления изменениями системных требований, является необходимой составной частью деятельности по их разработке. Управление требованиями описано в заключительном разделе главы. Некоторые специалисты полагают, что для разработки требований необходимо применение структурных методов, например обьектно-ориентированного анализа 1302, 54, 12', 25"). Такой процесс разработки требований включает анализ системы и разработку набора графических моделей системы, которые затем используются для ее подробного специфицирования.
Хотя структурные методы играют существенную роль в процессе раз. работки требований, многие аспекты этого процесса не могут быть охвачены данными методами. Они неэффективны иа ранних стадиях процесса разработки, таких, как формирование требований. Поэтому здесь рассматриваются общие подходы к разработке требований, а структурные методы анализа и системные модели описываются в главе 7. 6.1. Анализ осуществимости Для новых программных систем процесс разработки требований должен начинаться с анализа осуществимости.
Началом такого анализа является общее описание системы и ее назначения, а результатом анализа — отчет, в котором должна быть четкая рекомендация, продолжать или нет процесс разработки требований проектируемой системы. Другими словами, анализ осуществимости должен осветить следующие вопросы. б. Разработка требований 129 1. Отвечает ли система общим и бизнес-целям организации-заказчика и организации- разработчика? 2. Можно ли реализовать систему, используя существующие на данный момент техно.
логии и не выходя за пределы заданной стоимости? $. Можно ли объединить систему с другими системами, которые уже эксплуатируются? Критическим является вопрос, будет ли система соответствовать целан бизнеса. Если система не соответствует этим целям, она не представляет никакой ценности для бизнеса В то же время многие организации разрабатывают системы, не соответствующие их целям, либо не совсем ясно понимая зти цели, либо под влиянием политических или общественных факторов. Выполнение анализа осуществимости включает сбор и анализ информации о будущей системе и написание соответствующего отчета. Сначала следует определить, какая именно информация необходима, чтобы ответить на поставленные выше вопросы. Например, эту информацию можно получить, ответив на следующие вопросы. 1. Что произойдет с организацией, если система не будет введена в эксплуатацию? 2.
Какие текущие проблемы существуют в организации и как новая система поможет их решить? 3. Каким образом система будет способствовать целям бизнеса? 4. Требует ли разработка системы технологии, которая до этого не использовалась в организации? Как только будут сфорыулированы подобные вопросы, необходимо определить источники информации. Это могут быть менеджеры отделов, где система будет использоваться, разработчики программного обеспечения, знакомые с типом будущей системы, тсхноло. гн, конечные пользователи и т.д. После обработки собранной информации готовится отчет по анализу осуществимости создания системы.
В нем должны быть даны рекомендации относительно продолжения разработки системы. Мокнут быть предложены изменения бюджета и графика работ по созданию системы илн предъявлены более высокие требования к системе. 6.2. Формирование и анализ требований После выполнения анализа осуществимости следующим этапом процесса разработки требований является формирование (определение) и анализ требований. На этом этапе ко. манда разработчиков ПО работает с заказчиком и конечными пользоватслямн системы для выяснения области применения, описания системных сервисов, определения режимов работы системы и ее характеристик выполнения, аппаратных ограничений и т.д.
В процесс формирования требований могут быть вовлечены люди разных профессий. В нем принимают участие конечные пользователи, которые будут работать с системой, инженеры, которые разрабатывают и эксплуатируют подобные системы, бизнес- менеджеры, специалисты по предметной области, где будет эксплуатироваться система, и даже представители профсоюзов.
Процесс формирования н анализа требований достаточно сложен по ряду причин. 1. Лица, участвующие в формировании требований, часто не знают конкретно, чего они хотят от компьютерной сисгелгы, за исключением наиболес общих положений; им трудно сформулировать, что они ожидают от системы; они могут предълвлять нереальные требования, так как не подозревают, какова стоимость их реаэизацнн. 130 Часть 11. Требования 2. Лица, участвующие в формировании трсбований, выражают в этих требованиях собствснныс точки зрсния, основываясь на личном опыте работы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
