Написание спецификации программного обеспечения

У меня есть несколько вопросов о написании спецификации, и они:

1. Когда мы пишем спецификацию программного обеспечения, в разделе «Определение требований пользователя» мы должны указать только «Функции» и «Ограничения»?

2. «Интерфейс пользователя» попадает в «функции» или «ограничения»?

3. На какие основные ключевые области (требования) можно разбить программное обеспечение (например, пользовательский интерфейс)?

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

Хотя это может быть излишним для некоторых проектов, он предоставляет большой контрольный список вещей для размышления, даже если это просто мысленная проверка списка, который вам не нужен для этого требования.

Вот ссылка на дополнительную информацию о шаблоне:

http://www.volere.co.uk/template.htm

Сам шаблон (и книга « Освоение процесса требований» - которая на самом деле немного дешевле, чем шаблон и содержит полный текст шаблона) содержит много информации, примеров и советов в различных разделах относительно того, что должно идти в каждом разделе.

Вот резюме разделов в нем (цитируется по ссылке выше):

1. Цель проекта

2. Заинтересованные стороны

3. Обязательные ограничения

4. Соглашения об именах и определения

5. Соответствующие факты и предположения

6. Объем работ

7. Модель бизнес-данных и словарь данных

8. Сфера применения продукта

9. Функциональные требования и требования к данным

10. Требования к внешнему виду

11. Требования юзабилити и гуманности

12. Требования к производительности

13. Эксплуатационные и экологические требования

14. Требования к техническому обслуживанию и поддержке

15. Требования безопасности

16. Культурно-политические требования

17. Правовые требования

18. Открытые вопросы

19. Готовые решения

20. Новые проблемы

21. Задания

22. Миграция на новый продукт

23. риски

24. Расходы

25. Пользовательская документация и обучение

26. Зал ожидания

27. Идеи для решений

Я рекомендую прочитать Джоэл о программном обеспечении. Я не уверен, отвечает ли он на ваши конкретные вопросы, но у него есть отличный обзор того, что значит писать функциональные спецификации :

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

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

... Когда вы пишете спецификацию, вам нужно только сообщить, как программа должна работать один раз . Все в команде могут просто прочитать спецификацию. Специалисты по тестированию читают его, чтобы знать, как должна работать программа, и знать, что нужно проверять. Специалисты по маркетингу используют его для написания своих смутных документов, в которых содержится информация о продуктах, которые еще не были созданы. Люди, занимающиеся развитием бизнеса, неправильно истолковывают это, чтобы раскручивать странные фантазии о том, как продукт излечит облысение, бородавки и все такое, но он привлекает инвесторов, так что все в порядке. Разработчики читают это, чтобы они знали, какой код написать. Клиенты читают его, чтобы убедиться, что разработчики создают продукт, за который они хотели бы заплатить. Технические писатели читают это и пишут хорошее руководство ...

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

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

Когда мы пишем спецификацию программного обеспечения, в разделе «Определение требований пользователя» мы должны указать только «Функции» и «Ограничения»?

Требование - это сочетание двух вещей ...

1. Что делает вещь Функциональное требование.
2. Как хорошо это делает. Нефункциональное требование или «Ограничение»

«Интерфейс пользователя» попадает в «функции» или «ограничения»?

Я бы сказал, что «Пользовательский интерфейс» будет категорией требований, как вы определили в своем последнем вопросе.

На какие основные ключевые области (требования) можно разбить программное обеспечение (например, пользовательский интерфейс)?

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

Конечно, все это является вторичным по отношению к вашей реальной цели, которая заключается в определении четкого, однозначного и проверяемого описания системы программного обеспечения.

Основным требованием к требованию является то, что оно подлежит проверке. Если вы не можете понять, как проверить требование, скорее всего, оно не будет реализовано так, как задумал автор.

Я никогда не видел документ с требованиями, ограниченный только функциями и ограничениями, но я вижу некоторую ценность в том, чтобы иметь такую ​​структуру - это вынуждает автора классифицировать требования на «вещи, которые должны делать программы», и «управляет Программное обеспечение должно следовать. "

Я думаю, что пользовательский интерфейс имеет требования в обеих категориях

Ограничения:

• «на экране запуска должны отображаться две кнопки:« Пуск »и« Стоп »
• «Шрифт дисплея должен быть не меньше 10 точек».

Функции:

• «Когда Startклавиша нажата, программное обеспечение должно установить соединение TCP / IP с WOPR »