How to Elicit 100% of the UI Requirements | Free Template

“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

Composite data elements

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

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”.

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 CS@AdaptiveUS.com.