📌 What are Functional Requirements
Functional requirements describe what a system should do.
They cover the core features and behaviour the system must deliver.
For example, a functional requirement for an online store could be the ability to add items to a shopping cart.
It is the part of the system users directly interact with.
These requirements often come from the clear needs of the business or end users.
They define the tasks the system must perform to be considered successful.
⚙️ What are Non Functional Requirements
Non functional requirements describe how the system should work.
They deal with qualities like speed, usability, scalability, security and reliability.
For instance, the online store cart must load in under two seconds, or payment must be processed securely.
They do not describe a specific feature, but rather how features should perform.
Stakeholders may not always articulate non functional requirements clearly, but they are vital.
Without them, the system might technically function but still fail user expectations.
🧑🤝🧑 Why People Skills are Critical
Functional and non functional requirements cannot be captured by templates alone.
They are gathered through conversations, workshops and active listening.
A process analyst must be approachable and easy to work with.
Stakeholders are more likely to share honest needs when they feel respected and heard.
Emotional intelligence helps uncover what people really mean when they describe their challenges.
Sometimes stakeholders cannot express technical needs but can explain frustrations.
The analyst translates those into proper requirements.
This people centric skill is often more valuable than technical expertise.
📝 How to Capture Requirements Effectively
Start with workshops and open conversations.
Use open ended questions to encourage fuller answers.
For example, instead of asking “Do you want reporting?”, ask “What information do you need to see each week?”.
Mirror back what stakeholders say to confirm understanding.
Take detailed notes, but do not hide behind documentation.
The goal is connection, not paperwork.
Documentation matters, but only after true understanding is reached.
Requirements should reflect real pain points and aspirations, not just guesses.
🔑 Putting Functional and Non Functional Requirements Together
Once gathered, functional and non functional requirements should be structured side by side.
Functional defines the features.
Non functional sets the quality bar for those features.
Together they create a complete picture of what success looks like.
For example, “The system must generate weekly sales reports (functional)” and “Reports must load in under 5 seconds (non functional)”.
Both are needed to avoid gaps.
One without the other risks delivering a system that fails.
🗣️ Working with Stakeholders to Finalise Requirements
Managing multiple stakeholders means handling different priorities.
IT may push for performance, while operations may want usability.
Leadership might demand reporting, while end users seek simplicity.
The analyst must balance all these needs diplomatically.
Regular check ins ensure everyone stays aligned.
A people focused approach allows conflicting voices to be heard.
This builds trust and ensures buy in from all sides.
🌱 The Bigger Picture
Functional and non functional requirements are more than checklists.
They are shaped through relationships, trust and listening.
People skills make the difference between incomplete documents and solutions that genuinely work.
Analysts who listen first and document later deliver outcomes that fit human reality.
At its heart, requirement gathering is not a technical task but a human one.
