A business requirements analysis should be the first step in understanding the scope of the project, and the type of product any stakeholders require. Depending on the size and complexity of the project, a requirements analysis can be fairly simple, or complicated enough to require an external business analyst to undertake it.

Pre-requisite: This is the first step in the product selection process, and does not depend on any work having been completed.  It may be supported by an existing project plan, or be part of a project conception/initiation phase.

Outcome: Documentation that describes the requirements of each end-user, in enough detail that the project team is able to make most project decisions based on the list.  This might include documented workflows or use-cases in larger more complex projects. 


1. Identify stakeholders

Compile a complete list of stakeholders, from end-users to senior management. 

2. Identify any existing products or solutions currently in place

Consult with all stakeholders to compile a list of existing solutions and products/ processes being used to meet the need of the stakeholders to complete the tasks in question.  For example, these might include one or more of the following: legacy systems, spreadsheets, sharepoint, email or paper-based solutions.

3. Document the findings

Using interviews, observation, surveys, email and telephone communication, focus groups etc, document the details of the workflows and outputs identified by the stakeholders as important in the task in question. Document the workflows in the existing systems if necessary.  Diagrams and use-cases can be useful tools.

Example of a workflow that shows how a school might manage student clinical placement records - see the ePortfolio Project

Process example

4. Confirm the findings

Compile the results and have the stakeholders confirm all documentation.  Make any required changes, until all stakeholders are satisfied with the conclusion.

5. Translate existing tasks into list of required functionality

An existing process can be translated into a list of functionality using a table such as below: 

Example: A process is identified whereby school administration staff are regularly bulk-emailing groups of students with similar email reminders/updates/documents, and recording sent emails and replies within a centrally accessible spreadsheet.  Documents returned by email are saved to a central file-share.   Each file has to be named according to a naming convention so that they can be easily found when needed.  The file-path of the file is added to the spreadsheet.  Each year a new spreadsheet is started.

task functionality

The identified problems with this process include inefficiency, human error, occasional failure to complete the records in the spreadsheet due to being distracted by other tasks, difficulty in tracking replies and in looking up historical records, and the potential for not meeting accreditation requirements. What is needed is a system that allows email communication with students from a central system.

Existing Process/Tasks Functionality needed to imrove process Additional functionality that would be useful
Many admin staff using school email alias within own email application to communicate Central system that specific people can use

List of recent actions/ completed tasks, and by who/when.

Email contacts within the email application, or individual student emails being added Course based list of students imported who can have associated attributes and objects List updated nightly or weekly
Similar emails being sent to groups of students with varying requirements, often including standard documents. Re-usable editable mail template.  Method of selecting which student should receive which email (select all/ individual select/ deselect) based on configurable attributes; selection of standard documents to add to emails using a checkbox or filter. Document versioning. Mail-merge functionality based on student attributes
Responses tracked in spreadsheet System that includes response tracking  
Documents saved to central file-share and renamed according to naming convention Save document to system and associate with the student.  Bulk export of all documents important. Ability to tag the document would be beneficial i.e. immunisation record, first aid cert etc. Can search using tags, student name, date etc.
Any reporting is manual Can show list of students who have not responded to specific emails etc Filters that allow for a range of different reports

The information in the table can be broken down into detailed functional requirements:

  • Course based list of enrolled students imported from source system - can have attributes and objects associated.

  • List is updated from the source system daily or weekly.

  • Mail templates can be saved, edited and re-used. 

  • Documents can be saved to system from email or local drive. 

  • Saved documents can be tagged with one or more tags.

  • Saved documents can be associated with individuals.

  • Saved documents can be associated with all students who share a particular attribute. 

  • Document versioning is automatic.

  • Student can be selected to receive particular email template based on configurable attributes i.e. does or doesn’t have a particular document associated.

  • Mail-merge functionality allows emails to be personalised.

  • Can create a collection of standard documents to add to emails using a checkbox or filter.

  • Response tracking – history of contact associated with student.

  • Can view all associated documents/attributes for any student.

  • Can report on list of students who have not responded to specific emails or do not have specific documents associated.

  • Can select document types for bulk export.

  • Can send bulk email using multiple templates and documents via mail merge function/ filters/checkboxes.

  • Can view a list of recent actions/ completed tasks, and by who/when.

  • Can search using tags, name, date etc

  • Broad reporting functionality

All requirements should be translated accordingly.


Vague terms should be avoided, and re-written where necessary.  For example “ease of use” is subjective. Describe what is meant by “ease of use”, such as “Course instructors can automatically send grades to the Blackboard Gradecentre without the use of csv export and import”. Or, “Students can drag and drop documents from their personal drives into the product interface”.

  • Specify file types rather than saying “accepts most file types”.

  • Specify platforms and browsers if device compatibility is important.

  • Carefully consider reporting requirements. 

  • Consult with stakeholders in this process and consider asking ITS to assist.

6. Group functionality into categories

Some examples are:

Operational Requirements: These might describe the task driven functions of the end-product. These are the bulk of the features that the product should have.

Communication requirements: The product may have requirements for communication i.e. email, live messaging, VOIP, live video etc.

Reporting requirements: Instructors or admin staff may need to be able to generate reports from the data in the system. 

Technical Requirements: see ITS technical specifications document.

7. Rate according to Mandatory, Desirable, Optional, Out of scope

Consult with stakeholders to rate each of the functionality requirements.  This can be done within a panel or steering committee environment to reach a clear consensus.

8. Finalise the functionality requirements document

After consultation and consensus, send a final copy of the requirements to the steering committee/stakeholders to confirm the list of requirements, and the ratings of each criteria.

Return to Evaluating Technologies page

Next Step: Technology Market scan