Самый низкий уровень детализации функциональных спецификаций для того, чтобы быть полезными
-
19-08-2019 - |
Вопрос
Там, где я работаю, люди не любят писать спецификации.(Боже, кто-нибудь знает?) Поэтому они этого не делают, если только их не вынуждают их боссы.Если их заставляют писать их, они делают их как можно короче.(Кстати, они также включает в себя я.)
Это приводит к таким спецификациям, как
- Это программное обеспечение записывает время между событиями A и B в журнал событий
- Имя и путь к параметру X задаются в файле конфигурации в формате ini.
- Программное обеспечение активно без необходимости входа пользователя в систему на компьютере (реализация как служба Windows).
Этот пример взят из очень небольшого проекта, и он сработал довольно хорошо, но я не думаю, что этого будет достаточно для чего-то более сложного.Я не уточнял требования к ОС / оборудованию, потому что это внутренняя разработка, и у нас есть стандарты компании или отдела, охватывающие их.
Итак, мой вопрос заключается в следующем:Каким вы считаете абсолютный минимальный уровень детализации в функциональной спецификации для любого нетривиального программного обеспечения?
Решение
ИМХО, важная вещь в функциональных спецификациях (и всех других формальных методах / инструментах для разработки программного обеспечения и планирования проекта (Yourdon, SSADM, PRINCE2, UML и т.д.) заключается в том, что они поощряют хорошую практику, заставляя вас мыслить в общих чертах.Они не гарантируют успеха, но способствуют успеху, формализуя передовую практику
Так что тот факт, что FSS созданы, - это хорошо, даже если, возможно, они могли бы быть лучше.Некоторое планирование и подготовка лучше, чем вообще ничего, что и делают многие разработчики.
Что в идеале должно входить в FS?Столько, сколько необходимо, и как можно меньше.Просто потому, что некоторые функциональные спецификации охватывают X, Y и Z, не означает, что ваши должны.Если вы станете слишком предписывающим, вы добавите ненужную бюрократию к более простым проектам;соответственно, для сложных проектов предписывающий подход может побудить разработчика остановиться на том уровне детализации, на который он действительно должен перейти.
Другие советы
Джоэл из отдела программного обеспечения написал статью о взломе спецификаций.
Вы можете найти его здесь Обсуждение спецификации