Archive for the
‘Requirements Management’ Category

            We have discussed compliance testing earlier. This is known as testing to requirement. These requirements can be taken directly from a customer specification (when we have one) or derived internally from a requirements review or even both. Compliance testing is the primary method we use to ensure that we are meeting all specifications and […]

To perform embedded software testing, we recommend five phases of testing. These phases may take place concurrently and are as follows: Compliance testing Combinatorial testing Stochastic (or exploratory) testing Extreme testing Attack mode Each of these methods provides some view of the product the other method does not. Of course, testing the product is not […]

We do not need to suffer the pains of the risk due to spot checking.  We have a number of alternatives. For example: Modeling and simulation Iterative testing throughout the development Launch AND continue test and verification Launch and continue test and verification reduce volume of customers Relying upon modeling and other forms of simulation […]

Requirements management and configuration management are required for anything that even closely resembles effective testing.  Experience suggests failing in these two areas unnecessarily complicates the product verification activities, and we will show some of those traumas in the next few posts.  An iterative and incremental product development process calls for reviews throughout the development process.  […]

In some recent discussions with product development neophytes, we have heard a merging of the concepts of verification and validation.  Let us set the record straight.  Verification and Validation are not synonymous.  The World English Dictionary defines verification as “establishment of the correctness of a theory, fact, etc…”   and validation as “to confirm or corroborate”.  […]

I know this is way off topic; however I thought we should post this. Below is a letter my brother and I sent to the Veterans Administration. Our father was in the Special Forces and served multiple tours in Vietnam.  The US has been in wars for decades now, and we do not know the […]

We have recently had a discussion on what it takes to quality assure software. The discussion focused on FMEA and the role it plays in quality assurance.  The discussion began to sound as if the FMEA was the panacea for poor quality. There is no silver bullet. To be sure the FMEA (which is essentially […]

We have our requirements, our iterative packages and content defined, and now the developers are producing the iterations. During this time, the verification and test folks have been creating the test cases or details on how we intend to confirm the product performance. Our requirements provide the fodder for our testing.  For each requirement there […]

Once we have our captured our requirements. We identify the substance of the content for the iterations from the development.  In fact, recall from the requirements prioritization blog post. That work has given us some insight into how the iterative packages could be developed and what content or capabilities are to be delivered.  In the […]

One under or ineffectively used tool is the specification or requirements review, which is a form of design review. In this case we are reviewing the design while it is still easy and cheap to make adjustments.  Experience suggests, if we do not just forget to do this activity, it is a hastily arranged activity […]