Functional vs Non Functional Requirements
The official definition for a functional requirement specifies what the system should do:
“A requirement specifies a function that a system or component must be able to perform.”
A function is described as a set of inputs, the behavior, and outputs that should be measurable. In terms of a VMware Horizon View design scenario, a functional requirement could be “The solution should have the ability to support 1000 concurrent desktops, with the ability to scale by 20% over the next 3 years.”
The official definition for a non-functional requirement specifies how the system should behave:
“A non-functional requirement is a statement of how a system must behave, it is a constraint upon the systems behavior”.
A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. In terms of a VMware Horizon View design scenario, a non-functional requirement could be “The solution must use Cisco UCS blades, Cisco Nexus Switching and NetApp storage (FlexPod)”.
Conceptual, Logical, Physical?
A conceptual design is the first stage of the design process and describes the concept of the request or the end goal, but with no detail of how that will be achieved.
In the example of a VMware Horizon View design, a conceptual design statement could be “All 1000 call centre staff will use floating desktops”.
Next we move to the logical stage.
In the example of a VMware Horizon View design scenario, a logical design could focus on the pool design. Pool design covers a wide range of areas to include but is not limited to:
- Linked Clones vs Full Clones
- Floating desktops vs Dedicated Desktops
- Access methods
- Application delivery
- Virtual Hardware
The logical design describes how the solution will look, but does not detail the physical configuration.
The final stage, physical, builds upon the logical design taking into greater depth.
In the example of a VMware Horizon View design scenario, a physical design statement could be, “The floating desktop block will be hosted within Pod 1comprised of 16 UCS Blades each configured with Intel 2.8Ghz CPUs and 196GB RAM. The block with have dedicated NetApp storage comprising of 250GB flash and 6TB 15K SAS storage”. This is a brief example and would normally cover every component and setting of the design.
The Business Case for Desktop Virtulization
I’ll highlight the key benefits to keep in mind, however strongly recommend reading VMware’s Business Case for Desktop Virtualization guide to further enhance your knowledge.
- The power of the underlying VMware infrastructure, vSphere, with all of its functionality and maturity
- Ease of setup and management: one management console
- PCoIP remote desktop protocol: optimized out of the box to give you high performance over a
- LAN or WAN, with automatic adjustment to network speed and latency
- Integrated user profile management system (View Persona Management)
- Application virtualization software (ThinApp)
- Offloading of antivirus protection to a virtual appliance (vShield Endpoint)
- Management of linked-clone desktop images (View Composer)
- Access to View desktops from all popular mobile devices: Windows and Mac laptops, Android tablets, and iPads
Determine availability requirements for a View Conceptual Design
Most View deployments will require a very high uptime and will be required to meet strict SLA’s. Availability is made up of a number of areas, including both uptime and downtime, reliability, redundancy and resiliency. All of which need careful consideration in any View deployment.
Determine reliability requirements for a View Conceptual Design
What steps can be put in place to ensure the reliability of your design? Starting from the ground up.
- Redundant network connectivity (Multiple switch connectivity)
- Redundant load balancing
- Storage with resiliency
- HA and DRS on the vSphere infrastructure hosting the desktops and management machines for host resiliency (if applicable!)
- Further protection of vCenter (vCenter heartbeat? FT?) when using View Composer.
- Multiple View components (Security/Connection/Transfer Servers)
- Multiple ThinApp repositories
Determine manageability requirements for a View Conceptual Design
The four main aspects for manageability considerations are:
- Compatibility (can it be managed as part of the design)
- Usability (how easy is it to manage)
- Interoperability (does it integrate into other structures in the environment)
- Scalability (how well will it work as the environment grows)
Identify interoperability requirements for a View Conceptual Design
How will the consumers of the virtual desktops access the environment.
- Windows OS / MAC OS / iPad / iPhone / Android
How will View fit with existing infrastructure applications:
- Anti Virus
- VC OPS
Determine Security requirements for a View Conceptual Design
How many total and concurrent sessions are anticipated?
- Remember session and access limits.
If users access View desktops over the internet, we need to consider:
- DMZ infrastructure (View Security Servers)
- Load balancing requirements at the ingress point
- Additional open ports on firewalls
Is a VPN required?
- Verify that there are ample licences available as well as capacity on the firewalls
- Can end client devices establish a tunnel
Can users bypass View Connection Server?
- Security Considerations
- Potential for access conflicts
- Implications for monitoring session usage
Identify desktop personas and user experience requirements
What type of profiles will be used?
- Local or Roaming
Will mandatory profiles be used?
Where will user profile data be stored?
- How will it be backed-up
- Will it be highly available
Will users have access to multiple flavours of OS?
- Windows XP
- Windows 7
- Windows 8
Will 3D rendering be required?
Will Windows Aero be required?
What user expectation has been set?
Evaluate mobility requirements
Will access be granted to smartphones/tablets?
How will clients be made available?
Will specific locked down desktops with reduced functionality be used for this purpose?
Is there a case for local mode desktops? (This may require a re-visting you design to ensure optimised bandwidth and ensure transfer servers are available)
Will mobile device management be put in place to ensure any ‘lost’ devices can be remotely wiped?
Determine ROI/TCO requirements