Skip to content
Share this post

How to elicit 100% of the UI requirements

Become a Business Analyst

Speak to a Learning Advisor to learn more about how our bootcamps and courses can help you become a Business Analyst.

In many of my training sessions, many participants ask me a very simple question, “Is there a way that we can ensure complete capturing of requirements from a user interface perspective?”

“100% complete requirement?” Anything 100% only exists in theory.

“95%?” Of course, possible. I have successfully extended the traditional data dictionary to achieve near 100% complete user interface requirements along with the wireframe.

Let’s discuss what is covered in the common data dictionary.

A data dictionary provides standard definitions of primitive data elements, their meanings, allowable values, how those elements combine into composite data elements. Used to manage data within a solution’s context, often used along with Entity-Relationship diagrams.

Primitive data elements

 

Name

A unique name for the data elements.

Example: Prefix, First Name, Middle Name, Last Name, Suffix

Aliases

Alternate names for the data element.

 

Values

List of acceptable values.

Prefix: Mr., Ms., Dr., Mrs.

Meanings

If abbreviated, include an explanation.

 

Description

Definition of the data element in the context of the solution.

 

Composite data elements

Composite data is assembled from primitive data elements, e.g. An intelligent ID to describe items.

Sequence

Show primitive data elements in a specific order.

Name: First Name + Middle Name + Last Name

Repetition

This shows that one or more primitive data elements occur multiple times in a composite element.

 

Optional element

May or may not occur in a particular instance of a data element.

Middle name

Strengths of the data dictionary are:

  • Ensures stakeholders' agreement on the format and content of relevant information.

  • Ensures consistent usage of data elements.

Limitations of the data dictionary are:

  • Becomes obsolete unless maintained.

Now, let me describe what we cover in the extended data dictionary.

Extended data dictionary marries data dictionary and prototype/wireframe

 

In an Extended data dictionary what we do is explain each and every user interface element in a detailed manner. The advantage of an extended data dictionary is that it does not leave anything to the developer’s imagination. In many parts of the world, developers may not have much business knowledge. It's better that the business analyst or requirements analyst provides complete details about the controls.

Here is our Excel prototype of one of our modules “Defect management system”.

Cover Page - Extended Data Dic template 3D5-min.webp

Control Name

Explanation

Example

Type of element

Different types of elements we use in applications.

Can be a text box, a calendar, a look-up value, a radio button, etc.

Data type

Different types of data that the UI element intends to capture

Can be a number, text, or a dropdown.  

Format

Any specific format expected for the UI element

For example, ID is a positive number. The date format that generally we recommend is DD-MON-YY. Why? Because this avoids the confusion between the British date format and the American date format.

Size

Size of the UI element to be stored in the database

We provide the size of the field because this is something that the business analyst or requirements analyst can determine how long or how big do you want it to be. For example, the name field can be up to 100 characters.

Mandatory

Whether the UI element is mandatory

Dates are not mandatory. This is because, in the beginning, you may not have an idea about dates. However, status is mandatory.

Identifying Key

Identify key is the unique value that identifies instances of the object

Similarly, an ID is mandatory and ID is the identifying key. This field is used for identifying the record so here the ID field is used for identifying the record.

Min Value

Allowable minimum value.

Allowable minimum value.

Max Value

Allowable maximum value.

Allowable maximum value.

Editable

Then whether it is editable or not.

If you see here, ID is not editable. Similarly, the name is not editable after you submit it. The plan start date is not editable after submitting but the resource name is editable. That means you can assign tasks to different people over time. Status is editable because the status needs to be changed by the project manager.

H Align

Horizontal alignment of the UI element

Then we also talked about horizontal alignment which means do you want the data to be left-aligned or Center aligned or right aligned depending on what is your stakeholder preferences. I have observed that in certain countries a certain preference is provided. Like in the US, we tend to number align numbers to the right whereas if you go to middle eastern countries many of them prefer numbers to be Center aligned.

Validations / Business rules

Validations applicable to a particular field.

Say for example the planned start date must be less than or equal to the planned end date. It cannot be more than the planned end date and at the same time, it must be within the project start and end date. It cannot go out of the project dates. The same thing applies to the planned end date.

Lookup Ordering

Desired order for lookup

I would like the statuses to be ordered in an ascending manner and that's what I mentioning here.

Default Value

Default value for the UI element

For example, the default value for ID can be last I D plus 1 so that means if I have created a schedule ID which is ten thousand and five, the next ID should be ten thousand and six.

If you observe by making things defaulted to a particular value makes the application lot more usable otherwise the user has to fill in a lot of details so you have to put your mind behind understanding what fields can default automatically and in fact if you have filters on the page, I would also suggest that you default those filters so that the data to be retrieved reduces and this improves application for performance quite a bit.

Look Up Seed Values

Seeded values for lookups

Then look up seed values which I suppose is a look-up what are the seed values that I would like the developer to built-in so this is what I have given.

Expected data values

Likely growth of the lookup

Lookups can be classified as small (Up to 5), Medium (5 to 20), and Large (More than 20)

Next control

Next control the cursor should move

Next control it's basically saying after I complete this where do I go? After I come to the source from the resource, I go to the save field maybe this is what I should see.

Linked to any other field

The value of the current UI element is dependent on another field.

A state user element will be determined by the Country field.

Field Behavior

Any specific behavior to be exhibited by the UI element.

For example, providing a tooltip for the UI element.

Legacy Table

Table connected to another system from where data may be interfaced

In one system, the system table to capture customers may be called "Candidates" whereas in other systems it may be called "Customers". In case you are connecting to a legacy system or pulling data from a legacy system you could use three additional columns which is mainly legacy table and column.

This is something required if you're doing data migration or you are doing an interface to another system.

Column

Column connected to another system from where data may be interfaced

Customers.Name to Participants.Name

Transfer Rule

Any rule to be followed while transferring data

One application may have 2 fields for name such as "First name" and "Last name" whereas the other system has only one column "Name". So, the system should concatenate First Name and Last Name to Name.

 

Then what is the type of control you expected to be? Is it a text, is it a calendar, or is it a look-up?

Then we define the data type which is the kind of data that we expect. Whether it is a number, text, or from a  dropdown.

Then coming to format, do you expect a specific format? For example, ID is a positive number. The date format that generally we recommend is DD-MON-YY. Why? Because this avoids the confusion between the British date format and the American date format.

We provide the size of the field because this is something that the business analyst or requirements analyst can determine how long or how big do you want it to be. For example, the name field can be up to 50.

Then is it mandatory? For example, you can see here that the dates are not mandatory. This is because, in the beginning, you may not have an idea about dates. However, status is mandatory. Similarly, an ID is mandatory, and an ID is an identifying key. This field is used for identifying the record so here the ID field is used for identifying the record.

What is the on-screen size? In the database, you could store actually a much bigger data but, on the screen, you may not be able to show everything. That is why we limit the field length, and you could actually use a pop-up to describe all the details because otherwise, the field will look very odd on-screen height indicates how big do you want it to be. For example, here I could have an on-screen height of two or three is saying that the description field is a slightly bigger field.

Then whether it is editable or not. If you see here, ID is not editable. Similarly, the name is not editable after you submit it. The plan start date is not editable after submitting but the resource name is editable. That means you can assign tasks to different people over time. Status is editable because the status needs to be changed by the project manager.

Then we also talked about horizontal alignment which means whether you want the data to be left-aligned or center-aligned or right-aligned depending on what is the stakeholder preferences. I have observed that in certain countries a certain preference is provided. Like in the US, we tend to align numbers to the right whereas if you go to middle eastern countries many of them prefer numbers to be center aligned.

Then we come to the validations applicable to a particular field. Say for example the planned start date must be less than or equal to the planned end date. It cannot be more than the planned end date and at the same time, it must be within the project start and end date. It cannot go out of the project dates. The same thing applies to the planned end date. You can add more resources as you like.

Now coming to lookups, say, for example, here we used a lookup or a user-defined value for status and I would like the statuses to be ordered in an ascending manner and that's what I am mentioning here.

The default value is something that I would strongly suggest all the requirements analysts take note of. For example, the default value for ID can be last ID plus 1 so that means if I have created a schedule ID which is ten thousand and five, the next ID should be ten thousand and six.

Name of course I cannot default because that is something that the user has to provide but with a planned start date, I could default it to today's date, and planned end date I could default it to today's date plus seven days. I could default it to resource who has logged in and the status can be open.

If you observe by making things defaulted to a particular value makes the application lot more usable otherwise the user has to fill in a lot of details so you have to put your mind behind understanding what fields can default automatically and in fact if you have filters on the page, I would also suggest that you default those filters so that the data to be retrieved reduces and this improves application for performance quite a bit.

Then look up seed values which is a look-up what are the seed values that I would like the developer to built-in, so this is what I have given.

Next control it's basically saying after I complete this where do I go? After I come to the source from the resource, I go to the save field maybe this is what I should see.

There are three fields that are not generally used much but if you are using a button like the same you can say on the click it should say, for example, I could have another column here let me hard so which is my same button so this is basically a button and rest all mostly will not apply all that and here I could say on click Save data.

In case you are connecting to a legacy system or pulling data from a legacy system you could use three additional columns which is mainly legacy table and column. This is something required if you're doing data migration, or you are doing an interface to another system.

The advantage is if we want some more attributes, we can always put them down. I already have put about twenty attributes but sometimes people need more than this as well. For example, one of my clients added a column “Likely value for look-up”. That means, suppose a lookup is status, how many maximum statuses you are likely to have? Maybe about ten. you

But suppose it's a look-up on employee name or employee ID, then you can have a look-up which will be very big maybe 5000, something which is unusable. In that case, you really must find a way to implement it in a different way. Instead of a lookup, maybe you will implement it as AJAX control, or a smart look-up.

I hope you found something very useful, and I would strongly recommend all my requirements and business analyst friends to use such a template. I have seen extremely good results by following this template because it does not leave anything to a developer's interpretation and hence the way the stakeholder wants you can get it correct.

Sometimes I get the question, “LN, will the stakeholders really prepare this?” “No. It is you who should prepare this and get it reviewed by the stakeholders.”

When I have a doubt on an aspect, I would mark this in yellow which means I want the stakeholder to look at these rules because maybe there are more than these rules that I know. So, I would like them to take a look at things that I am confident I can just put it. Stakeholders can have a look but other than that I don't see a need for the stakeholders to really make this template. This template must be made by the requirements or business analyst but should be reviewed by the stakeholders for acceptance.

If you would love to have this template, pls. write to Info@AdaptiveUS.com.

Cover Page - Extended Data Dic template 3D5-min.webp

 

  Previous Next  

Related Posts

Write Comment

Write Comment