Comments on: Requirements vs. Design http://embeddedgurus.com/barr-code/2009/02/requirements-vs-design/ A Blog by Michael Barr Tue, 24 Jan 2012 21:58:05 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Harry Levinson http://embeddedgurus.com/barr-code/2009/02/requirements-vs-design/comment-page-1/#comment-1873 Harry Levinson Thu, 17 Jun 2010 17:17:15 +0000 http://www.gfcdev.org/test-stack/2009/02/04/requirements-vs-design/#comment-1873 Consider adding a section on 'Test' expanding from above: Test The test of a system is a verification that Architecture, Design, and Implementation (3 layers of HOW) actually results in a product that reflects the requirements (WHAT). The test should not be a restatement of the requirement but a specific set of scenarios that have well defined outputs based on specific input states and values. Analogy: The requirement for an easy to use first floor kitchen would entail observation that the location is on the first floor, showing that all sinks, stoves, ovens, and drawers are within 5 feet of each other, and that the counter-tops are 30 inches above the floor. Consider adding a section on ‘Test’ expanding from above:

Test
The test of a system is a verification that Architecture, Design, and Implementation (3 layers of HOW) actually results in a product that reflects the requirements (WHAT). The test should not be a restatement of the requirement but a specific set of scenarios that have well defined outputs based on specific input states and values.

Analogy: The requirement for an easy to use first floor kitchen would entail observation that the location is on the first floor, showing that all sinks, stoves, ovens, and drawers are within 5 feet of each other, and that the counter-tops are 30 inches above the floor.

]]> By: peter kraak http://embeddedgurus.com/barr-code/2009/02/requirements-vs-design/comment-page-1/#comment-39 peter kraak Tue, 10 Feb 2009 04:19:00 +0000 http://www.gfcdev.org/test-stack/2009/02/04/requirements-vs-design/#comment-39 this is one of the simplest and well explained definitions of this usually mis-understood and problimatic area i have seen in two decades of embedded programming! i agree with your model. this is one of the simplest and well explained definitions of this usually mis-understood and problimatic area i have seen in two decades of embedded programming! i agree with your model.

]]> By: James Grenning http://embeddedgurus.com/barr-code/2009/02/requirements-vs-design/comment-page-1/#comment-38 James Grenning Wed, 04 Feb 2009 21:45:00 +0000 http://www.gfcdev.org/test-stack/2009/02/04/requirements-vs-design/#comment-38 If the code is developed using Test Driven Development, the tests become another form of documentation. A very powerful form. The tests say what the code is supposed to do and they verify that it does it.Like this:<b>TEST(sprintf, formatSingleString){ char buffer[20]; LONGS_EQUAL(12, sprintf(buffer, "%s\n", "Hello World")); STRCMP_EQUAL("Hello World\n", buffer);}</b>It takes a little getting used to but, this test specifies that a call to sprintf() has two outputs, the number of characters written to the buffer and the exact values of the characters written. If the code is developed using Test Driven Development, the tests become another form of documentation. A very powerful form. The tests say what the code is supposed to do and they verify that it does it.Like this:TEST(sprintf, formatSingleString){ char buffer[20]; LONGS_EQUAL(12, sprintf(buffer, “%s\n”, “Hello World”)); STRCMP_EQUAL(“Hello World\n”, buffer);}It takes a little getting used to but, this test specifies that a call to sprintf() has two outputs, the number of characters written to the buffer and the exact values of the characters written.

]]>