
When is the technique applicable
If gathering requirements for an IT system then inevitably some of the requirements will mean storing data or doing something with data. A logical data model can be a technique for gathering these. It is very useful because it enables a diagram to be drawn up which can be discussed to improve the understanding of the data relationships. A table also known as a data dictionary can then be used to gather further information about the data itself.
This technique is the most useful for gathering data requirements in the following circumstances:
- The system is completely new
- The stakeholders are using lots of complex terms and specialised business terms making it difficult to understand what they are talking about
- The stakeholders are interchangeably using different terms that could mean the same thing
- There aren’t clear examples available to show the data inputs or outputs
- It isn’t clear which of the data mentioned are entities or attributes or how they relate to each other
What is the expected outcome/benefit of using it?
- Enables data requirements to be grouped together in a logical structure and an understanding of how the data relates to each other.
- Ensures agreement of consistent terminology
How to use/apply it
A class or entity is a group of data with connected characteristics. The different characteristics are known as attributes.
Each time a different data requirement is mentioned write it on a white board or flip chart. Check it hasn’t been previously included and establish the relationship between the other data requirements written. If it has a one to one relationship with a previous data requirement group it together as it belongs in one entity otherwise separate it out and establish whether the relationship is one to many or many to many etc.
Worked examples of when/how it has been used.
See diagram below. This is an example using a class diagram and using syntax from UML. There are similar techniques with slightly different syntaxes.
The below is an example from the article drilling down solution requirements into more detail. In it was a requirement to allow an employee to book holiday through the companies intranet. The entities identified were employee and holiday. This showed the relationship as an employee could book zero to many holidays but a holiday was applicable to just one employee.
Discussing the relationships between the entities could uncover further requirements about the data. For example the above would mean that there is only one employee record and that the number of days entitled would have to be overridden each year. Another problem with the above relationship is that it means that an employee could only book holiday in that current year so could not book for the next year. If this wasn’t the case then an additional entity would need to be added to keep an historical record each year. After understanding more about what is needed from the data the diagram may be changed to the following.
Holiday entitlement has now been added to keep a record of holiday entitlement each year and to allow future years to be booked.
In addition to the diagram a table is required to understand more detail about the data requirements.
Employee
Description: Employees at the company who are permanent or FTC contractors.
Attribute Name | Description | ||
Employee name | The name of the employee | Mandatory / Optional | Mandatory |
Type | Alpha numeric | ||
Length | 30 | ||
Format | |||
Validation | |||
Default | |||
Example | Bob Hoskins | ||
Team | The team the employee works in | Mandatory / Optional | Mandatory |
Type | Alpha numeric | ||
Length | 30 | ||
Format | |||
Validation | |||
Default | |||
Example | Change team | ||
Date started company | The date the employee started at the company | Mandatory / Optional | Mandatory |
Type | Date | ||
Length | 10 | ||
Format | Dd/mm/yyyy | ||
Validation | |||
Default | |||
Example | 23/04/2001 | ||
Date left company | The date the employee left the company | Mandatory / Optional | Optional |
Type | Date | ||
Length | 10 | ||
Format | Dd/mm/yyyy | ||
Validation | |||
Default | |||
Example | 01/10/2007 |
Holiday entitlement
Description: The holiday entitlement of each employee
Attribute Name | Description | ||
Holiday year | The year of the holiday entitlement for each employee who has started at the company and not left. | Mandatory / Optional | Mandatory |
Type | Alpha numeric | ||
Length | 4 | ||
Format | Yyyy | ||
Validation | |||
Default | |||
Example | 2017 | ||
No of days entitled | The number of days an employee is entitled to in the current year. This is a calculated field depending upon the number of years the employee has been with the company. | Mandatory / Optional | Mandatory |
Type | Alpha numeric | ||
Length | 30 | ||
Format | |||
Validation | Less than 5 years – 20 days
5-10 years – 25 days Greater than 10 years – 30 days |
||
Default | 20 days | ||
Example | 20 days | ||
No of days left | The number of days the employee has left for a holiday year. This is a calculated field taking into account the number of holidays approved in a holiday year. | Mandatory / Optional | Mandatory |
Type | Alpha numeric | ||
Length | 30 | ||
Format | |||
Validation | No of days entitled – holiday approved in that year | ||
Default | |||
Example | 10 |
Holiday
Description: The number of holidays booked per employee
Attribute Name | Description | ||
Date from | The date from which the employee wishes to book holiday. | Mandatory / Optional | Mandatory |
Type | Date | ||
Length | 10 | ||
Format | Dd/mm/yyyy | ||
Validation | |||
Default | |||
Example | 12/09/17 | ||
Date to | The date the employee wishes to book holiday to. | Mandatory / Optional | Mandatory |
Type | Date | ||
Length | 10 | ||
Format | Dd/mm/yyyy | ||
Validation | |||
Default | |||
Example | 17/09/17 | ||
Number of days | To be automatically calculated to store the number of days being booked as a result. | Mandatory / Optional | Mandatory |
Type | Alpha numeric | ||
Length | 30 | ||
Format | |||
Validation | No of working days between date from and date to | ||
Default | |||
Example | 10 | ||
Manager name | The names of the manager approving the holiday | Mandatory / Optional | Mandatory |
Type | Alpha numeric | ||
Length | 30 | ||
Format | |||
Validation | |||
Default | |||
Example | Bob Hope | ||
Team | The name of the team the manager is from. | Mandatory / Optional | Mandatory |
Type | Alpha numeric | ||
Length | 30 | ||
Format | |||
Validation | |||
Default | |||
Example | |||
Date approved | The date the holiday was approved by the manager | Mandatory / Optional | Mandatory |
Type | Date | ||
Length | 10 | ||
Format | Dd/mm/yyyy | ||
Validation | |||
Default | |||
Example | 10/09/17 |
Using this approach is a technique for understanding the data requirements.
Thoughts? Questions? Please share in the comments.
If you have found this article useful then you might like my book – The Business Analysis Handbook – Techniques and Questions for better Business Outcomes. The book is available from www.koganpage.com and all major print and e-book retailers.