Software Engineering

87
5.1 
Application of IPPD to software
5.1.4 
 Maximize flexibility for optimization and use of contractor 
unique approaches
This tenant of IPPD focuses primarily on agreements between customers, develop-
ers, suppliers, and subcontractors. Innovative techniques to software development 
can be both beneficial and detrimental to project success. While new or unproven 
approaches may appear advantageous, they should be selectively instituted under 
trial conditions to ensure they produce the desired results.
The second statement within this tenant addresses a concept of challenging 
requirements and offering alternative solutions that prove cost effective. This is 
a valuable idea that provides several benefits whenever it is applied. Challenging 
the validity of requirements improves the precision by which software require-
ments are captured and expressed. Stakeholder representatives typically view the 
software product from their own perspective. Thus, they will support the require-
ments that embellish the characteristics of the software product they are concerned 
with. Stakeholders must be challenged to identify what the software product must 
do and not overemphasize the importance of features or characteristics that are nice, 
sophisticated, or impressive.
Software requirements must be solicited and gathered from many sources. The 
complete set of requirements must be clarified and prioritized to establish the prec-
edence of product functions, features, and other characteristics. Each individual 
requirement imposes a cost on the development effort, therefore challenging the 
validity of the assists in weeding out the unnecessary or secondary stakeholder 
needs and expectations. The objective must be to reduce the set of requirements 
to the minimal necessary to result in a viable product that supports customer and 
stakeholder needs, are clearly specified so that there is no confusion concerning 
what is intended by the requirements statement, and fit within the project scope of 
resources and scheduled milestones.
In some instances, stakeholders do share the financial burden associated with 
their defense of particular requirements. If a company is funding a software devel-
opment effort, its representatives may feel responsible for getting the most prolific 
product for their money. They may misrepresent the importance of features and 
may argue the merit of unnecessary requirements with the software development 
team. Such representatives do not understand that they may cause the development 
effort to be doomed from the start by overburdening the development effort with 
excessive requirements. It is always necessary to challenge the validity of software 
requirements and to prioritize them before determining the minimal set that fits 
within the development project’s constrained resources.
Once the software development effort has begun, any proposed changes to 
the requirements baseline must be challenged immediately. The addition of new 
or modifications to existing requirements may necessitate significant rework to 
incorporate the change into the product architectural design. The cost associated 
with a requirement change must account for the effort to incorporate the design 

---