What's the big deal about 'requirements'?
One
of the most reliable methods of insuring problems, or failure, in a
complex software project is to have poorly documented requirements
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' (too subjective). A testable requirement would
be something like 'the user must enter their previously-assigned
password to access the application'. Determining and organizing
requirements details in a useful and efficient way can be a difficult
effort; different methods are available depending on the particular
project. Many books are available that describe various approaches to
this task. (See the Bookstore section's 'Software Requirements
Engineering' category for books on Software Requirements.)
Care
should be taken to involve ALL of a project's significant 'customers'
in the requirements process. 'Customers' could be in-house personnel or
out, and could include end-users, customer acceptance testers, customer
contract officers, customer management, future software maintenance
engineers, salespeople, etc. Anyone who could later derail the project
if their expectations aren't met should be included if possible.
Organizations
vary considerably in their handling of requirements specifications.
Ideally, the requirements are spelled out in a document with statements
such as 'The product shall.....'. 'Design' specifications should not be
confused with 'requirements'; design specifications should be traceable
back to the requirements.
In some organizations requirements may
end up in high level project plans, functional specification documents,
in design documents, or in other documents at various levels of detail.
No matter what they are called, some type of documentation with
detailed requirements will be needed by testers 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.
'Agile' methods such as XP use methods requiring close
interaction and cooperation between programmers and customers/end-users
to iteratively develop requirements. The programmer uses 'Test first'
development to first create automated unit testing code, which
essentially embodies the requirements.
-------------
http://www.quick2sms.com - Send Unlimited FREE SMS to Any Mobile Anywhere in INDIA,
Click Here
|