In the previous post I talked about Software Configuration Management. This post is about management of software requirements and the link to software configuration management.
Although I did not specifically discuss management of software requirements in the previous post, it is evident that managing the configuration includes the specification sources i.e. the requirements. In the first recommendation of the previous post I touched on the object Work Request and example supporting materials e.g. specifications that may be attached. Ideally requirements are decomposed to individual requirement line items, i.e. similar to a tree. Each such line item would then specify the desired function but also instructions essential to developers but also test scenarios and the required end results that must be met.
In the requirements set you also find the actual failure mode and effect analysis i.e. if this function fails; what would be the effect and what would would need to be implemented that this failure would not occur. Obviously this is not just the software itself but the complete integration with the hardware it may need to control. As pointed out earlier, this level of detail is critical to also manage the prototype test process and also the actual life test i.e. the software as it is installed onto the product. The myriad of interconnections considering this level of detail and also combined with Change management records makes data management a daunting task without the right PLM capabilities.

Read the rest of this entry »