А почему мы, тестировщики, столько времени возимся с функциональными требованиями? А как же остальные требования, коих тоже много, и кои тоже важны?
А дело в том, что функциональное требование это ‘A description of a behavior that a system will exhibit under specific conditions‘.
Продумывать ситуации, в которых может оказаться программа, и предусмотреть, как она должна из этих ситуаций выкручиваться — это ли не задача тестировщика?
Это.
На очень высоко абстрактном уровне все требования делятся на четыре слоя:
- бизнес-требования,
- пользовательские требования,
- функциональные требования,
- всё, что угодно, что попадает под понятие «нефункциональные требования».
Дальше начинается преданье, дальше начинается ересь от «По-моему, под функциональными требованиями подразумевается, что…» до «Шо вы мине голову морочите вашими требованиями, возьмите и напишите их себе сами, если они вам так нужны…»
Конечно, можно нужно учесть, что требование и спецификация — не одно и то же. Но чего это учитывать — их писать надо.
В алфавитном порядке толкование самых толковаемых терминов:
Business requirement
A high-level business objective of the organization that builds a product or of a customer who procures it. Это «Хотелки», которую ещё нужно правильно отобразиться в функциональных требованиях (коих может быть больше, чем одно), которые в свою очередь должны превратиться в спецификации.
Неприятность в том, что хотелки дают ответ только на вопрос «Зачем нужно что-то делать?», а большинство считает, что «Чё там валандаться по одному порошку в день, ох, тьма египетская в глазах…», и подразумевают, что хотелки будут рассказывать и зачем, и как это надо реализовать. Как же, читай потом этих доку-монстров…
Business rule
A policy, guideline, standard, or regulation that defines or constrains some aspect of the business. Not a software requirement in itself, but the origin of several types of software requirements.
Constraint
A restriction that is imposed on the choices available to the developer for the design and construction of a product.
Feature
One or more logically related system capabilities that provide value to a user and are described by a set of functional requirements. И попробуй теперь пересказать это своими словами, слабак.
Functional requirement
A description of a behavior that a system will exhibit under specific conditions. Ключевое слово — «ситуация».
Nonfunctional requirement
A description of a property or characteristic that a system must exhibit or a constraint that it must respect. То есть, нужно учитывать.
То есть, дураком буду, если скажу, что нон-фанкшынал рекуайрментс — это же не требования, бо есть же слово «нон».
Quality attribute
A kind of nonfunctional requirement that describes a service or performance characteristic of a product. Кто это учитывает?
System requirement
A top-level requirement for a product that contains multiple subsystems, which could be all software or software and hardware. Как такие требования пишутся?
User requirement
A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute. Не надо ждать, что пользователи придут, и предъявят свои требования. Будет очень плохо, если пользователи придут с требованиями.
© «Software Requirements» by Karl Wiegers and Joy Beatty, Third Edition, PUBLISHED BY Microsoft Press, ISBN: 978-0-7356-7966-5
Комментарии