Состав функциональной спецификации
Функциональная спецификация состоит из трех частей:
1. Описание внешней информационной среды, с которой будет взаимодействовать разрабатываемое программное обеспечение. Должны быть определены все используемые каналы ввода и вывода и все информационные объекты, к которым будет применяться разрабатываемое ПС, а также существенные связи между этими информационными объектами.
2. Определение функций программного обеспечения, определенных на множестве состояний этой информационной среды.
Вводятся обозначения всех определяемых функций, специфицируются их входные данные и результаты выполнения, с указанием типов данных и заданий всех ограничений, которым должны удовлетворять эти данные и результаты. Определяется содержание каждой из этих функций.
Следует отметить, что наиболее общей рекомендацией для этого этапа является структурирование (декомпозиция) целей программного продукта по схеме: основные цели —> подцели 1-го уровня. . . —>. . . подцели i-го уровня —>. . . . . —> подцели n-го уровня —> функции для пользователя ПО.
Результатом выполнения этапа должна быть структура целей программного продукта, которая может быть описана словесно, но наиболее наглядным является схематичное представление структуры целей, как показано на рисунке 1. Такая схема дополняется подробным словесным описанием содержания функций, подцелей и основной цели ПО.
3. Описание исключительных ситуаций, если таковые могут возникнуть при выполнении программ, и реакций на эти ситуации, которые должны обеспечить соответствующие программы.
Должны быть перечислены все существенные случаи, когда программное обеспечение не сможет нормально выполнить ту или иную свою функцию. Для каждого такого случая должна быть определена реакция программы.
ь
Автоматизация анализа успеваемости
студентов
Ввод информации
об успеваемости
Обработка информации
об успеваемости
Ввод информации
из зачетной ведомости
Корректировка
инф-и об успеваемости
Ввод результатов
экзаменов
Восстановление из
архив. копий
Защита от несакц.
доступа
Сохранение архив.
копий
Получение итоговой
ведомости успеваемости
Получение списков
неуспевающих
Получение
рейтинговой ведомости успеваемости
. . . . .
Вывод результатов анализа
. . . . .
Рисунок 1. Пример функциональной архитектуры
При написании функциональной спецификации удобно пользоваться несколькими простыми принципами:
- простота изложения;
- лаконичность;
- полнота;
- самодостаточность документа.
1) Простота. Спецификация должна
- быть написана простым человеческим языком;
- не иметь сложную структуру;
- по возможности, спецификацию нужно делать чем меньше, тем лучше.
В итоге, заказчик, начав читать вашу спецификацию, не должен отложить ее на потом из-за того, что ему сложно “въехать” в суть дела в короткие сроки.
2) Лаконичность. "Вода" в спецификации не нужна. Также не нужны в спецификации размышления. Нужны только выводы и руководство к действиям.
Плохо: "Вероятней всего, пользователь не захочет печатать XY графики, так как эти графики низкого качества и бесполезные. Поэтому мы не будем позволять пользователю печатать XY графики и деактивируем команду Печать."
Лучше: "Команда Печать будет неактивна для XY графиков."
Если ваше решение поставят под сомнение, тогда вы можете привести свои аргументы в отдельной переписке. В противном случае спецификация увеличивается и становится менее читабельной.
Не нужно пунктов в духе "Безопасность: не применима". Если пункт не применим, лучше ничего не писать.
Не надо писать о стандартном поведении программы. Например, не надо указывать, что выпадающий список будет содержать 5-12 элементов. Это стандарт, прописанный в руководстве по пользовательскому интерфейсу.
3) Полнота. Функциональная спецификация должна быть полной и покрывать все, что необходимо для того, чтобы разработать поставленную проблему. В то время как спецификация должна быть простой, она не должна порождать вопросы у заказчика (и у разработчиков тоже). Т.е. вы должны посмотреть на функции со всех сторон
4) Самодостаточность. Спецификация, как единый документ, должна быть самодостаточна. Не стоит наполнять документ ссылками. Пользователь документа не должен обращаться к каким-то другим источникам, чтобы получить полное представление о том, как должна работать та или иная опция или функция. Надо упростить работу с самим документом.