What should be cover in Functional and Non-Functional requirements for a network project?

Question

I am working on providing wireless infrastructure suggestions to a client like what software, hardware and equipment will be required to a client in order for them to set up the wireless infrastructure. Its a production site that is quite big and the client want wireless connectivity in each of the areas and also doesn't want to allow access outside of its premises securing data. Security is a big concern for a client and the client cannot afford any downtime as its a critical business for him.

I am creating a document suggesting hardware, software, equipment etc to consider as well as creating a document that will cover Functional and Non Functional requirements. I was just wondering as to what are the things to cover in Functional and Non-Functional requirements since its a networking project.

I will really appreciate any inputs or suggestions. Thanks in advance :)

Answer 1

Functional Requirements

Describes what the system should do or be capable of doing Typically if functional requirements are not met, then the system will not work (at least not in its entirety)

• The wireless infrastructure system shall provide wireless network coverage across the 3000 sqft warehouse.
• The wireless infrastructure system shall provide a wireless network with an upload/download data rate of at least 500 Mbps
• The wireless infrastructure system shall maintain 99% up time in a given year.

Non Functional Requirements

Describes how the system will achieve the functional requirements. Typically if non functional requirements are not met, then the system will still function but maybe not in the most ideal way.

• The wireless infrastructure system must use 15 XYZ model routers
• The wireless infrastructure system must space each router apart by 50 ft +/- 1 ft
• The wireless infrastructure system will must use both the 2.4 Ghz and 5 Ghz signal bands

Some non functional requirements may actually be functional requirements, especially if they are a design specification item that the customer/user requires. These can be a bit of a "case by case" situation.

Assumptions

Assumption help provide context as to why specifics were written a certain way. For example, if the functional requirements above are the only requirements you were given, then your assumptions might look like the following:

• Non functional requirements created under the assumption that the use case is for a maximum of 100 individual laptops at any given time.

As well, you could provide assumptions not only about your requirements but maybe your contract.

• Statement of Work written under the assumption that the customer is responsible for installation and maintenance of the wireless infrastructure system.

Answer 2

warning - this is a poor answer

This is a non-trivial question. I've spent many hours pondering this question and I've come to the conclusion that the question is not simple.

Reasoning by example is a poor practice, but....

Security is traditionally a non-functional requirement. Security describes how the product behaves. Based on that principle the following are all examples of non-functional requirements.

• Wireless should be available 95% (or five nines or whatever) of the time. Planned outages and intentional outages will not be counted against this number.
• Wireless network shall support X bandwidth; measured bandwidth falling below that threshold will be considered an outage, unless the failure is caused by overuse, as determined by Z.
• The wireless network shall support performance monitoring by team X using protocol/technology Y.
• Wireless should be resilient against denial of service attacks to standard X. Attempts to conduct denial of service should be detected at threshold Y, and reported in accordance with policy Z
• Wireless authentication should use X protocol and should not support Y &Z protocol.
• Wireless authentication should be resilient against N hours of X, Y & Z attacks. (e.g. firesheep)
• Wireless access control failures should be logged to the SIEM (and the logs should conform to the standards expressed in policy Z)
• Wireless should permit whitelist/blacklist site access
• Wireless nodes should be resilient against man -in -the middle attacks; wireless nodes should authenticate node to node with protocol X using institutional certificate Y
• In order to support reasonable expectations of integrity, wireless should support TLS version X
• In order to support monitoring, wireless will support monitoring through SSL and certificate insertion
• Connections originating from or traversing the wireless network will be identified in SIEM/Incident response.
• The wireless network must be segmented from the general network. There must be a separate security policy, with discrete enforcement.
• Incident response shall have the capability to isolate the core network from the wireless network as part of their response. (Exercise of this capability will not count against uptime.
• Incident management shall have the ability to segregate/isolate individual wireless networks while maintaining service to the total wireless network (if there is an incident in building X, we can shut off building X access).

I could argue most of those; I'm aware of edge cases where those are arguably functional for a specific system based on mission requirements. But the essence is that all of those don't describe the function of the wireless system - they describe how the system will accomplish that function.

Couple of notes to make the implicit explicit; this is a non-comprehensive list of examples drawn from security only because that is the field where I spend my time thinking about this problem.