В теме 2 ответа, и 3 участника, последнее обновление сделано пользователем 
Надежда Тарасюк 12 г, 11 мес. назад.
-
Сообщения
-
Проверьте, пожалуйста, мою работу. Может подскажите что можно дополнить, изменить.Доброго дня!
тоже по диагонали
взгляд зацепился за следующее:
1) да, над языком описания надо работать.
1.1) Сложные конструкции могут привести к тому, что кто-то (или заказчик или разработчик) неверно поймут требование и будут проблемы).
"The Operating System must be Windows, and has been tested on Windows XP, Windows Vista and Windows 7." (тут не очень понятна вторая часть требования, при чем тут тестирование)
1.2) Не выдержан общий стиль написания (например, формат "система должна…") — в документе требование где-то начинается с результата, где-то с условий выполнения, где-то с подлежащего.
1.3) Часто не хватает конкретики и однозначности в требованиях, например "This program should be accessible on a site of the manufacturer." кто производитель? На каком сайте (их может быть несколько)? Как именно доступна ? и т.д.
1.4) где-то калькулятор называется "программой", где-то "системой" — в чем разница? если используются 2 понятия, они означают 2 разные вещи обычно.В общем, требование должно быть завершенным, атомарным, недвусмысленным и т.д.
2) Не очень поняла, почему меню помощи описано в General constraints, почему требование об удобстве использования в Portability и т.д. Создалось впечатление, что вы не до конца разобрались с разделами документа. Можно поинтересоваться для чего все это — может не надо использовать достаточно громоздкий шаблон для такого простого приложения?
3) Способ описания приоритетов MoSCoW (must, should, could, wont) — это один из способов (не единственный). И не факт, что читающий документ с ним знаком досконально, поэтому просится что-то вроде легенды в начале документа с объяснением что такое требование must, и т.д.
Вы должны авторизироваться для ответа в этой теме.
