Archive for the
‘Requirements Management’ Category

We break form our blog run on sprint meetings due to incoming flambé du jour. Sometimes we see organizations that are afraid to use the most fundamental of tools, for example, fault tracking from verification.  Instead of using a tracking and visibility tool, we pass back and forth excel sheets behind the scenes. Why would […]

We like this saying and see much merit and believe it to be an axiom.  We have touched upon this a bit in our blog on sponges.  We see areas where one part of the company or development process makes due or improvises with the malodorous input received.  The receiving entity may complain and attempt […]

The customer is the receiver of the output; the customer can be an internal end customer or an intermediary to the next “chain” of events on the way to the final customer. Ultimately, we are aligning our actions (Suppliers, Inputs, Processes, and Outputs) in a way that provides the biggest benefits for our final customer. […]

Our organization’s structure can confound what constitutes and output.  Consider the company that is structured as a “functional” organization, the output from one group will typically go to another group in the system.  This organization structure is sometimes referred to as “silo” since each part of the company, group or department is segregated by expertise.  This has […]

Each process produces some sort of, at least intermediate output. The ultimate output will be the resultant of the series of inputs, processes and outputs, and will be directed toward the ultimate end customer. Therefore the ultimate output capability is the collection of all of the inputs and processes of the systems of the organization. […]

We like the title Random Acts of Product Development.   It often appears that product development is a collection of ill-conceived and poorly executed tasks.  Those planning refuse to recognize dependencies between groups and tasks and are unable or unwilling to acknowledge they are really working within a system – blinded by the solely important launch […]

We see well-meaning people adopt an attitude “if it needs done, then I will do it” even if their job or position in the company does not define them as the person to solve the problem. I call this absorption and it is part of the much ballyhooed “can-do attitude” upon which many companies thrive.  […]

            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 […]