Wi-Fi is a Passion


Requirement Analyse

Requirement analysis is the process of discovering projects requirements. Those are the needs of the customer that need to be met at the end of the project. That’s why gathering those requirements are so important. There are three types of requirements: business, user, and technical requirements.

Business requirements are objectives for the whole organisation. This is a vision or a scope of why the business wants to implement Wi-Fi. The internal business requirements are based on the organisation policies (for example a security policy that is in place). The external business requirements are based on government regulations.

User requirements are objectives created by the possible uses, like roaming throughout the building without losing connectivity. Most of the time those requirements are not SMART. SMART stands for Specific, Measurable, Achievable, Realistic/Relevant and Time-bound. In other words, “I want to transfer large files without taking an unacceptable amount of time.” Questions to consider are, what are large files and what is an unacceptable amount of time. The users are not specific enough and not able to measure those requirements. Here you see why you need to be communicative, because you need to ask the right questions.

Technical requirements are also called functional requirements. Those are which roaming must be supported or what wireless security method needs to be chosen. Those requirements need to be matched with the user and business requirements. It is possible that you need to create multiple technical requirements for one user or business requirement.

There are also regulatory requirements or constraints. For hospitals, you need HIPAA for example and when you work with payments you need to be PCI-DSS compliant.

There will be more constraints during a wireless design. One example is the budget constraints. How much will it cost is a common question. There are two types of budgets, one is called bottom-up, which means how much will it cost to implement this, or a top-down budget that states your budget that can you do within that what you want. Every design needs hardware, and that costs money. With less budget, you can deploy less access points. All the material that is needed will be written down in a Bill of Materials (BOM), and this is what is needed to order all the hardware.

Besides budget/cost, there are more constraints, such as the scope and quality that is based out of the requirements, and the schedule that depends on the resources that are available. Those constraints are called CSSQ (Cost, Scope, Schedule, and Quality).

Rough order of magnitude (ROM), is an estimation that varies between 15-20% over the actual cost.
Budgeted cost of work scheduled (BCWS) is scheduled at the beginning at the project.
Budget cost of work performed (BCWP) is compiled after the task is completed.
Actual cost of work performed (ACWP) is also after the task is completed. The cost variance is when the BCWP minus ACWP is not equal to 0. If it is positive there is not much wrong, but most of the time the CV is negative (since projects go over their budget).

The last part of this blog is about business objectives. Everything needs to be better (quality improvement), faster (efficiency improvement), cheaper (cost reduction) and more (increase production). Two issues with those improvements are that there is not enough budget to accomplish this or the important factor that businesses want, organisation continuity.