WilliamsB

Firstly welcome!

I gather you are looking for "help with producing documents that are professional, but arn't overkill for this smallish project?" and what to know "where i should start and what tasks i should carry out. The managers want all my work thoroughly documented" and you  are intending "to firstly caprture all of the user's requirements and how they currently use of the system. secondly i intend on doing a thorough review of the system and note down its capabilities. Then finally compile a requirements vs capabilities report in order to see if the system can be deployed succesfully in this organisation, and if it can detail the changes in business process that will be required."

There is a fairly standard set of questions you need answers to in order to carry out this analysis of requirements and I recommend starting with "Why has this project been started?". You have said that "the brief of my project is to assess the suitibility of of the company's CRM system to support the business" because "The consensus within the company is that the software is awful and unreliable".

So the project has been started to assess suitability. How will the sponsors of this project assess suitability? What measures will they use? What target measure would need to be achieved in order for the product to be assessed as "suitable"? What about this consensus? Who says the software is awful and unreliable? Do these people/groups have a say in your project? If so, how do they know the software is awful? What are they assessing/measuring/observing/experiencing that is telling them that? What would have to be changed to stop it being awful? What measures would they assess to announce it is no longer awful? Same questions about unreliability?

Basically - you need the people who are the key decision makers in your project to agree what the objectives of the project are. What measures will they measure to assess if the project has been successful and what targets must the project hit to be considered successful? This is really important to get right as everything you do in the project should be geared at hitting these objectives. 

Define the scope of the impact of the project in terms of impacted processes, organisation units, locations, data, applications and technology (and any other dimensions that make sense). The scope answers the question of "how big does this solution have to be to achieve the objectives?".

Define the functional requirements that the project will have to deliver (whether this is a change to existing functionality or not - those decisions can be made in design).

Define the non-functional requirements (such as reliability!) that will also have to be delivered.

Both the functional and non-functional requirements should map to at least one objective that the project is achieving. They answer the question "What must be in place in order for the objectives to be achieved"?

Lower levels of analysis will depend on 

1. whether you intend to change processes or not - and so need process models

2. whether you intend to change data used or not - and so need data models

3. what the people in the project who are designing the solution to the functional and non-functional requirements you have defined need in order to be able to design solutions.

I would suggest drawing up the the first set of information (objectives, scope, functional and non-functional requirements) in to a single document and getting that signed off before progressing in to further detailed analysis.

There is an article on this site defining this structure a bit more - here. There is plenty more on this site as well...

I hope this is enough information to get you going!

Guy