Best Approach for subnetting/VLANing traffic?
Right. I'm going to be brutally honest, because it's what I'm good at.
Throw away your Trendnet switches. Get HP Procurves. Don't settle for anything less than 2510-48Gs, with PoE if you want to use VoIP phones which are powered from the network.
If you're going PoE, make sure that your phones and switches are both certified as 802.3af/at compatible, (and backward compatible) so that you can expand the network later without worrying.
Let's pretend you've got the following network:
192.168.0.0/24 - VLAN 1 - Management traffic only.
192.168.1.0/23 - VLAN 2 - Data.
192.168.3.0/23 - VLAN 3 - Voice.
You put the switches VLAN 1 interface on, you guessed it, VLAN 1. You set the ports for phones Untagged VLAN 2, Tagged VLAN 3.
Configure your phones to expect voice traffic on VLAN 3. Use VLAN 2 as the pass-through VLAN for data on the data/passthru port.
Don't bother segregating Engineering because they're handling large files. It'd only serve to irritate the users, and won't gain you much in the way of network performance.
The reason for having VLANs is to decrease the size of a broadcast domain, which if you have a huge flat network is a big issue. You can also use VLANs to guarantee delivery of VoIP packets to cut down jitter. There's also the ability to segregate traffic for security reasons. Unless there's a big incentive to do any of this for Engineering, frankly, I wouldn't bother.
If you add VLANs willy-nilly, you also increase the amount of routing power needed to allow traffic to traverse VLANs in the network. There are some routers which will require further licensing to allow 10+ VLANs to be routed to.
An interesting sidenote worth making is that if Engineering are handling really huge files, then there may be some advantage to putting them on a 10Gbit Ethernet network, but you'd also need a NAS device / file server that was 10GbE capable.
I guess I'll throw my $0.02 into the ring too.
First of all, you don't need to change your network from a flat one before bringing in VOIP - ideally, setting up a VLAN for voice traffic and configuring QoS and the like would be part of the project to switch over to VOIP.
And secondly, yes, you want a separate VLAN for VOIP. It's so common to use separate VLANs for voice traffic that it's a de facto standard, in addition to being "best practice" and a good idea. Doing so makes your network more secure and easier to manage and troubleshoot when issues do arise.
Finally, creating a new VLAN for the engineering department won't (or shouldn't) necessarily do anything to impact the speed of file transfers - VLAns are more for logical segmentation and security than anything else. I'd recommend taking a look at Evan Anderson's answer here, which gives you the basics of what a VLAN is, does, and when to use them before you go any further down this path.
Ok, here is my opinion and some background. I've installed a couple of smaller VOIP solutions for a company I used to work for. The largest installation we had was about 50 phones in one location.
Now, even with that setup we didn't use VLAN's. Why? Because you can QoS without VLAN's and it's not too hard. If it was bigger than this, then I would have likely placed it into a VLAN. But part of the reason I didn't do it is because we had limited ports available at the customer premises and unmanaged switches. They had hardly any budget and although I was nervous about it, it worked fine. In fact we used the passthrough ports on the phones where the phone itself has a port that you connect to the LAN and then another which you connect to the computer.
Basically VLANing can sometimes make it a little easier to filter and prioritise the VLAN VOIP traffic. Because many phones can add the VLAN tag for you. Many IP phones also set the DSCP bits which you can use to prioritize your VOIP traffic as well. However, the VLAN is NOT going to magically make it all work well. Remember, your phones are connected to a switched network, not a shared piece of copper (unless it's the passthrough port. I've had no problems with that) so problems are generally not introduced at the copper level Where the sharing comes in is your internet feed. This is why QoS is the most important part of running VOIP and is the hardest to get right.
VOIP issues get significantly worse the smaller the bandwidth you have available. Why? because several users want to download some files at the same time, and if VOIP traffic doesn't get enough bandwidth or if the packets start getting delayed you get choppy audio. However, most phones can cope with 120ms ping which seems very high, but they have jitter buffers in them that smooths the voice and you don't really notice. So my advice is to ensure you have a good router that can do QoS. 10Mbit/s will do a small office with 10 phones and provide basic internet browsing and the odd download just fine.
And then have a read of Toastman's comments on how QoS works (google it). He's been a big contributor to the excellent tomato router replacement software. And even if you don't use tomato, he gives a very good explanation of how QoS works and how you can make all this work for you. I used Mikrotik gear myself which has good QoS built in. Cisco gear can also do it, but it's more expensive. At home I used tomato and that worked very very well also.
Hope that helps.