Current methods and methodologies tend to concentrate on data a processing type requirements. In many projects, network engineers are the last to know about a project and thus are struggling to meet the already agreed upon deliverable date.

Here at SBDi we share the following information with the network engineers as soon as we have validated:

1.	A description of the different roles that will be accessing the system through the network. This includes:
	a.	the type of messages (events) that will be transferred to/from them
	b.	the amount of information being transferred to/from them
	c.	the type of device they will be using (wireless telephone or wireless palm as an example)
2.	A description of traffic patterns. This includes:
	a.	normal hours of usage
	b.	peak (time of day or season)
	c.	traffic loads measured in low, average, high, and exceptional (typically on high volume days of a season)
	d.	expected growth over the next five years
3.	Expected quality of service. This includes:
	a.	response time
	b.	reliability
	c.	security (ie: encryption)
	d.	confirmations
4.	Implementation Schedule
	a.	What parts will be implemented first

Many of these questions will at a minimum need to be detailed by the who (external interface), what (type of data), when (events).

What is most important is to supply this information as soon as possible. Allowing them access to review requirements via a requirements management tool will save time and keep communication lines open.

Recommended Reading: The Sept/Oct Issue of Software Testing and Quality Engineering (STQE) has an article on using the Requirements Set Pattern to validate the requirement set. "Are Your Requirements Complete."

Pat Ferdinandi