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 :)

2 Answers 2


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.


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.
  • Upvoted for your kind efforts towards helping me. Just a quick question that is : Can Scalability be included in Non Functional requirement ? If yes than why? Commented Oct 2, 2020 at 0:43
  • @ILoveStackoverflow I would argue that "The system must remain usable no matter how large it grows" is a functional requirement.
    – Sarov
    Commented Oct 2, 2020 at 13:13
  • 1
    @ILoveStackoverflow shrugs So whoever wrote that article disagrees with me. Does it matter, as long as the requirement is still tracked and done? See the last paragraph of this Answer - there are grey areas.
    – Sarov
    Commented Oct 2, 2020 at 15:20
  • 1
    Some things depend upon the context. If your customer says they want a solution that can be scalable to maybe the whole town versus the whole warehouse, b/c they are trying to thing of the future plans... Then that is a functional requirement, but if your software architect said they wanted the developers to use Object Oriented Programming b/c of its scalability, I would think that is more of a non functional requirement. The first one, the customer says if the end product is functioning or not, the second one, you could still deliver the product whether you used OOP or not.
    – Spectrem
    Commented Oct 2, 2020 at 22:44
  • 1
    @ILoveStackoverflow, I have added additional details for assumptions.
    – Spectrem
    Commented Oct 5, 2020 at 21:46

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.

  • Upvoted for your kind efforts towards helping me. Can you suggest something related to Assumptions like what could be the assumptions? Any idea will do :) Commented Oct 4, 2020 at 2:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.