Functional Requirements
Describing your functional requirements can be a very tricky issue. As outlined above you need to strike the right balance between just describing what you do at the moment and coming up with "blue sky" ideas that aren't achievable.
It is tempting to get straight into the detail of what you think the ideal system should do but in order to get the right approach to this you really need to stop thinking about an IT system and start thinking in terms of business activities. Business activities can be viewed as a pyramid with Strategy at the top - Why you are doing something; Tactics in the middle - What you are doing and Operations at the bottom - How you are doing it.
It is always worth starting by reviewing the strategy. If you can't answer the question "Why do you want to do this?" the project is already in trouble. JISC infoNet recommends taking a customer focused approach to answering this question. Consider "How does this help our relationship with the customer?" In most cases the customer will be the student. If you either can't identify the customer or can't see how your project fits into the customer relationship maybe you need to rethink your objectives.
Next you can turn your attention to what it is that you need to do. Again you should start by looking at this in broad and simple terms. If you find yourself already embroiled in a huge amount of detail you are pitching your thoughts at the wrong level. There are three components to any business process: Input, Transformation and Output.
Having answered the question "Why are you doing this?" you need to consider "What do you need the process to achieve?" i.e. what are the outputs? It all sounds straightforward but you may find, particularly where you are working with end users, that you ask either of these questions and the answer they give is to explain exactly what they do at the moment. They can easily confuse "what is" and "what should be". It is often useful to involve an outsider in these discussions to bring in greater objectivity.
Eventually you will get down to the detail of what data you need to collect and what kind of transformations you need to undertake to achieve the required outputs. You will probably need to undertake some form of process mapping and process analysis to aid you in setting out the requirements. We cover these topics in greater detail in the Process Review infoKit.
Having mapped your existing processes you may wish to apply some analytical tools to help you identify issues and problems that could be rectified when you implement a new system. It should be stressed that the sort of analysis we are talking about here is process analysis not IT system design but it can help you to identify the sorts of facilities you want to look for in a new system. We would advise leaving detailed process redesign until you have purchased your IT system and are working on implementation otherwise you could waste a lot of effort. Understanding the issues with your current processes however can only help you at this stage.
