are here: Freetutes.com
Analysis and Design
Application of Technical methods in Software Quality Assurance
There are two major objectives to be achieved by employing technical
methods, firstly the analyst should achieve a high quality specification and the
designer should develop a high quality design.
Firstly we will take up the specification part. There is no doubt on the fact
that a complete understanding and clarity of software requirements is essential
for the appropriate and suitable software development. No matter how well designed,
well coded but a poorly analyzed and specified program will always be a problem
for the end-user and bring disappointment to the developer.
The analyst plays the major role in the requirements analysis phase and he
must exhibit the following traits…
The ability to grasp abstract concepts, reorganize into logical divisions and
synthesize “solutions” based on each division.
The ability to absorb pertinent facts from conflicting or confused sources.
The ability to understand the user/client environment.
The ability to apply the hardware and/or software system elements to the user/client
Software requirements must be uncovered in a “top-down” manner,
major functions, interfaces and information must be fully understood before successive
layers of detail are specified.
During software requirements analysis, models of the system to be built are
created and these models focus on what the system must do and not on how it has
to do. These models are a great help in the following manner….
The model aids the analyst in understanding about the system’s function,
behavior and it’s other information thus making the analysis task easier
The model is the standard entity for review and it is the key to determine
completeness, consistency and accuracy of the specification.
The model is the base/foundation for the design and thus it serves as the representation
of the software that can be “mapped” into an implementation context.
Quite often problems are too large and complex to be grasped as a whole and
then it is very reasonable to partition/divide them into smaller parts so that
they individually become much easier to understand and in the end one can establish
interfaces between the parts so that the overall function can be accomplished.
During the requirement analysis the information, functional and behavioral domains
of software can be partitioned.
Specification methods irrespective of the modes via which they are carried
out are basically a representation process. Requirements are represented in such
a manner that leads to successful software implementation. Blazer and Goldman
proposed eight principles of good specification and they are given as follows..
Separate functionality from implementation: As per the definition, the specification
is a description of what is desired rather than how it is to be realized/implemented.
Specification can have two forms. The first form is that of mathematical functions
in which as per the given set of inputs a particular set of outputs is produced.
In such specifications , the result to be obtained is entirely expressed in a
what rather than how form. Thus the result is the mathematical function of the
A process-oriented systems specification language is required: Here we will
take up the second form of the specification. In this situation the environment
is dynamic and its changes affect the behavior of some entity interacting with
the environment. This is similar to the case of embedded computer system.
Here no mathematical function can express the behavior. To express the same we
have to use process-oriented description in which the what specification is expressed
by specifying a model of the required behavior in the terms of functional responses
to various inputs from the environment. Now such kind of process-oriented specifications,
which represent the model of the system behavior, have been usually excluded from
the formal specification languages but one can not do without them if more complex
dynamic situations are to be expressed.
A specification must encompass the system of which the software is a component.
Interacting components make up a system. The description of each component is
only possible in the complete context of the entire system therefore usually a
system can be modeled as collection of passive and active components. These objects
are interrelated and their relationship to each other is time-variant. Stimulus
to active objects or agents as they are called are given by the dynamic relationships
and to these the agents respond which may further cause changes to which again
the agents respond.
A specification must encompass the environment in which the system operates.
Similarly, the environment in which the system operates and with which it interacts
must be specified.
Previous Page | Contents
| Next Page >>