4.5.3
Intuition Is note ka 80/20Koi bhi code likhne se pehle, tumhe do sawaalon ka jawab dena hoga: WHAT must the system do? (functional) aur HOW WELL must it do it? (non-functional). Baaki sab — user stories, acceptance criteria — bas ek disciplined tarika hai un dono jawabon ko record karne, slice karne, aur test karne ka , taaki koi galat cheez na bana le.
Socho ek builder jo bricks lagana shuru kar deta hai bina yeh puche ki kaisi building chahiye ya kiske liye . Code bhi waisa hi hai: sabse expensive bug hai bilkul sahi tarike se galat cheez banana . Ek requirement ek written agreement hota hai ki "done" ka matlab kya hai taaki customer ki mental picture aur developer ki mental picture overlap kare.
Ek galat assumption ko fix karne ki cost roughly exponentially badhti hai jitna late pakdi jaye:
Cost ( t ) ≈ C 0 ⋅ k t , k > 1
jahaan t C 0 C 0 k 4 WHY this matters: requirements likhna is curve ke sabse steep hisse ke against sasta leverage hai.
Definition Functional requirement (FR)Ek statement ki ==system kya karna chahiye == — ek specific behaviour, input→output, ya feature.
Test: "Kya main isse 'The system shall ...' ke form mein phrase kar sakta hoon?"
Definition Non-functional requirement (NFR)Ek statement ki system kisi quality ko kitni achhi tarah perform kare — speed, security, availability, usability, etc. par constraint. Isse aksar quality attributes ya "the -ilities" bhi kehte hain.
Test: "Kya isko number/unit se measure kiya ja sakta hai, koi feature nahi?"
Intuition Verb-vs-adverb testFunctional = verb ("the system uploads a file").
Non-functional = adverb ("...quickly , securely , reliably "). Ek hi verb kai adverbs le sakta hai.
Aspect
Functional
Non-functional
Answers
WHAT it does
HOW WELL
Example
"User can reset password"
"Reset email arrives in < 5 s, 99% of time"
Failure looks like
Feature missing
Feature present but too slow/insecure
Verified by
feature test
benchmark / load / pen-test
Worked example Ek requirement ko FR vs NFR mein sort karnaRequirement: "Customers products search kar sakte hain, aur results 2 seconds ke andar aate hain chahe 10,000 concurrent users hon."
FR: "Customer products search kar sakta hai." → Kyun? Yeh ek behaviour hai (ek verb).NFR: "results within 2 s under 10,000 concurrent users." → Kyun? Yeh us behaviour par ek measurable quality constraint hai (performance + scalability).
"FURPS+" NFRs ka menu
F unctionality, U sability, R eliability, P erformance, S upportability + (security, scalability, legal). Jab F likh lo, pucho: "URPS+ ka kya?"
Ek feature ka chhota, user-centred description is form mein:
As a ⟨ r o l e ⟩ , I want ⟨ g o a l ⟩ , so that ⟨ b e n e f i t ⟩ . who chahta hai, what chahte hain, aur why (benefit cost ko justify karta hai).
Intuition WHY yeh exact template
As a <role>real user ka naam lene par majboor karta hai, "the system" nahi — aise features banana band ho jaata hai jo koi use nahi karta.I want <goal>capability rakha hai, implementation nahi. (Goal: "cheap flight dhundna", nahi ki "SQL index add karna".)so that <benefit>value test hai: agar benefit nahi bhar sakte, toh story shayad worthless hai. Prioritisation ke liye yeh tumhara 80/20 filter hai.
INVEST hoti hai
I ndependent, N egotiable, V aluable, E stimable, S mall, T estable.
Worked example Ek vague request ko story mein convert karnaStakeholder: "Humhe shopping cart stuff chahiye."
Story: As a shopper, I want to remove an item from my cart, so that I don't accidentally buy things I changed my mind about.
Yeh step kyun? Benefit ("accidently nahi kharidna") batata hai ki removal easy aur visible honi chahiye, jo baad mein UI aur acceptance criteria shape karta hai.
Definition Acceptance criteria (AC)Woh specific, pass/fail conditions jo ek story ko accept hone ke liye satisfy karni chahiye. Yeh ek fuzzy story ko kuch aisa banata hai jo ek tester (ya automated test) definitively check kar sake.
Intuition WHY stories ko AC chahiyeEk story what & why kehti hai; yeh deliberately negotiable hai aur test karne ke liye precise nahi hai. AC contract ki fine print hai — yeh ambiguity hatata hai ("works" → "given an empty cart, removing... shows the cart total = £0").
Ek popular HOW-format hai Given-When-Then (Gherkin) :
context/state Given action When expected outcome Then
Worked example "remove item" story ke liye AC likhna
Given ek cart mein 2 items hain, When main ek remove karta hoon, Then cart mein 1 item dikhti hai aur total update hota hai.
Kyun? Happy path test karta hai aur yeh bhi ki total recompute hota hai (ek hidden requirement!).Given ek cart mein 1 item hai, When main use remove karta hoon, Then cart "empty cart" message dikhata hai.
Kyun? Edge case test karta hai — boundary conditions wahan hoti hain jahan bugs chhupte hain.Given ek removed item, When main cart dekhta hoon, Then refresh ke baad woh present nahi hai.
Kyun? Ek possible bug forecast karta hai: removal sirf UI mein hua lekin persist nahi hua.
Worked example AC jo ek NFR bhi encode karta haiStory: As a user I want search results.
AC: Given 10,000 products, When main "shoe" search karta hoon, Then results ≤ 2 seconds mein aate hain 95th-percentile request ke liye.
Kyun? Number dekho — AC woh jagah hai jahan non-functional requirements ko ek measurable threshold milta hai .
Common mistake "Performance sirf feature ka hissa hai, ise non-functional kehne ki zaroorat nahi."Kyun sahi lagta hai: users slowness ko feature ke broken hone ki tarah experience karte hain, isliye functional lagta hai.
Fix: feature 100% present ho sakta hai aur phir bhi fail ho sakta hai. NFR ko alag karna ek explicit, measurable target aur ek alag tarah ka test (load test, nahi feature test) force karta hai. Us split ke bina, "fast enough" ek opinion rehta hai.
Common mistake User story ke andarhow (solution) likhna.
e.g. "As a user I want a Redis cache so pages load fast."
Kyun sahi lagta hai: dev already solution imagine kar leta hai.
Fix: stories problem space ki hoti hain (goal + benefit); how baad mein liya jaane wala design decision hai. Rewrite: "...I want pages to load quickly, so that I don't abandon the site." Ab team Redis, CDN, ya kuch bhi choose karne ke liye free hai.
Common mistake Acceptance criteria mein koi edge/negative cases nahi.Kyun sahi lagta hai: happy path woh hai jo hum pehle sochte hain.
Fix: har "Then it works" ke liye, ek Given an invalid/empty/boundary input case add karo. Zyaadatar production bugs boundaries par hote hain (0 items, max length, no network).
Common mistake "Testable" ka matlab sirf ek human click karta ghoomta hai.Kyun sahi lagta hai: manual checking confirm karta hai ki demo kaam karta hai.
Fix: ek AC ko is tarah phrase kiya jaana chahiye ki ise automated kiya ja sake aur hamesha re-run ho sake (objective pass/fail, fixed inputs/outputs). "Looks nice" testable nahi hai; "shows total = £0" hai.
Stakeholders se baat karo → raw needs collect karo.
Har need ko FR (verbs) aur NFR (measurable qualities) mein split karo.
User-facing FRs ko user stories (role/goal/benefit) ki form mein package karo, unhe INVEST rakho.
Har story ke liye, acceptance criteria (Given-When-Then) likho — edge cases aur koi bhi NFR thresholds including .
Estimate karo, benefit se prioritise karo (80/20), banao, phir story ko "done" tab hi verify karo jab saare AC pass ho jaayein .
Functional requirement kaunsa ek sawaal answer karta hai?WHAT system ko karna chahiye (ek behaviour/feature, ek "verb").
Non-functional requirement kaunsa ek sawaal answer karta hai?HOW WELL — ek measurable quality/constraint (speed, security, availability...).
3-part user story template doh. As a , I want , so that .
User story mein "so that " kyun hota hai? Yeh value batata hai, prioritisation/80-20 filter ki tarah kaam karta hai aur cost justify karta hai.
INVEST acronym ka matlab kya hai? Independent, Negotiable, Valuable, Estimable, Small, Testable.
Acceptance criterion kya hota hai? Ek specific pass/fail condition jo ek story ko accept hone ke liye meet karni chahiye ("definition of done").
Gherkin AC format ke teen keywords batao. Given (context), When (action), Then (expected outcome).
Non-functional thresholds aksar kahan concrete bante hain? Acceptance criteria mein, measurable numbers ke roop mein (e.g. "≤ 2 s for 95th percentile").
Performance ko non-functional ke roop mein alag kyun karein feature ke hisse ki jagah? Ek feature fully present ho sakta hai phir bhi bahut slow ho; yeh split ek measurable target aur alag test (load test) force karta hai.
"As a user I want a Redis cache so pages load fast" mein kya galat hai? Yeh ek solution (how) batata hai, goal nahi; stories problem space mein rehni chahiye aur design open chhodni chahiye.
FURPS+ tumhe kya check karne ki yaad dilata hai? Functionality, Usability, Reliability, Performance, Supportability + security/scalability/legal NFRs.
Requirements error ko production mein fix karna itna zyada expensive kyun hota hai? Cost roughly exponentially har stage ke saath badhti hai; ek galat assumption design, code, aur tests mein propagate ho jaata hai.
Recall Feynman: ek 12-saal ke bacche ko samjhaoSocho tum apne dost se sandwich banane ko kehte ho. Functional = kya daalna hai: "bread, cheese, ham." Non-functional = kaise chahiye: "1 minute mein ready, zyada salty nahi, triangles mein kata hua." User story tum ho yeh kehte hue ki kyun : "Main ek bhooka baccha hoon jo cheese & ham chahta hoon taaki class mein bhookha naa rahoon." Acceptance criteria woh tarika hai jisse dost prove karta hai ki sahi hai: "Given tumne mujhe bread diya, jab finish hoon, tab cheese AUR ham hai, bread jali nahi hai, aur ek minute se kam laga." Agar inme se koi bhi fail ho, sandwich 'done' nahi hai — chahe theek lagta ho!
Mnemonic Whole-chapter hook"What, How-well, Who-Why, Prove-it."
What = functional · How-well = non-functional · Who-Why = user story · Prove-it = acceptance criteria.
Software Development Life Cycle — requirements pehla SDLC phase hain.Agile and Scrum — user stories product backlog mein rehti hain.Test-Driven Development — acceptance criteria automated tests ban jaate hain.Software Design — design woh how answer karta hai jo stories deliberately omit karti hain.Stakeholder Analysis — har story mein <role> yahaan se aata hai.Estimation and Story Points — INVEST ka "Estimable/Small" hissa.
Requirements = written agreement on done
Cost grows exponentially if caught late
Functional = WHAT it does
Non-functional = HOW WELL
Feature and benchmark tests
