Requirements Gathering

​

Requirements indicate the needs of a successful product. Therefore, requirement gathering is often the first step in the development process. We separate the requirements into two categories: user and business.

​

User Requirements

To understand user and customer needs as well as how well the app is functioning, we released the beta version to conduct internal usability testing within the organisation. Thus, we obtained the first actual user feedback.

 

We started collecting UX data when users interact with the app.

 

Users perform several tasks we defined as the main features, which we assume to benefit business.

 

Some tasks can be easily performed. However, in some cases, multiple methods are available for users to attempt to accomplish a singular task.

 

We conducted interviews with participants who had accomplished all the tasks and queried keynotes of the app by asking questions, such as

 

• How would you approach the tasks given?

• What limitations or difficulties have you encountered during the trial that should be attended to?

• Where did you waste your time?​

• Then, we asked “Why?” to expand on their thoughts and feelings and elicit further data.

 

Moreover, we allowed users to explore the app further and in return, the users provided valuable feedback. We gathered quite a few responses from them for questions, such as

 

• Which features impressed users the most?

• Which features do users feel more interested in?

• Which features are used more frequently?

• What frustrated them while using the app?

• Any specific features users expect in the near future?

• Any opinions for UI flows which users have experienced?

• Any comments about UI placement?

• Any confusing wordings?

• Any bugs reported while they were using the app?

 

Issues always arise from usability testing.

After data gathering, we started grouping and organising the data, and some patterns were obvious:

 

• Most confusing aspects for users about the app

• The judgements of user experiences, which is often mentioned

• Reoccurring problems that are iterated through testing

 

We identified specific areas of improvement of the existing design.

Determining frequently used features assists us in understanding whether the app can retain active users.

Moreover, we noted some potential features that should be developed in the app during the trial.

 

These common insights from users assist in formulating a list of functional requirements.

​

Business Requirements

In our case, these requirements can be understood by conducting meetings with executive stakeholders.

These executives provide funding and support for developing the app, and have interest or concern in the organisation.

 

Through interviews with executive stakeholders, product owners can ask questions about their expectation, overall business goals, visions, and concerns of the development of the app. These questions define the purpose of the app, which is presented in the organisation and defines where the app stands in the marketplace. Thus, the purpose concludes and clarifies what the app is meant to accomplish.

 

Executive stakeholders usually summarise the latest vision of the product and identify new market opportunities from this vision, and then conduct further discussions with product owners on the business benefits that the product may bring. Some discussions are listed as follows:

 

• How will the app satisfy a revenue target?

• What is necessary to monetise the app?

• Anything unique of the app that makes it stand out from the market?

• Would the app strengthens the brand values and promote the brand?

 

Even though executive stakeholders have considerable influence on the direction of the product, product owners are still responsible for coordinating several issues during meetings:

 

Controversy:

It is common for executive stakeholders to be unaware of an idea or requirement that is different from customer insights. Stakeholders’ vision and customers’ requirements frequently do not align. In this case, product owners inform stakeholders of the actual user requirements and the current user experience, highlight areas of conflict and disagreement, and then, attempt to achieve consensus for balancing the perspectives of both users and stakeholders.

 

Capability:

Quite often, the stakeholders’ vision is so ambitious that its implementation may be improbable in practice. Product owners should also contemplate on how to balance marketing and capability of development.

 

Timeline:

The main focus for the meeting is to clarify the exact requirements that are expected to be dealt with and communicate the corresponding development timeline.

 

Development team is concerned about is that the time to finalise the releasable product may be insufficient.

 

Unrealistic expectation can often cause mismatch between goals and timelines. When controversy occurs about the schedule, such as limited developing time on compiling a wide scope of features, the apparent contradiction should be indicated. The product owners should attempt to reach the consensus with executive stakeholders to extend the timeline.

 

If urgent requirements emerge that are beneficial for business, product owners must negotiate with stakeholders for possible release into the first version at that particular instant to partially satisfy benefits and then publish the eventual product.