From your
other post, it sounds like quite a big complex system, so you shouldn't pay too much attention to brief guidelines aimed at more simple websites. Custom development is a risky difficult process, difficult for both the client and the supplier, and the bigger and more complex the system, the more difficult the process is, so don't expect any part of it, including the brief, to be easy.
First off, a lot depends on the relationship between the client and supplier and what roles you both intend to take in this process:
1. Are you a business that is specifying your business requirements and you want your supplier to come up with a solution and be the solution provider? or
2. Are you a business that wants to specify the solution, and you just want the supplier to develop the solution you specify?
Taking the latter approach can sometimes be a stumbling block since if you specify in detail a solution, rather than a business requirement, without thinking about and specifying a business requirement you will never know whether any solution will meet your requirement, and it is then your responsibility if the solution doesn't meet your business requirements, even if the solution does meet your specification for the solution.
Taking the former approach, it is up to your supplier to create a detailed spec of what will be delivered, and you have to focus more on your requirements and amending and agreeing to the spec. The former approach is more often used by businesses wanting websites who are not IT solution providers themselves (most are not), and in a bid process, where you write what your requirements are in an "Invitation to Tender" document, and then suppliers will reply with their "Invitation to Tender Response", i.e. their tender/bid/offer (tender as in "a written offer to contract goods, services, solution at a specified cost or rate; a bid.")
To find out more about the difference between writing business requirements and solutions have a read of this
post. Sometimes you do have to mention parts of the solution as part of the requirement, e.g. if you have an existing system based on a particular ecommerce system and you want to continue to use this system in the new solution.
There are ways you and your supplier can make the whole process easier and less risky, if you can identify existing systems which can be part of the solution, e.g. an accounts system, an ecommerce system, that way your solution is a semi-bespoke solution rather than a fully bespoke solution, and you don't have to specify in as much detail the existing systems which have already been developed.
For large custom developed systems, not only should you be thinking about the requirements and the solution, but you should also be thinking about:
1. Getting a water-tight
client-supplier contract drawn up, and
2. What kind of
project methodology you want to use.
Different suppliers will have different preferences for software development project methodologies, my own preference is to use an iterative process with
early working prototypes where possible.
do i need to put every little detail into the brief
Whether it is you or your supplier doing this, be aware that quite often
"the devil is in the detail".
