{"id":2887,"date":"2017-11-07T13:48:37","date_gmt":"2017-11-07T13:48:37","guid":{"rendered":"https:\/\/www.threesl.com\/blog\/?p=2887"},"modified":"2017-11-07T13:48:37","modified_gmt":"2017-11-07T13:48:37","slug":"functional-non-functional-requirements","status":"publish","type":"post","link":"https:\/\/www.threesl.com\/blog\/functional-non-functional-requirements\/","title":{"rendered":"Functional and Non-Functional Requirements"},"content":{"rendered":"

A Requirement that works and one that doesn’t?<\/h2>\n

Grammatically the difference between the types of requirement could be seen like that, but not so in RM (Requirements Management) parlance. Functional<\/em> and Non-Functional Requirements<\/em> are a what<\/strong> and how<\/strong> of engineering.<\/p>\n

\"HID
Interlinked Functional and Non-Functional Requirements<\/figcaption><\/figure>\n

Functional Requirement<\/h3>\n

These define what <\/strong>the features are. “The User Interface board shall send an enable signal when the user presses the On<\/em> key”<\/samp>
\nor “The finance reporting mechanism shall produce a summary report automatically at the end of each month”<\/samp>. These requirements tell the designer\/implementer what the systems need to do. They can be read and agreed by the customer and will align with their expectations of the system.<\/p>\n

Functional requirements are not limited to actions. They can include regulatory or safety\u00a0requirements, “The system shall be protected and able to be certified to IP44”<\/samp>, or internal rules “The output format shall be commensurate with detail explained in the operating procedures for the production line”<\/samp>. They can reference other external requirements or standards. “The electrical interface shall be compatible with USB 2.0 standards using type A connectors, verified by a third party.”<\/samp><\/p>\n

Non-Functional Requirement<\/h3>\n

These define how <\/strong>the system will operate. They will place constraints and capacities on the system that can be measured.\u00a0 “The User Interface\u00a0 enable signal shall be a TTL level present within 0.25 seconds of the user making contact with the physical interface”<\/samp> or “The finance reporting mechanism shall be capable of summarising 100K entries into the 10 specified categories”. <\/samp><\/p>\n

These limits and descriptions provide bounds within which the Functional Requirements<\/em> can me met. “The system shall allow users to cross the road safely”<\/samp> is a wide Functional Requirement<\/em>. “The user shall not need to interact directly with the facility”, “The design shall comprise of a fixed physical system requiring no power”<\/samp>. Looks like we’re building a bridge or subway rather than a pelican crossing then!<\/p>\n

Lines are Drawn<\/h4>\n

There is always going to be a grey line between the two areas. Some will depend where the responsibilities end and so on one project what is deemed a functional requirement. “The interface must be USB 2.0”,<\/samp> is a main operating characteristic that our system can not change and is needed to interface to an external system. On another project the functional requirement may be “The main system should interface with up to three external input and output devices”<\/samp> and the design team may decide “All inter product interfaces shall use USB 2.0 standard communications”<\/samp><\/p>\n

In the ideal world everything should operate 100% of the time without failure and should be completely intuitive. Should occur without delay and should be fixable for ever. However, the world we live in is not ideal. System designers need to recognise that. Non-Functional Requirements<\/em> can define these limits and manage expectations, from both a contractual and measurable quality point of view.<\/p>\n