Я нахожусь в процессе написания спецификации требований, и у меня возникла дилемма в формулировке части требований.
Сценарий: мы загружаем файлы с веб-сайта, и загруженные файлы необходимо прикрепить к элементу в имеющемся у нас инструменте CM. Загруженные файлы содержат имена, которые могут быть ASCII, ISO-8859-1, японский и т. Д.
В приведенной ниже фразе «не ASCII» охватывает все ситуации?
Загруженное имя файла может содержать не-ASCII-символы, и его обработка не должна приводить к сбою приложения.
Ответы:
Требование, как указано, для меня нечетко.
Первый вопрос, который у меня возникнет: сколько кодировок необходимо поддерживать? Возможные интерпретации включают в себя:
Если вы не укажете, какую кодировку вы имеете в виду, то при возникновении ошибки, связанной с кодировкой, вы и разработчик можете сразиться, и вы оба будете правы. Это, по определению, следствие нечеткой спецификации.
В дальнейшем, что программное обеспечение должно делать с именем файла, кроме того, чтобы не зависать? Если это ...
Лучшая версия вашего требования будет
Конкретные примеры требуемых кодировок необходимы для разработки критериев приемлемости. В добавленных предложениях указывается, что нужно сделать программному обеспечению, кроме того, чтобы не дать сбой.
источник
Написанное вами требование не имеет характеристик хорошего требования . В частности, это не связно, не атомарно и не однозначно. Из-за отсутствия этих характеристик это также нелегко проверить.
Ваше начальное требование к состоянию:
Я бы порекомендовал удалить «... и обработка этого не приведет к сбою приложения». Если у вас есть требование, чтобы какое-то программное обеспечение должно было что-то делать, я думаю, можно предположить, что оно должно делать это без сбоя программного обеспечения.
Это преобразует требование в:
Теперь у вас есть связное и атомарное требование. Однако я не уверен, что это однозначно. В своем вопросе вы упоминаете ряд различных форматов. Есть несколько вариантов.
Некоторые рекомендуют отдельное и уникальное требование для каждой кодировки имени файла, которая должна поддерживаться. Это наилучшим образом соответствует связным, атомарным, прослеживаемым, однозначным и проверяемым требованиям. Это также облегчило бы определение важности каждого требования - возможно, поддержка некоторых кодировок более важна или необходима раньше.
Другие могут рекомендовать таблицу поддерживаемых форматов, и это требование будет ссылаться на таблицу. Он будет менее полным (у вас есть текстовое предложение и таблица, которую нужно сохранить), но они будут в одном документе или базе данных. Однако, если вы собираетесь выполнить связывание в инструменте управления требованиями, их можно связать вместе, чтобы изменения в одном из них выдвинули на первый план связанное требование. Это также позволило бы передавать текст другим пакетам программного обеспечения, как есть, но с другой таблицей для разных кодировок.
Однако то, как вы документируете требования, зависит от ваших конкретных потребностей.
источник
Есть несколько проблем с вашей формулировкой, которые ослабляют требование:
1) Вы должны выразить требование в положительном выражении, а не в терминах того, что оно не должно делать . Как сделать один тест на «не сбой».
2) Фраза «Имя загруженного файла может содержать ...» расплывчата.
Предлагаемая альтернативная формулировка (сугубо субъективная, конечно) может быть:
Приложение должно поддерживать загруженные имена файлов, содержащие не-ASCII символы.
(Слово «поддержка» все еще немного расплывчато и может быть изменено, чтобы быть более конкретным, если принимать его вместе с другими требованиями для вашего приложения.)
источник
Проблема со спецификацией в том виде, в котором она написана, в том, что она не говорит, что приложение должно делать с «интересными» именами файлов. Я столкнулся с одной программой, которая заменила бы любые символы имени файла, которые он не понимал
_
, с тем эффектом, что когда его попросили скопировать каталог, который содержал два символа, имена которых были идентичны, за исключением символов, которые утилита не понимала, второй файл записанный в каталог перезаписал бы первый. Такое поведение будет квалифицироваться как «не сбой», но это не должно означать, что это допустимо при отсутствии явной спецификации, в которой говорится об этом.Я хотел бы предложить, чтобы в хорошей спецификации было указано, что должно произойти, или отметьте, какие действия допустимы, например: «Если имя файла содержит нераспознанные символы, система должна сгенерировать новый GUID для всей операции и сгенерировать имя файла который объединяет этот GUID, порядковый номер и любую часть исходного имени файла, которую можно легко разместить; он должен создать таблицу, отображающую старые и новые имена файлов »или« Если имя файла содержит нераспознанные символы, система может сформировать новый имя путем объединения символов, которые он распознает; если в результате такого преобразования два имени файла оказываются идентичными, любое из них может быть произвольно объявлено «победителем» ».
источник