Page 64 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes meets that requirement. It is consistent if there is no requirement that conflicts with another.
Terminology can cause inconsistencies; for example, different requirements may use different
terms to refer to the same object. There may be logical or temporal conflict between requirements
that causes inconsistencies. This occurs if the SRS contains two or together by any software system.
For example, suppose a requirement states that an event e is to occur before another event f.
But then another set of requirements states (directly or indirectly by transitivity) that event f
should occur before event e. Inconsistencies in an SRS can reflect some major problems. All these
characteristics, completeness is perhaps the most important and also the most difficult property
to establish. One of the most common defects in requirements specification is incompleteness.
Missing requirements necessitate additions and modifications to the requirements later in the
development cycle, which are often expensive to incorporate. Incompleteness is also a major
source of disagreement between the client and the supplier.

Correct
The specification must define the desired capability’s real world operational environment, its
interface to that environment and its interaction with that environment. It is the real world aspect
of requirements that is the major source of difficulty in achieving specification correctness. The
real world environment is not well known for new applications and for mature applications
the real world keeps changing.
Complete
A complete requirements specification must precisely define all the real world situations that
will be encountered and the capability’s responses to them. It must not include situations that
will not be encountered or unnecessary capability features.

Unambiguous
Statement of a requirement is unambiguous if it can only be interpreted one way. This perhaps,
is the most difficult attribute to achieve using natural language. The use of weak phrases or poor
sentence structure will open the specification statement to misunderstandings.
Verifiable
In order to be verifiable, requirement specifications at one level of abstraction must be consistent
with those at another level of abstraction. Most, if not all, of these attributes are subjective and a
conclusive assessment of the quality of a requirements specification requires review and analysis
by technical and operational experts in the domain addressed by the requirements.
Consistent
System functions and performance level must be compatible and the required quality features
(reliability, safety, security, etc.) must not contradict the utility of the system. For example, the
only aircraft that is totally safe is one that cannot be started, contains no fuel or other liquids,
and is securely tied down.

Valid
To validate a requirements specification all the project participants, managers, engineers and
customer representatives, must be able to understand, analyze and accept or approve it. This is
the primary reason that most specifications are expressed in natural language.
3.5.4 Components of SRS

Component-based software development move towards is based on the idea to expand software
systems by selecting suitable off-the-shelf mechanism and then to assemble them with a well-
defined software architecture. Because the new software development paradigm is much
different from the traditional approach, quality assurance (QA) for component-based software
development is a new topic in the software engineering community.

58 LOVELY PROFESSIONAL UNIVERSITY