Information Technology Reference
In-Depth Information
A popular method for producing this desired refinement is to create a mock up
of the system based on the existing requirements, which will be used to evaluate its
effectiveness and to identify its weaknesses. This mock up, known as a prototype,
is essentially a scaled down version of the software system, produced with limited
functionality. When working to create the prototype, certain problems, such as
ambiguities and outright errors will become apparent as they hinder the creation
process. Evaluating the prototype is achieved by allowing users to interact with the
system and recording the experience. This method allows users to provide actual
feedback about the system's functionality, and is easier to gauge than a vague
discussion about intangible system characteristics (Stiller and LeBlanc
2002
).
6.2.3 Verifying Requirements Specification
All requirements should be verifiable. The most common method is by test. If this
is not the case, another verification method should be used instead (e.g. analysis,
demonstration, inspection, or review of design). Certain requirements, by their
very structure, are not verifiable. These include requirements that say the system
shall never or always exhibit a particular property. Proper testing of these
requirements would require an infinite testing cycle. Such requirements must be
rewritten to be verifiable. As stated above all requirements must be verifiable.
Non-functional requirements, which are unverifiable at the software level, must
still be kept as a documentation of customer intent; however, they may be traced to
process requirements that are determined to be a practical way of meeting them.
For example, a non-functional requirement to be free from backdoors may be
satisfied by replacing it with a process requirement to use pair programming. Other
non-functional requirements will trace to other system components and be verified
at that level. For example, system reliability is often verified by analysis at the
system level. Avionics software, with its complicated safety requirements, must
follow the DO-178B development process.
Verifiability is necessary for a requirement, but there are other important issues
as well. A requirement can be verifiable yet incorrect; and assessing verifiability
alone will not detect incorrect requirements. Moreover, verification is totally
irrelevant with regard to a requirement which has been overlooked. Mere analysis,
inspection, or review alone will find some of these issues but, generally, is far
weaker than usually is realized.
Only through effective communication between the client and the developers
can a system be accurately defined, and only with this clear definition can a project
hope to be successful. This process begins with the understanding of problems and
of technical solutions. Then the team leaders and members who did not talk to the
developer need to understand what was learned through team conversations.
Finally, organizational functions such as design, engineering, marketing, docu-
mentation, testing, and customers must also understand the problem, and agree/
correlate
to
the
technical
solution.
Customer-centered
techniques
necessitate
