The production and management of a project's Requirements is often the most visible contribution made by Business Analysts.
These range from strategic level requirements that form the basis of a feasibility study, to a detailed requirements definition driving the final design/build phase.
While every project needs a set of requirements to work from, IT systems development demands the greatest care and effort.
If we are building a road bridge, for example, there will be a predictable volume and type of traffic.
After the various geological and environmental factors are taken into account, materials and construction methods should follow logically on from the architect's design.
However this is very unlike many computer systems, where what is needed and what is attainable and the best way of doing it are often disputed, often long after the project gets underway.
For this reason defining Requirements for an IT system deserves special attention.
We must be clear on the scope and objectives of the project before attempting to gather and document requirements.
Failure to pin this down can result in wasted time and effort as requirements are produced for a part of the project which has no hope of progressing.Just as your feasibility study should not begin before your Terms of Reference are agreed, so you should not start to produce Requirements without a suitable Project Initiation process.
Following on from the preliminary investigation we should now have a good approximation of what the finished product will be and can look in much closer detail to produce a working set of requirements.
The Requirements Catalogue is no longer just a 'wish list': what you are doing will form the basis for the project going forward.
Now is the time to fully engage available Domain and Subject Matter experts.
Requirements can be categorized as:-It is well to check that your requirements are sound before submitting them for review.
Enlist the help of business and technical experts to check through your draft before you engage with the wider organization.
The review process should:
After your specialists have reviewed and re-drafted the Requirements Document it is ready to be submitted to your key stakeholders.
Now is the time when everybody wants their own area prioritized to top the development schedule.
This becomes more contentious with iterative development models where projects are delivered in phases.
You may find your negotiation skills severely tested but you need to focus on what the project Must Have as opposed to what would be Nice to Have or that which is the Not Really Needed.
Take this opportunity to double check the feasibility and fit of your requirements.
Be aware of politically motivated, entrenched positions in your discussions with stakeholders.
You are now ready to submit your final draft for sign off and publication.
As with all documentation you should provide context and clarity by describing the background and the technologies used.
Include a Glossary for those who may be unfamiliar with any technical terms or abbreviations.
Assumptions or constraints should be noted and any helpful modelling diagrams included.
The Requirements Catalogue will follow the accepted in-house format and typically contains a unique id, description, prioritization etc.
Always identify any dependancies or associated system or functional requirements.
This document may also include acceptance criteria.
After publication, requirements need to be properly managed.
Even the most thoroughly researched requirements may change during the life of a project, as external factors, and technical or operational imperatives change.
The requirements definition now becomes part of the project's Change Control process. This ensures that ownership is conferred and that no change is sanctioned without proper Impact Analysis and documentation.
The importance of agreeing sign off, and Version Control, procedures cannot be overstated.
The specification of requirements is fundamental to any project.
IT systems generally need the greatest care and most effort.
Compiling the requirements for a project is an iterative process which can span high level strategic drivers down to the low level system specifications.
There are several widely accepted techniques used to elicit requirements.
A formal review process should be used to validate and prioritize the list of requirements.
When they have been agreed and signed off, the published requirements need to be managed as part of a robust Change Control mechanism.