Topic: What's the big deal about 'requirements'?

Message

   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. 

Author	Message
Mithi25 Senior Member Joined: 23Jun2009 Online Status: Offline Posts: 288	Topic: What's the big deal about 'requirements'? Posted: 22Sep2009 at 4:29am
	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.
	Send Unlimited FREE SMS to Any Mobile Anywhere in INDIA, Click Here Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Types Of Software Testing @ OneStopTesting : Manual Testing @ OneStopTesting