Requirement specifications are important and one of the most reliable
methods of insuring problems in a complex software project is to have
poorly documented requirement specifications. Requirements are the
details describing an application's externally perceived functionality
and properties. Requirements should be clear, complete, reasonably
detailed, cohesive, attainable and testable. A non-testable
requirement would be, for example, "user-friendly", which is too
subjective. A testable requirement would be something such as, "the
product shall allow the user to enter their previously-assigned
password to access the application". Care should be taken to involve
all of a project's significant customers in the requirements process.
Customers could be in-house or external and could include end-users,
customer acceptance test engineers, testers, customer contract
officers, customer management, future software maintenance engineers,
salespeople and anyone who could later derail the project. If his/her
expectations aren't met, they should be included as a customer, if
possible. In some organizations, requirements may end up in high-level
project plans, functional specification documents, design documents,
or other documents at various levels of detail. No matter what they
are called, some type of documentation with detailed requirements will
be needed by test engineers in
order to properly plan and execute tests. Without such documentation
there will be no clear-cut way to determine if a software application
is performing correctly.
No comments:
Post a Comment