Why Certification Matters to the Bottom Line

by Donna Moore, CEO of SpireSpark International

A certification program has a host of benefits but its main benefit is to the bottom line.  A cleverly designed and well managed certification program should both increase sales and reduce costs for participants.  How does it do that?  

Let’s start with increased sales. Certification means better interoperability, both with your own products and with others.  Product quality is significantly improved - resulting in fewer consumer issues, higher consumer confidence, better reviews, happy customers and increased brand value.  Product differentiation becomes possible as certified products provide assurance to consumers when selecting and purchasing products.

Reduced costs can be substantial as well.  Think lower return rates, decreased customer service calls, less tech support and truck rolls. Just one service call can wipe out the profits on a unit. Testing with certification tools and test plans in the early stages of development also leads to more robust products with fewer defects, thus resulting in early launch of products with reduced bug fixing effort.

While there may be initial cost and time to get a cert program up and running, it will increase the length of time the standard is in the market and provide a great return on investment where it matters – the bottom line.

For more information about setting up certification programs and their benefits, contact me: Donna@SpireSpark.com

The Importance of Clear Requirements

by Ralph Dale-Jones

The importance of requirements to any product are quite obvious: clearly without any, there is no likelihood of a product; with only a vague set, it is unlikely the product will resemble what was intended, and with imprecise requirements, it is more than likely that the product will not work in the way that was envisaged.

Writing, managing and ensuring that requirements are mapped to the final product is not an easy task. It is particularly difficult when multiple interacting systems are involved; high level requirements must span the whole system, followed by individual system requirements which then map further down the product life-cycle to individual components.

The more time spent writing clear requirements, the more likely it is that the end product will function as it should.  A popular process of developing a product from a set of requirements is the V-model, shown below, using the development of a DLNA project as an example.

On the left-hand side of the V-diagram are the requirements; on the right are the systems that test the requirements. At the highest level, work begins on the guidelines developing a feature, such as HTML-5 or Live Streaming; such requirements must span multiple devices and must not compromise existing features, an objective that becomes more and more difficult as the number of features grow.

On the V-diagram, guideline implementation is tested during certification of a device or set of devices; the documents and processes associated with certification must be updated and implemented to reflect the new guidelines.

At the next level down on the left hand side of the V-diagram is the test case specification; these are the test cases that must be implemented by the test tools in order to prove that the product implements the guideline correctly. The counterpart of the test case specification is, strangely enough, a set of tests that ensure that the test tools correctly implement the testing requirements of the specification. Finally, at the bottom level of the V-diagram is the detailed software design which maps to White box testing, such as Unit or Grey box tests.

The purpose of the V-diagram is to ensure that the requirements are mapped correctly, right through from the highest level to the lowest level; the means of enforcing this is the comprehensive set of testing on the right hand-side of the V-diagram. In the V-process an indication of a poor set of requirements is the so called out-of-phase error, which happens when an error is found which is traced to a level higher than the level of testing: for example, a guideline error found during software testing.

The amount of work involved in developing and testing requirements is not small but it will ensure traceability throughout the development and will result in a product that is more likely to resemble the one that was specified at the start of the project. The time spent on writing strong requirements and test specifications leads to considerable time and money saved in the later phases of the project.  There will be fewer Guideline clarifications, code updates, side effects and especially fewer bugs.