The following notes are to assist you if your work placement does not provide their own instruction. Continue to do your own research and ask colleagues in the work place for advice.
Identify stakeholders
Most failed projects fail because they didn’t accurately gather the requirements.
Think of every group of people who will either use the system or have a role in its creation/maintenance.
This includes groups such as:
- Users – Members of the company who use the system
- Customers – Members of the public who use the system
- Regulators / legal entities – Any laws that affect the system
- Management – People who want statistics of how the system is used
- IT – People maintaining the system during its lifetime
Not all groups will be involved in every system.
Ask yourself what each group gets out of the system and / or what the system gets out of each group.
Data gathering techniques
| Method | Pros | Cons |
| User stories – “In my role of <role>, I want <goal> so that <reason> | Good for finding out what users want from a system. | Might not give enough details without further techniques. |
| Interviews | Good for exploring specific issues. | Time consuming. |
| Focus Groups | Good for examining multiple viewpoints. | Dominant personalities might derail discussions. |
| Observation | Good for seeing how a system is actually used. | Time consuming. |
| Documentation | Good for seeing how a system is meant to be used. | Actual usage may differ. |
Data analysis
Once you have gathered the data using a selection of techniques you need to analyse it to make an accurate picture of the user and business requirements for a system.
These requirements can be split into different categories.
- Functional requirement of what a system needs to do.
- Non-functional requirements that explain how a system is going to do it.
- Constraints such as how much can be spent on the new system or how many operations a system must perform in a time period.
This is where the accuracy of the gathered data becomes important. A mistake in a value in the requirements might leave a system unfit for purpose.
Data inaccuracies
- Omission – Information is missing
- Ambiguous – More than one interpretation of the information
- Inconsistent – Information changes in different gatherings
- Superfluous – Information not relevant to the project
- Incorrect – Information not accurate
- Duplicate – Information recorded multiple times in a single gathering
- Typo – Information accuracy can not be guaranteed
Functional vs non-functional requirements
Functional requirements
- Defines what a system should DO
- Defines the inputs, outputs and processes of the system
Non-functional requirements
- Defines how a system should WORK
- Often include constraints like budget, timescale of operating values
- Deals with the lifetime of the system. What is the capacity? How many users can / will use it? What is the bandwidth needed? What legal regulations affect it?
- Covers usability. How easy and intuitive is the system to use?
Example
Imaging a piece of room booking software. On the main page you have a calendar view showing what rooms are in use at a give time. These could even be a different colour when in use.
The functional requirement is to be able to see if a room is booked for a given time.
The non-functional requirements will make it easier to see this, such as a calendar view and different colours.
The functional requirement could have been met with a text list showing all the times rooms were booked. But that wouldn’t be as user friendly.
Data security
IT systems often store sensitive information. As part of this unit, you are going to need to bear this in mind while drawing up requirements or designing the system.
- Explain the importance of preserving security and confidentiality of the information.
- What legislations are involved with the data you gather or store? Keep in mind Data Protection Act of 2018, GDPR, Computer Misuse Act of 1990 etc.
