Gathering business requirements. Business requirements are high level requirements detailing the purpose of the wireless LAN, locations where wireless LAN services should be available, and what business functions and processes is a wireless LAN there to support. While business requirements are always defined by the business and gathered by the design engineer, the process of gathering these requirements should be a collaborative process.
Let’s consider Colin here. He’s receiving a set of unhelpful and probably unrealistic requirements. Now, a customer will always want the best wifi performance everywhere and at the lowest cost, but his requirements need to be unpacked by the design engineer. What is the customer actually trying to achieve with the wireless LAN and what did they mean by we want coverage everywhere? You see, it’s important to sit down with the stakeholders and spend some time unpacking their requirements. We see that here with Misty hosting an interactive design workshop where she’s discussing each area in turn.
So let’s talk about 10 areas, which should be discussed when gathering business requirements. First, we need to understand the purpose of the wireless LAN. Is the wifi just there to provide internet access for guests or is it a warehouse wireless LAN enabling picking activities via mobile devices? Does the wireless network need to spot mobile telephony or is its primary purpose to enable hot desking and collaboration spaces in a smart office? You see there are hundreds of driven reasons people install wifi, and as a designer, we need to have a very clear understanding of how the system is going to be used.
But why? Surely as a designer, you just need to design wifi coverage everywhere. Do you really care how it’s going to be used? Well understanding the purpose of the wireless LAN will or at least should affect the design. You see, if the wireless LAN is supporting a business critical process where we cannot afford any downtime, then AP redundancy will be required where every location is covered by at least two access points. If voice services are required then we need to ensure we have design which support seamless roaming, if location-based services are required, then access points will be installed closer to the perimeter than it would’ve been otherwise in a classic basic coverage design.
See, many of the business requirements are going to flow out of the purpose. Linked to the purpose is what expectations do the business have for the system? Maybe this system is mission-critical connecting healthcare equipment in a hospital and the network needs to be available 24/7. Maybe the system is required to provide a guaranteed level of throughput for a broadcaster to deliver a video stream. Maybe the business has expectations around the way they would like their users and devices to connect to the network, for example, being authenticated via active directory or guests connecting via a captive portal.
You see, it’s important at this stage to recognize that we are trying to get an understanding of the expectations that the business stakeholders have for the wireless LAN system. It might well be that these need to be redefined when we’re defining the technical requirements as we start to look at what is technically possible with the chosen wireless LAN solution. Once we understand the purpose and some of these expectations, we can start understanding what service areas are required. These are where do we require wireless services to be available? This stage will involve marking up a map or building plans and agreeing with the business stakeholders, which areas will have wifi coverage.
Now, again, at this stage, the default answer is always going to be we want coverage everywhere, but we need to define what everywhere means. Does it include bathrooms, stairwells, plant rooms, elevators? What about outdoor areas, car parks, smoking shelters, et cetera? If we already understand the purpose, we can help the customer define these areas. For example, if the system is to support voice over wifi, then do they require phone calls to be maintained on staircases when moving between floors?
Let’s say the purpose of the wireless system is to support a wireless name card in a psychiatric hospital where the name card includes a panic button and if a nurse is under attack, they can press the button, which will allow security and provide her location. Now, for this system, everywhere really does mean everywhere. Anywhere a nurse could be in danger. The stairs, elevators, restrooms. You see, we don’t want a situation when a nurse presses the panic button and we go, “Oh, sorry, we didn’t have wifi coverage there.” You see, understanding the purpose of the system feeds into all these other areas.
Some areas we may class as incidental coverage only. For example, restrooms. It’d be nice to have wifi coverage in the restrooms, but we’re not going to go as fair as installing an access point in the restroom just to provide coverage. Once we have these areas defined, we can then move on to thinking about capacity. We want to know the maximum number of users in a given area. For some areas such as office spaces, conference rooms, lecture theaters, this may be as simple as counting the chairs and sometimes can be done directly from the floor plan. For areas such as foyers and open areas, we need to get an understanding from the business of the worst case scenarios for each of these areas.
For example, there might be a company meeting which happens once a year in the atrium and when this happens, we get 1200 people all gathering in the same place. Now, for each area, we also need to know what devices will be used, and while there might be driven device types, what are the key devices for the business and our operations? Again, understanding the purpose of the wireless LAN can help you determine this. For example, is it a corporate laptop or is it a barcode scanner or is it a wireless name tag or a visitor’s personal device? This is a question the business stakeholders may struggle to answer.
For example, let’s take a university. When we ask the university what are their key devices? The answer might be, we don’t know. It could be any device a student brings in. While this answer may initially seem unhelpful, they have just told us that the key devices for the university are the devices the students bring in, and what are those devices? Well, most likely laptops, phones, tablets. It’s unlikely to be a barcode scanner, for example. And if this university currently has a wireless network management system, it might be possible to get some more statistics about the devices. For example, what is a percentage of iOS devices compared to Android? So while the initial answer might have been, we don’t know, we can work with the stakeholders to better define it.
And then for these key devices, we also need to know what applications they’re going to be using. For example, is the wireless LAN going to just be used for basic internet services or will there be streaming 4K video? Are we supporting barcode scanners, sending infrequent telnet data? At this stage, we are only interested in a high level view of what the users will be doing from a business perspective, we’ll not worry about how much bandwidth these applications require. We leave that for the defining technical requirements phase.
We talked about these key devices and key applications, but what about key personnel, are they individuals or departments which have greater wireless requirements? And if so, where do these people work? As we discuss the business requirements, we may also need to understand if there’s any financial constraints. It might be that the budget will actually constrain the business requirements. For example, stairwell coverage may be required to provide voice roaming, but if there’s not enough budget to install access points in every stairwell. Then the business may just have to accept intra floor roaming and not inter floor roaming, and they basically have to accept that voice calls may get dropped when moving between floors.
For some projects, financial constraints are just not applicable. The customer requires a design to meet all the requirements and then following the design it’s more than their budget, they may scale back to design. It’s also possible that you may be required to design some alternative designs. Maybe one design is going to include stairwells and outdoor areas and another design doesn’t. Another consideration is any legal and compliance requirements. For example, an organization that needs to process and store credit card information must be PCI-compliant, and being PCI-compliant requires the detection and location of rogue wireless devices.
And a final consideration is, does a business have any security requirements? Maybe there is a corporate security policy which a wireless LAN must comply with, or there might be some existing security systems which must be integrated into the wireless LAN. Once we have gathered and understood all the business requirements, we can then start to gather and define the technical requirements. So be sure to watch the technical requirements video linked at the bottom of this page. Thank you for watching, and goodbye for now.