Requirement: The Source Of Software Development

The first time I heard Requirement was when I was doing a Software Testing Course after my graduation. I spent six months in a Software Testing Course understanding each module. This gave me confidence in understanding the customer point of view, requirement details, and user workflows. When I started my career at In Time Tec in February of  2013 as a Qualification Engineer, I was developing secure printing solutions for printers.

After a couple of years, I joined another team that was building a product for our company from scratch. For a service project, we had real customers interacting with a development team who put together requirements on what needs to be done. In product development, the team needs to work with a product owner to understand and explore the possible end-user scenarios and how the solution can meet the customer needs. One thing is common in both service and product development- thinking from a customer point of view allows us to build the software to solve problems for the customer. 

While we were struggling to visualize the end-user behavior and workflow, one thing that helped us in this journey was the product owner experience in the domain. Our Product Owner, Anthony Chen, had real experience in the domain for over a decade, allowing the team to quickly discover what was needed. If I look at the initial set of features that the team had developed, all were built on assumptions and the knowledge we had in the initial phase. After 1 year of team effort, the product reached the state where we can demonstrate it to the real customer. I still remember the day when the decision was supposed to be made to purchase our product, the whole team was awake at night crossing our fingers and we were in Skype call supporting our US team to demonstrate the application.

From that day on, the team has learned and experimented with so many things on requirement gathering. Initially, it was defined by the team and when the end-user started using the application, the user workflows and data they were using were different. So the customer started reporting it as an issue but for us, it was an expected behavior of the feature that we have built based on our knowledge. Accepting it as a bug in the system was difficult and we used to push back marking it as an enhancement. The story continued until a few of our team members visited the customer place and saw the real situation what end users were going through and that was the eye-opener for us as it exposed us to the real-world scenarios. 

The Next Challenge

When the Product Owner is defining the user story, it’s a simple paragraph that talks about the problem statement and the acceptance criteria, which is limited information for building the full-fledged feature. Initially, we followed the user story as is and built the feature. Later we realized the impact of a new feature on the existing feature set, scalability, reliability of the feature, UI design and more were missing. 

This situation made us explore different Requirement Gathering techniques:

1. Brainstorming with domain experts in the team
2. Questions and Answer sessions with a product owner
3. Prototype and UI mockups designing
4. Design review with technical expertise in the team

All the above techniques not only helped us to dig deep into the requirement scope but also to build a reliable feature. The assumptions we made and our limited understanding was clarified through these processes. Our team has created platforms like backlog refinement meeting, design review meeting, and brainstorming sessions. 

Functional and Non-Functional Requirements:

While we were following the requirement gathering techniques, we also discovered the need for differentiating the requirement into functional and non-functional requirements. 

1. Functional requirements were straight forward and we got them clarified easily with the product owner and customer before we finalized the requirement. Functional requirements mostly cover the functional workflow, the I/O data, UI, and intended behavior of the system.
2. Non-Functional requirements were a little difficult to gather as it covers the expected performance of the feature, scalability, and usability. At times we did not know the expected performance and we built the feature by choosing the best design which can help us to have better performance. 

Requirement gathering template:

We introduced a requirement gathering template that helps to capture and document more information about the requirement:

• The goal of the feature
• Background
• Acceptance criteria
• RTM which maps requirement and test cases
• Business critical use cases
• User interface and design
• Scope of the feature
• Impact on existing feature
• Assumptions
• Expected load on the feature
• Performance expectation

We created a global template in Confluence and the team used this template while gathering the requirements. This helped us to give a better solution for the problem. While we were creating requirement documents in Confluence, we also linked it with a design document of the particular feature that gave technical information about the implementation. To manage these documents in a better way we created Product Requirement Tree and started managing requirements and designs under that which looked somewhat like this:

• Feature

1. Requirement document
2. Design (High Level and Low Level)

Requirement/Functionality Verification:

In our project, the requirement verification is done in different phases:

1. After requirements were frozen, the qualification team used to write use cases and test cases and get it reviewed from the internal QA team and as well with the product owner to make sure the requirement is well understood. 
2. Once UI mockups were ready, the team used to get it reviewed with a product owner.
3. Sprint review was the platform that was created for demonstrating the feature to the team and product owner to get the feature set reviewed.
4. The final stage was the UAT testing where the customer will be doing the testing of the new features added and approving them before production.

Change Management:

At times we came across a situation where the change was requested by the customer on the existing feature that was considered as an enhancement. We created a simple template in a Confluence document with the details like the original feature, the change request, when it was requested, by whom it was requested. This helps us to trace back the changes we are making on any given feature and also helps to keep it documented as proof for when we have to answer for multiple people involved from the customer side for deciding the feature behavior. 

Here is the Diagram explaining the end-to-end process of requirement gathering to feature delivery:

Below 2 situations will give clarity on the advantages of following the proper requirement gathering process:

Before following process:

We were supposed to develop one of the features and this seemed easy to do when we looked at the high-level requirement. As the feature was in the priority list, we asked the experienced developer to finish it as soon as possible and we ended up implementing the feature in a hurry without following proper processes. The result was the feature being incapable of fulfilling the customer needs and became the major flaw area in our application. This not only killed many human hours to fix the issues later but also caused the trust issue with the customer.

After following process:

We were asked to build a feature that was significantly complex and was dealing with the core features in the application. When the requirement was defined by the product owner, the team took it on and started designing the feature. With time, the team has experienced that the feature is not as simple as it appeared in the beginning. Afterward, the team has called for a couple of brainstorming sessions to understand the scope, impact on the existing functionality, and the core problem of the feature which we were supposed to solve. Once the requirements were clear from both the development and qualification side, two mid-experienced engineers were able to design and implement the feature in just a couple of weeks delivering the top-notch quality. The feature not only fulfilled the need but also impressed the customer. This was an experience where we learned about the importance of requirement gathering.

Before estimating any feature and coming up with the deadline for the releases, looking at the detailed requirement and its scope of work helped us to fulfill the commitment on time with quality. This also brings confidence in team members and the customer who will be using the application. We are working towards each feature we add into the system, satisfying the customer needs and workflows, and reducing the number of change/enhancement requests coming from the customer.