# L07 10 Requirements Templates (EARS)

https://www.youtube.com/watch?v=CT1FkZyceQY

[00:00] rather than staring at a blank sheet of paper.
[00:03] it can be better to use a template driven approach to writing requirements.
[00:07] one such approach is the easy approach to requirement syntax.
[00:12] years in this approach there is a standard template for all requirements.
[00:17] and that template is a while aware of some precondition and possibly a winner if of a trigger leads to the system shall response.
[00:28] there are a number of specific templates within that general pattern.
[00:31] one is the ubiquitous template the touch screen shall have a response time of less than 250 milliseconds.
[00:39] this is a situation which has to always be true for the system.
[00:44] the state-driven requirement template is while an external speaker is connected the internal speaker shall mute.
[00:53] so state driven is some condition that is true and the entire time that condition is true some requirement must be fulfilled but when that condition trends false.
[01:02] then the requirement no longer applies.
[01:04] the event driven template is when a card is inserted the card reader shall verify credentials.
[01:11] this is an action triggered by an event and the requirement has to have some sort of response that happens one time when the precondition is met.
[01:20] there's the optional feature pattern where a convertible roof is installed a park roof motion interlock function shall be provided.
[01:29] rationale that way the roof doesn't tear off when the car starts driving down the street.
[01:34] in this case the where keyword is intended to mean there's a feature or component that might or might not be in the system but if it's there this requirement applies.
[01:45] there's the unwanted functionality template if an invalid value is entered then an error message shall be displayed.
[01:53] this is intended to provide exception handling and error handling.
[01:58] the complex template isn't really a template it just permits the ability to
[02:02] mix and match the templates above.
[02:04] for things that have to be more complicated.
[02:07] to be sure you want to boil down requirements to the simplest possible form.
[02:11] but sometimes things are a little more complicated than the templates above.
[02:17] the ears work also has an interesting list of requirements.
[02:19] issues things that can be wrong with a requirement that's worth a quick look.
[02:22] the attributes of requirements they found problematic are requirements that are ambiguous.
[02:28] vague.
[02:31] complex omitted or missing.
[02:35] duplicated wordy.
[02:38] describe an implementation or are untestable.