Integrated Software Requirement Management

May 5, 2009

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.

Working with clients on this requirement management challenge revealed that the System engineering and Requirements engineering was well covered as a process, though insufficient was data management integrated with change records and the ability to create different baselines. Keeping requirements line items synced in context with such changes was extremely difficult, in fact it is the kind of thing that keeps a configuration manager awake at night. Also internal relationships are stressed creating such (paper) baselines as in this client case it frustrated engineers as they felt it was not their task and responsibility.

So Software configuration management implicit must include integrated requirement management. Such integrated requirements management address the primary causes of software project failure, performance and cost. ‘Integrated’ would then comprise capturing of Software requirements and validation as described earlier, linked to downstream (external) development, (internal) testing activities to managing completion through a unified process across the development lifecycle, in fact the V-model I talked about in previous posts.
Integrated Change management keeps all stakeholders informed of changes to requirements throughout the development, verification process and the ultimate operational use of the product. Easy assessment and addressing of the impact of changes before implementation and reuse of requirements across projects and product lines increases business agility, improve software quality and reduce project risk.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: