Спецификация требований к ПО

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

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

· менеджеры проекта по данным спецификации рассчитывают графики, затраты и ресурсы;

· команда разработчиков ПО получает представление о создаваемом продукте;

· группа тестирования составляет планы тестирования, варианты использования и процедуры;

· специалисты по обслуживанию и поддержке получают представление о функциональности каждой составной части продукта;

· составители документации создают руководства для пользователей и окна справки на основании спецификации требований к ПО и дизайна пользовательского интерфейса;

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

· персонал, занимающийся юридической стороной проекта, проверяет, соответствуют ли требования к продукту существующим законам и постановлениям;

· субподрядчики строят свою работу и несут юридическую ответственность также согласно спецификации требований к ПО.

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

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

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

· разделы, подразделы и отдельные требования должны быть названы согласованно;

· оставьте текст не выровненным по правому краю, не выравнивайте его по ширине;

· оставляйте достаточно свободного пространства («воздуха»);

· используйте средства визуального выделения (такие, как полужирное начертание, подчеркивание, курсив и различные шрифты) последовательно и в разумных пределах;

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

· если вы ссылаетесь в документе на другие его части, используйте возможности работы с перекрестными ссылками в вашем редакторе, а не сложную кодировку страниц;

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

Требования к именованию

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

Нумерация по порядку

Это способ, при котором каждому требованию присваивается уникальный порядковый номер, например UR-9 или SRS-43. Коммерческие средства управления требованиями присваивают такой идентификатор, когда пользователь добавляет новое требование в БД. (Эти средства также поддерживают функцию иерархического именования.) Префикс обозначает тип требования, например UR означает «user requirement» («пользовательское требование»). При удалении требования номер повторно не используется. Такой простой поход нумерации не обеспечивает логического или иерархического группирования связанных требований, а названия не раскрывают содержания требования.

Иерархическая нумерация

Это наиболее распространенный способ. Если функциональные требования приводятся в разделе 3.2 спецификации, то все их номера будут начинаться с 3.2 (например, 3.2.4.3). Чем больше цифр, тем больше уровень детализации требования. Это способ отличается простотой и компактностью. Ваш текстовый редактор может назначить номера автоматически. Однако даже в спецификации среднего размера нумерация может быть весьма длинной. Вдобавок названия, состоящие только из цифр, ничего не говорят о назначении требований. Когда же вы начнете применять этот метод на практике, то обнаружите, что присваиваемые названия не являются неизменными. Если вы вставите новое положение, то номера всех последующих фрагментов увеличатся. А после удаления или перемещения требования — уменьшатся. При этом нарушаются все ссылки на эти фрагменты.

Вы можете усовершенствовать этот способ. Пронумеруйте важнейшие разделы требований иерархически, а затем выделите отдельные функциональные требования в каждом разделе с помощью короткого текстового кода, после которого проставьте порядковый номер. Например, если в спецификации требований к ПО есть «Раздел 3.5 — Функции редактора», то требования в нем будут названы ФР-1, ФР-2 и т.д. При этом соблюдается определенная иерархия и структурированность документа, названия достаточно короткие, осмысленные и менее зависят от местоположения в документе.