Спецификацию требований в различных компаниях называют по-разному, при этом в этих компаниях названия не используются одинаково.
Спецификацию требований к ПО иногда называют документом бизнес-требований, функциональной спецификацией, спецификацией продукта или просто документом о требованиях.
В спецификации требований к ПО указываются функции и возможности, которыми должно обладать ПО, а также необходимые ограничения. Она должна содержать достаточно подробное описание поведения системы при различных условиях, а также необходимые качества системы, такие как производительность, безопасность и удобство использования.
Спецификация требований служит основой для дальнейшего планирования, дизайна и кодирования, а также базой для тестирования пользовательской документации. Однако она не должна содержать подробности дизайна, проектирования, тестирования и управления проектом за исключением известных ограничений дизайна и реализации. Даже тем, кто работает над проектами гибкой разработки нужна та или иная информация, содержащаяся в хорошей спецификации требований к ПО. Обычно такие разработчики не собирают всю эту информацию в виде целостного материала, но шаблон спецификаций требований служит удобным напоминанием, какие знания может потребоваться собрать. Завершается эта глава разделом, описывающим спецификацию требований в проектах гибкой разработки.
Внимание! Один материал требований часто не удовлетворяет потребностей всех аудиторий. Одним нужно знать только бизнес-цели, другие хотят получить высокоуровневую общую картину, третьих интересует только видение с точки зрения пользователя, но есть и такие, которым требуются все подробности. Вот почему мы активно рекомендуем создавать такие материалы, как документ концепции и границ проекта, документ пользовательских требований и спецификацию требований к ПО. Не следует ожидать, что все представители пользователей прочтут подробную спецификацию требований к ПО и разработчики узнают все, что им нужно, из набора вариантов использования или пользовательских историй.
Спецификация требований к ПО необходима различным участникам проекта:
В большинстве проектов создают одну спецификацию требований к ПО, но в крупных проектах это непрактично. В проектах крупных систем часто пишут спецификацию требований системы, к которой прилагаются отдельные спецификации требований к ПО и оборудованию (ISO/IEC/ IEEE, 2011).
Одна компания создавала очень сложное приложение управления процессами, в которых на протяжении уже многих лет задействованы более сотни сотрудников. В спецификации требований этого проекта было примерно 800 высокоуровневых требований. Проект был разбит на 20 подпроектов, в каждом из которых были собственные спецификации требований к ПО с примерно 800 или 900 требованиями, выведенными из системных требований. Это большой объем документации, но большие проекты становятся неуправляемыми, если в них не применять подход «разделяй и властвуй».
Есть и другая крайность: в одной компании создали лишь по одному руководящему документу для каждого проекта среднего размера, и назвали его просто — «Спецификация». Она содержала всю возможную информацию о проекте: требования, оценки, проектные планы, планы качества, планы тестирования — в общем, все. Управление изменениями и версиями такого всеобъемлющего документа представляло собой сущий кошмар. Кроме того, уровень информации в таком универсальном документе не соответствовал всем аудиториях, до которых нужно было довести информацию требований.
В третьей компании, где стали применять приемы гибкой разработки, вообще отказались от написания какой-либо формальной документации, — они стали писать пользовательские истории на записках-наклейках. К несчастью для одного проекта клей на записках высох и спустя несколько месяцев работы над проектом записки часто осыпались на пол, когда кто-то проходил мимо.
В еще одной компании выбрали промежуточный вариант. Хотя их проекты и не были большими и их можно было описать на 40–60 страницах, некоторые члены команды захотели разбить спецификацию требований к ПО на 12 отдельных документов: одну спецификацию для пакетного процесса, одну — для подсистемы отчетности и по одной для каждого из десяти отчетов. Подобный взрывообразный рост числа документов создает проблемы, потому что очень сложно обеспечить синхронизацию и эффективное предоставление нужной информации соответствующим людям.
Лучшим вариантом во всех этих ситуациях будет хранение требований в средстве управления требованиями, как описано в главе 30. Такое средство также оказывается очень кстати для решения дилеммы: создавать одну или несколько спецификаций требований в проекте, где планируется несколько выпусков продукта или итераций разработки (Wiegers, 2006). В этом случае спецификация требований к ПО для части продукта или определенной итерации представляет собой всего лишь отчет, созданный на основе запроса определенного содержимого базы данных.
Не обязательно составлять спецификацию для всего продукта еще до начала разработки, но необходимо зафиксировать требования для каждой итерации перед ее созданием. Это удобно, если в начале работы участники проекта не смогли определить все требования, а некоторую функциональность необходимо быстро передать в руки пользователей. Отклики об использовании ранних итераций позволяют скорректировать оставшуюся часть проекта. Однако при работе над любым проектом необходимо достичь базового соглашения по каждому набору требований до начала их реализации разработчиками. Выработка базового соглашения или базовой версии требований (baselining) представляет собой процесс преобразования реализуемых требований к ПО в то, что будет изучаться и одобряться. При работе с согласованным набором требований снижается вероятность недопонимания и ненужных переделок.
Структурируйте и составляйте спецификацию требований к ПО таким образом, чтобы все заинтересованные в проекте лица смогли в ней разобраться.
Ниже приведены советы, как сделать требования ясными и понятными:
| Способы представления требований | Требования к именованию |