Other Tutorials by

Visual Basic - Visual Basic tutorials

VB6 beginners tutorial - Learn VB6

Advanced VB6 tutorial - Learn Advanced VB6

You are here: > Systems 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 environments.

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 and systematic.

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 Principles

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..

  1. 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 input.

  2. 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.

  3. 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.

  4. 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 >>


Home | About Us | Privacy Policy | Contact Us

Copyright © | All Rights Reserved