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

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

К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

В данном подразделе рассматривается спецификация требо­ваний к системе регистрации для учебного заведения, бизнес-мо­дель которого описана в подразд. 3.3.2.

Уточненная постановка задачи для системы

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

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

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

11овая система должна позволять студентам выбирать 4 курса и предстоящем семестре. В дополнение к этому каждый студент может указать 2 альтернативных курса на тот случай, если какой-либо из выбранных им курсов окажется уже заполненным или от­мененным. На каждый курс может записаться не более 10 и не менее 3 студентов (если менее 3, то курс будет отменен). В каж­дом семестре существует период времени, когда студенты могут изменить свои планы (добавить или отказаться от выбранных курсов). После того, как процесс регистрации некоторого студента завершен, система регистрации направляет информацию в расчетную систему, чтобы студент мог внести плату за семестр. Если курс окажется заполненным в процессе регистрации, сту­дент должен быть извещен об этом до окончательного формирования его личного учебного плана.

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

Не нашли то, что искали? Воспользуйтесь поиском:

Лучшие изречения: Увлечёшься девушкой-вырастут хвосты, займёшься учебой-вырастут рога 9987 — | 7776 — или читать все.

Спецификация требований программного обеспечения (англ. Software Requirements Specification , SRS) — структурированный набор требований (функционал, производительность, конструктивные ограничения и атрибуты) к программному обеспечению и его внешним интерфейсам. (Определение на основе IEEE Std 1012:2004) Предназначен для того, чтобы установить базу для соглашения между заказчиком и разработчиком (или подрядчиками) о том, как должен функционировать программный продукт.

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

Читайте также:  Чем обшить стену возле буржуйки

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

В стандарте ISO/IEC/IEEE 29148:2011, который пришел на смену устаревшему IEEE 830, содержится рекомендации к структуре и методам описания программных требований — «Recommended Practice for Software Requirements Specifications».

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

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

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

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

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

Спецификация требований к ПО необходима различным участникам проекта:

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

Сколько нужно спецификаций?

В большинстве проектов создают одну спецификацию требований к ПО, но в крупных проектах это непрактично. В проектах крупных систем часто пишут спецификацию требований системы, к которой прилагаются отдельные спецификации требований к ПО и оборудованию (ISO/IEC/ IEEE, 2011).

Одна компания создавала очень сложное приложение управления процессами, в которых на протяжении уже многих лет задействованы более сотни сотрудников. В спецификации требований этого проекта было примерно 800 высокоуровневых требований. Проект был разбит на 20 подпроектов, в каждом из которых были собственные спецификации требований к ПО с примерно 800 или 900 требованиями, выведенными из системных требований. Это большой объем документации, но большие проекты становятся неуправляемыми, если в них не применять подход «разделяй и властвуй».

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

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

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

Читайте также:  Схема емкостного датчика влажности

Лучшим вариантом во всех этих ситуациях будет хранение требований в средстве управления требованиями, как описано в главе 30. Такое средство также оказывается очень кстати для решения дилеммы: создавать одну или несколько спецификаций требований в проекте, где планируется несколько выпусков продукта или итераций разработки (Wiegers, 2006). В этом случае спецификация требований к ПО для части продукта или определенной итерации представляет собой всего лишь отчет, созданный на основе запроса определенного содержимого базы данных.

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

Структурируйте и составляйте спецификацию требований к ПО таким образом, чтобы все заинтересованные в проекте лица смогли в ней разобраться.

Ниже приведены советы, как сделать требования ясными и понятными:

  • для структурирования всей необходимой информации используйте соответствующий шаблон;
  • разделы, подразделы и отдельные требования должны быть именоваться единообразно;
  • используйте средства визуального выделения (такие, как полужирное начертание, подчеркивание, курсив и различные шрифты) последовательно и в разумных пределах; Помните, что цветовые выделения могут быть невидны дальтоникам или при черно-белой печати;
  • создайте оглавление, чтобы облегчить пользователям поиск необходимой информации;
  • пронумеруйте все рисунки и таблицы, озаглавьте их и, ссылаясь на них, используйте присвоенные номера;
  • если при хранении требований в документе вы ссылаетесь в документе на другие его части, используйте возможности работы с перекрестными ссылками в вашем редакторе, а не сложную кодировку страниц;
  • если вы используете документы, применяйте гиперссылки, чтобы читатель смог быстро перейти к соответствующим разделам спецификации или другим файлам;
  • при хранении требований в специализированном средстве используйте ссылки, чтобы облегчить читателю навигацию по нужной информации;
  • включайте графической представление информации, где это возможно для облегчения понимания;
  • воспользуйтесь услугами опытного редактора, чтобы обеспечить последовательность документа и единообразие терминологии и структуры.
Ссылка на основную публикацию
Сони плейстейшен нетворк вход
Игры по сети, развлечения, друзья, покупки и многое другое – ваше сетевое приключение начинается в PSN. Подключитесь к нашему сетевому...
Смарт часы фикситайм 3 отзывы
Данный товар недоступен для доставки в Ваш регион Мы всегда стремимся к лучшему, чтобы радовать своих покупателей самыми выгодными ценами....
Смарт часы эпл для детей
1 min Apple Watch — самые популярные умные часы в мире. Является ли это идеальным выбором для вашего ребенка, зависит...
Сони f3112 xperia xa
Недорогой смартфон компании Sony (22 990 рублей за Dual версию) с интересным дизайном, LTE, двумя отдельными слотами для SIM-карт, слотом...
Adblock detector