Archive for the
‘Configuration Management’ Category

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

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

You need not been so technically skilled to be able to see how many project fail due to requirements.  We provide a brief list of the failings below: Requirements control Insufficient time Did not include the sponsor or customer Late delivery of requirements Requirements traceability We will not write any more on requirements control that […]

The initial product requirements provide the product baseline. Our project planning will be focused upon delivering meeting these requirements. In a phased development process, we will prioritize the requirements (shown earlier) and deliver iterations.  This staged delivery allows us to gain additional insight into the product.  We may learn things that necessitate changes to the […]

Our configuration management is borne out of our requirements.  In our earlier blog post, we discussed how the project scope must be traceable to the requirements. In the case we present below, the project scope is a particular function or need to be met, for example a new feature or function for an automobile.  We […]

This may sound difficult, but there are some rules for good requirements.  According to the International Council on Systems Engineering (INCOSE http://www.incose.org/chicagoland/docs/Writing%20Effective%20Requirements.pdf), requirements should have the attributes below (similarly can be found at IEEE): Necessary –  driven by the objective of the project and business Verifiable – ability to objectively confirmed that the requirement is […]