I've always focused on making simple content sites/forums, but I want to start getting into some serious business and therefore need something quite complex to be programmed. Once I find an appropriate programmer, I'll obviously need to express to them my intentions for the project. Does anyone have any tips for this? Is there a recommended format to write out a plan? Anything I should read up on? Thanks.
Hi. You're definitely asking this question at the right time: before you start the project. There are many formal and informal ways that business folks and programmers can communicate, and you're right to think that the more complex the project, the more formal and structured the communication should be. Programmers typically do not understand business goals and business processes particularly well, though there certainly are exceptions. For a successful result, they have to be told what you want at a level of detail that's nearly unbelievable for anyone who hasn't participated in a complex software project. One of my favorite tools is called Use Case Analysis. Rather than try to describe it, let me give an example: Another thing you might consider is hiring a professional business analyst to review and refine your specification after you've written a first draft. A business analyst is someone who specializes in analyzing technical requirements and facilitating communications between business people and programmers. I happen to be one, having several decades of experience in the field. I could help to refine your processes and your spec, and I could help to ensure that the programmer(s) understand the requirements and produce what you're looking for. PM me if you'd like to know more.
It is not so much a plan as it is going from requirements to a technical design/ specification. As above a Business Analyst or Technical Analyst are two professionals that are specialists in this, a BA typically approaches it from the side of the business where as a TA is from the IT side and so will have lower business knowledge but greater IT. In large corporations, as I used to be a PM & BA in, then you would typically have both working on a project as there is a fair cross over between the two and so documents written in language that both understand well is possible. The very first key step is getting business requirements down accurately. A BA would typically do this using a table with each row numbered allowing them to mark out dependencies between requirements. When this is taken and converted into a technical document the TA can reference which business requirement it enables to deliver and therefore gives you a quick and easy cross reference the documents to ensure that all of them have been captured. The problem is that doing a Business Requirements Document (BRD) does require a reasonable amount of skill and experience as listing 200+ requirements it can be difficult to remember if you have covered off something or not etc so an easier route for true business people is to draw a flow diagram of how the application should work including all the key deliverables.
MuSCow requirements are a good way to understand the project that you're going to design. They're essentially: Musts - The system must be able to do this Shoulds - The system should be able to do it Coulds - The system could do this Wonts - The system won't do this Its a great way to plan out the capabilities of your program