2.9 The Requirements Specification and Map

2.9 The Requirements Specification and Map

As presented earlier in this chapter, the requirements specification is a document that lists and prioritizes the requirements gathered for your architecture and design, and the requirements map shows the location dependencies between applications and devices. We will now discuss these two documents in greater detail.

In going through the requirements analysis process, you will be gathering, deriving, and determining requirements from a variety of sources, including users, management, administration, and staff, as well as from documents about the existing network and its applications and devices. Some requirements will be taken verbatim, others will have to be derived from available information, and still others will have to be estimated.

When a list of requirements has been developed, you will need to determine which requirements are core, or fundamental, requirements; those requirements that may be considered desirable features for the network; requirements that may be implemented in a future release or upgrade of the network; those that are to be rejected; and those requirements that actually provide information about the system but that may not be actual requirements. You will also need to prioritize requirements to help determine where funds are spent, the order in which functions and features are applied, and where they are applied in the network.

A requirements specification lists all of these requirements and specifies where they were gathered from or how they were derived; reasons why requirements were considered core requirements, features, future requirements, rejected requirements, or informational requirements; and their priority levels.

Figure 2.14 shows a template for this information on a per-requirement basis.

Requirements Specification
ID/Name	Date	Type	Description	Gathered/Derived	Locations	Status	Priority

Figure 2.14: Template for the requirements specification.

The fields of this template are:

• ID/name. This can be a number identifying the requirement in the order it was gathered or derived, or it can be the name of the requirement.

• Date. This is the date when this requirement was developed.

• Type. This represents the component that this requirement came from (user, application, device, network, or other).

• Description. This is a listing of the details, if any, for that requirement. As part of this description, you may indicate whether the requirement is functional or performance in nature.

• Gathered/derived. If the requirement was gathered, where it was gathered from is listed in this section. If the requirement was derived, how it was derived is listed here.

• Locations. Where this requirement applies in the environment, if known, is noted here.

• Status. This represents the current state of this requirement (core [or fundamental], feature, future requirement, rejected, or informational).

• Priority. This is a number representing the priority level of this requirement within its status type.

Requirements may be managed and tracked through common word processing and spreadsheet software applications. The examples shown here were developed using a popular spreadsheet application. There are also software tools that are optimized for requirements tracking. Experience has shown that most of the common word processing and spreadsheet applications are sufficient for this task.

Example 2.1: Requirements Analysis for a Company LAN

A first attempt was made to gather requirements for a building LAN network. The results were:

1. There are 150 users (60 engineers, 15 HR and Finance, 30 Manufacturing, 10 Management, 30 Sales/Marketing, 5 Other).

2. Each area in the building must support Fast Ethernet connections to the backbone.

3. Database, Visualization, Manufacturing, and Payroll applications are considered missioncritical for this company.

4. Inventory application (INV1) for manufacturing requirements are not determined at this time.

5. Database application (DB1) requires a minimum of 150 Kb/s per session.

6. Engineering users have workstations with GigE NICs.

7. Visualization application (VIS1) for finance requires up to 40 Mb/s capacity and 100-ms round-trip delay.

8. Payroll application (PAY1) requires 100% uptime (while in operation) between finance and outside payroll company.

9. Company must be kept secure from Internet attacks.

10. Company requires a minimum of T1 access to Internet.

11. Current network will be completely replaced, so there are no requirements from existing network.

12. Other general applications include the following: mail, word processing, internal and external Web access.

The first attempt at a requirements specification would look like the Figure 2.15. The requirements are just listed in order; there are no status or priority levels assigned at this point. There are two exceptions to this—requirements 1 and 11 are shown with a status of informational (info). Also, when possible, the locations of these requirements are placed on the corresponding requirements map. The requirements map is shown in Figure 2.16.

Requirements Specification
ID/Name	Date	Type	Description	Gathered/Derived	Locations	Status	Priority
1	14Jan03	User	User distribution is 60 engineers, 15 HR and Finance, 30 Manufacturing, 10 Management, 30 Sales/Marketing, 5 Other.	Gathered from Management	See Map	Info	TBD
2	12Jan03	Network	Each area of the building must support Fast Ethernet connections to the backbone. Database, Visualization, Manufacturing,	Gathered from Management	All Bldgs	TBD	TBD
3	12Jan03	Application	and Payroll applications are considered mission-critical for this company. More information needed. Inventory application (INV1) for	Gathered from Management	See Map	TBD	TBD
4	20Jan03	Application	manufacturing requirements not determined at this time.	Gathered from Users (MAN)	See Map	TBD	TBD
5	14Jan03	Application	Database application (DB1) requires a minimum of 150 Kb/s per session.	Gathered from Various Users	TBD	TBD	TBD
6	02Feb03	Device	Engineering users have workstations with GigE NICs. Visualization application (VIS1) for finance	Gathered from Users (ENG)	See Map	TBD	TBD
7	20Jan03	Application	requires up to 40 Mb/s capacity and 100-ms round-trip delay. Payroll application (PAY1) requires 100%	Derived from Application	See Map	TBD	TBD
8	11Feb03	Application	uptime (while in operation) between finance and outside payroll company.	Gathered from Management	See Map	TBD	TBD
9	12Jan03	Network	Company must be kept secure from Internet attacks.	Gathered from Management	TBD	TBD	TBD
10	02Feb03	Network	Company requires a minimum of T1 access to Internet.	Gathered from Network Staff	See Map	TBD	TBD
11	02Feb03	Network	Current network will be completely replaced, so there are no requirements from existing network.	Gathered from Network Staff	N/A	Info	TBD
12	20Jan03	Application	Other general applications: mail, word processing, internal and external web access. More information needed.	Gathered from Network Staff	TBD	TBD	TBD

Figure 2.15: Beginning of requirements specification for Example 2.1.

Figure 2.16: Beginning of requirements map for Example 2.1.