You will find many instance where users ask for real time in the requirements. Such requirements must always be check carefully for many reasons. This is because real time design is costly. How do you determine the need of real time? These are some standard queries you can ask before you embark on real time design.

Mission Critical

A common way to check for real time is the type of system you will be designing. Mission critical system like a car application will need real time design because your car requires instant feedback on the road. Another such system is airline control tower where you will be managing incoming and outgoing aircrafts. Such systems will need a real time infrastructure compared to standard applications. The design is usually highly availability, resilient and fault tolerance.

I want Real Time for Free

The challenges come when your users want real time data refresh in your system. The correct term that you need to use is “near real time”. This means you can achieve data refresh with a tolerance lag of five minutes or more. Another term is “live streaming” where you may design a dedicated pipeline for data refresh. Such design will incur higher cost and must be segregated for your premier customers. In another words, real time requirements should be segmented properly in your product offerings with a cost.

Real time requirements will impact your design and cost greatly. Mission critical systems are real time from backbone to front end. For other applications, real time could be a specific feature. You must always take note that the cost of implementation for real time is always higher than standard requirements. Thus, you must consider these additional cost when you market your products.

Stakeholder analysis is a step you must undertake to understand and evaluate the stakeholders for your project. This step is often neglected, skipped or taken for granted. It is easy to overlook because humans tends to make assumptions for stakeholders. I will loosely classify stakeholders into these categories. You must take note to manage and include these stakeholders from the start of project.

The Good, The Bad and The Ugly

Stakeholders can be divided into the good, the bad and the ugly! You need to focus on gathering these good stakeholders who can play the roles well.

• Sponsor to support and orchestra your project vision
• Functional roles to implement your project objectives
• Influencer to motivate and champion your project goals

Bad and ugly stakeholders are attracted to all projects. This is inevitable and steps must be taken to understand and mitigate their influence. Sometimes, decision must be made to swap these negative stakeholders out.

Required Representation

In every project, it is not surprising to see the wrong stakeholder leading the project. Halfway through the project, you realise a representative is missing for a function group. You may even notice that this repeats into the next project. Thus, it is important to start the project with the required stakeholders with a minimum of 2 representatives. Why? This is because all humans have downtime and you need backup to ensure continuity.

Stakeholder analysis is an essential steps for project success. Identifying positive stakeholders helps to drive your project goals. You must learn to analyse and downplay bad and ugly stakeholders. Lastly, you need to ensure at least 2 representation of stakeholders in your projects.

In the world of limited resource and time, we need to evaluate and prioritise when to implement user requirements. There should be clear guidelines on how requirements are prioritise. These are some of a ballpark guideline to give you a sanity check if the requirements are worthy to be implemented.

Requirements Criteria

There is actually a quick way to ballpark the priority of your requirements. One key method is to use ROI (Return On Investment) model. This is usually used together with data statistics to understand the impact and expected returns. Agile based methodology will view the priority for items that maximise value or benefits to the product.

Setup a Checklist

Before you go in depth to design solution to all the requirements that flow your way, it is cost effective to do a sanity check with a simple checklist.

• Impact of Requirements e.g. high volume vs low occurrence
• Is there workaround if this is low occurrences?
• What is the ROI? Is it a positive gain of value and benefits?

It is now a norm to evaluate requirements to maximise the value and benefits. This is usually overlooked due to external factors such as management pressure and voice of customers. You can use a simple checklist to determine the viability of implementing these requirements.

Have you ever encounter vague requirements? What are usually the issues? I will have a standard strategy to handle vague requirements. This is a quick and systematic approach to manage such requirements.

1. Identify the stakeholders for the requirements.
2. Get sample data for the requirements. This can be existing data or copies of excel records.
3. Consolidate user communications and understand interactions of users and the requirements and the sample data.
4. Agile or prototype to elicit sample data or to clarify the requirements.
5. Separate clarity and vague once you identify each part of the requirements.
6. You should be able to proceed on the clear requirements and put the vague part into the backlog.
7. Iterate the approach from Step 1.

Requirement gathering is never straightforward. Those documented are usually clear requirement while the vague part exists somewhere out there. It takes a lot of practice to clarify vague requirements. You can consider to approach it in a systematic and agile manner.