Requirements Review कैसे करें

Requirements review क्या है और यह क्यों फ़ायदेमंद है

ISTQB की शब्दावली में requirements और user stories test basis का हिस्सा हैं — वह सामग्री जिससे टेस्ट निकाले जाते हैं। इनका review स्टैटिक टेस्टिंग है, और CTFL v4.0 requirement defects — inconsistency, अस्पष्टता, विरोधाभास, छूटी बातें, अशुद्धियाँ और दोहराव — को उन defects में गिनता है जिन्हें स्टैटिक टेस्टिंग dynamic टेस्टिंग से ज़्यादा आसानी और कम लागत में पकड़ती है। बच निकला requirement defect कोड बनता है, फिर उसी गलतफ़हमी पर लिखे टेस्ट, और आख़िर में कोई यूज़र उसे पकड़ता है।

Requirements review साझा समझ भी बनाता है, जो कोई डॉक्यूमेंट अकेले नहीं दे सकता। जब product owner, एक डेवलपर और एक टेस्टर एक ही story साथ पढ़ते हैं — जिसे कई agile टीमें "three amigos" कहती हैं — तो हर कोई अलग सवाल लाता है: बिज़नेस को क्या चाहिए, इसे कैसे बनाया जा सकता है, और यह कैसे fail हो सकता है। Review प्रकार आम तौर पर informal या छोटा technical review होता है; नियामक या वित्तीय rules के लिए checklist के साथ inspection उचित है। Review के प्रकार और भूमिकाएँ अपने अलग पेज पर तुलना के साथ हैं।

Requirements review कैसे चलाएँ, कदम दर कदम

• सही समय चुनें। Story को sprint में लेने से पहले review करें (कई टीमें "reviewed" को definition of ready का हिस्सा बनाती हैं), और बदलने पर फिर review करें।
• संदर्भ इकट्ठा करें। Epic, जुड़े business rules, API contract, डिज़ाइन और story से जुड़ा कोई नियम खोलें। कई विरोधाभास डॉक्यूमेंट के बीच होते हैं, एक के अंदर नहीं।
• पहले अकेले पढ़ें। हर reviewer नीचे की checklist के साथ पढ़े और चर्चा से पहले findings लिखे, ताकि पहली कही गई राय बाक़ी सबको न बाँध दे।
• Findings को review comments की तरह लिखें। हर comment में एक finding: कहाँ, क्या गलत है, क्यों मायने रखता है, सुझाया गया बदलाव या सवाल, और किसे फ़ैसला करना है।
• चर्चा करें और तय करें। Refinement या छोटी मीटिंग में author हर finding को स्वीकार, अस्वीकार या बदलता है। खुले सवालों को owner और तारीख़ मिलती है; कुछ भी चुपचाप मान लिया गया नहीं छोड़ा जाता।
• Rework करें और फिर जाँचें। Author story और acceptance criteria अपडेट करता है; एक reviewer पुष्टि करता है कि हर स्वीकार की गई finding हल हुई, तभी story ready मानी जाती है।
• Findings संभालकर रखें। Finding types (अस्पष्टता, छूटा error path, टकराता rule) का log दिखाता है कि आपकी टीम को कौन-से checklist items और template headings सबसे ज़्यादा चाहिए।

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI Requirement गैप एनालाइज़र

Requirements review checklist

इन आठ मानदंडों को अपने नोट्स के शीर्षक बनाएँ। हर मानदंड के नीचे के सवाल वही हैं जो सबसे ज़्यादा defects पकड़ते हैं।

• Ambiguity (अस्पष्टता) — क्या दो पाठक इसे अलग-अलग बना या टेस्ट कर सकते हैं? क्या इसमें धुँधले शब्द (तेज़, आसान, उचित), अपरिभाषित शब्द, अस्पष्ट सर्वनाम या "और/या" हैं?
• Completeness (पूर्णता) — क्या error paths, खाली स्थितियाँ, limits, permissions और roles कवर हैं? Timeout, दोहरे submission, cancel या invalid डेटा पर क्या होता है? यह कौन कर सकता है, और कौन नहीं?
• Consistency — क्या यह किसी दूसरी story, business rule, API contract, UI डिज़ाइन या ख़ुद से टकराता है? क्या एक ही चीज़ को हर जगह एक ही नाम से बुलाया गया है?
• Correctness (सही होना) — क्या यह वही है जो बिज़नेस और यूज़र को सच में चाहिए? क्या यह domain, क़ानून और मौजूदा नीति के हिसाब से सही है? क्या संख्याएँ (fees, limits, GST/VAT, तारीख़ें) सही और स्रोत-सहित हैं?
• Testability — क्या हर acceptance criterion ऐसा observable नतीजा बताता है जिसका pass या fail साफ़ हो? क्या आप आज ही इससे किसी test case का expected result लिख सकते हैं?
• Feasibility — क्या उपलब्ध तकनीक, डेटा, third-party services, समय और बजट से इसे बनाया जा सकता है? क्या यह किसी ऐसी चीज़ पर निर्भर है जो टीम के नियंत्रण में नहीं?
• Traceability — क्या इसका unique ID है, इसके epic या बिज़नेस लक्ष्य और जुड़े rules से link है, और क्या test cases इसे reference कर पाएँगे?
• Non-functional ज़रूरतें — क्या performance, security, privacy, accessibility, localisation, reliability और audit की ज़रूरतें मापने योग्य मानदंडों के साथ लिखी हैं, या कम से कम यह चिह्नित है कि वे कहीं और तय हैं?

आज़माएँ: AI Acceptance Criteria रिव्यूअर

चेतावनी वाले शब्द और उनकी जगह क्या पूछें

कुछ शब्द लगभग हमेशा किसी अनिर्णीत requirement को छिपाते हैं। गहराई से पढ़ने से पहले टेक्स्ट में इन्हें खोजें; हर शब्द या तो एक finding है या इस बात की तेज़ पुष्टि कि उसका अर्थ कहीं और परिभाषित है।

Requirement में शब्द                   इसकी जगह पूछें
fast, जल्दी, तुरंत                     कितने सेकंड या मिनट में, किस percentile पर, किस लोड में?
user-friendly, आसान, intuitive         कौन-सा काम, किस यूज़र के लिए, कैसे मापा जाएगा?
उचित, reasonable, पर्याप्त              ठीक-ठीक क्या? cases गिनाएँ या संख्या दें
etc., आदि, जैसे                         पूरी सूची क्या है?
should, may, might                     अनिवार्य या वैकल्पिक?
सभी, हमेशा, कभी नहीं                   सच में सभी? अपवाद क्या हैं?
support, handle, process, manage       observable व्यवहार क्या है?
and/or                                 दोनों, या कोई एक?
secure, robust, scalable               किस ख़तरे, failure या लोड के ख़िलाफ़?

पूरा उदाहरण: एक user story और उसके review comments

उदाहरण के लिए, एक काल्पनिक ऑनलाइन स्टोर के backlog में यह story है। टीम के account rules डॉक्यूमेंट में एक business rule BR-4 भी है: unverified accounts sign in नहीं कर सकते।

नीचे के comments उसी तरह लिखे हैं जैसे वे review टूल या ticket पर दिखेंगे: हर comment में एक मुद्दा, उसकी जगह, कारण और सुझाव या सवाल। ध्यान दें कि reviewer वैल्यू सुझाता है पर तय नहीं करता — फ़ैसला product owner का है, और जहाँ security शामिल है वहाँ security का।

Story (US-231, email से password reset) में छह acceptance criteria हैं: email डालकर reset link पाना, “उचित समय” के बाद link का expire होना, “strong” नया password, reset के बाद अपने-आप login, “fast और user-friendly” पेज, और unverified accounts के लिए भी reset। नौ review comments का सार:

• RC-01 (Testability · Major, AC2) — “उचित समय” टेस्ट नहीं हो सकता, दो टेस्टर दो अलग संख्याएँ चुनेंगे। सुझाव: link भेजे जाने के 30 मिनट बाद expire हो; PO से पूछा गया कि क्या 30 मिनट सही है।
• RC-02 (Ambiguity · Major, AC3) — “strong” परिभाषित नहीं। क्या मतलब मौजूदा password policy SEC-12 से है? और क्या नया password मौजूदा password जैसा हो सकता है?
• RC-03 (Completeness · Major, AC1) — unregistered email पर व्यवहार तय नहीं। संदेश अलग हुआ तो form बता देगा कि किन emails के account हैं; सुझाव: दोनों हालात में एक ही संदेश, security की पुष्टि के साथ।
• RC-04 (Completeness · Minor, AC1 और AC2) — क्या link एक ही बार चलेगा? ग्राहक दो links माँगे तो क्या पहला valid रहेगा?
• RC-05 (Consistency · Major, AC4 + AC6) — दोनों मिलकर unverified account को sign in करने देते हैं, जो BR-4 से टकराता है; तीनों में से एक को बदलना होगा।
• RC-06 (Correctness · सवाल, AC4) — क्या reset दूसरे devices के मौजूदा sessions बंद करे? Reset के तुरंत बाद automatic sign-in पर security का फ़ैसला चाहिए।
• RC-07 (Non-functional · Major, AC5) — “fast और user-friendly” दो requirements हैं और कोई भी मापने योग्य नहीं; इन्हें response-time लक्ष्य और टीम की accessibility checklist में बाँटें। साथ ही: email किस भाषा में जाएगा?
• RC-08 (Feasibility · सवाल, AC1) — reset requests की कोई सीमा है? उसके बिना form से किसी ग्राहक का inbox भरा जा सकता है और email provider का ख़र्च बढ़ सकता है।
• RC-09 (Traceability · Minor, story) — story अपने epic, SEC-12 और BR-4 से linked नहीं; links जोड़ें ताकि test cases उन rules तक trace हो सकें जिन्हें वे जाँचते हैं।

US-231  Reset password by email
As a registered customer
I want to reset my password from the login page
so that I can get back into my account when I forget it.

AC1  The customer enters their email and receives a reset link.
AC2  The link expires after a reasonable time.
AC3  The new password must be strong.
AC4  After resetting, the customer is logged in automatically.
AC5  The page should be fast and user-friendly.
AC6  Customers with unverified accounts can also reset their password.

--- Review comments ---

RC-01 [Testability · Major] AC2
  "A reasonable time" cannot be tested: two testers will pick two different numbers.
  Proposal: "The link expires 30 minutes after it is sent." @PO is 30 minutes right?

RC-02 [Ambiguity · Major] AC3
  "Strong" is not defined here. Is this the existing password policy SEC-12?
  If so, reference it. Can the new password be the same as the current one?

RC-03 [Completeness · Major] AC1
  No behaviour for an email that is not registered. If the message differs, the
  form reveals which emails have accounts. Proposal: show the same message in both
  cases. @Security please confirm.

RC-04 [Completeness · Minor] AC1, AC2
  Is the link single-use? If the customer requests two links, is the first one
  still valid?

RC-05 [Consistency · Major] AC4 + AC6
  Together they let an unverified account sign in, which contradicts BR-4
  ("unverified accounts cannot sign in"). One of the three has to change.

RC-06 [Correctness · Question] AC4
  Should a password reset sign out existing sessions on other devices? Automatic
  sign-in right after a reset needs a security decision.

RC-07 [Non-functional · Major] AC5
  "Fast and user-friendly" is two requirements and neither is measurable. Split
  into a response-time target and the team accessibility checklist. Also: which
  language is the email sent in, Hindi or English?

RC-08 [Feasibility · Question] AC1
  Is there a limit on reset requests? Without one, the form can be used to flood
  a customer inbox and to run up email-provider costs.

RC-09 [Traceability · Minor] Story
  Not linked to its epic or to SEC-12 and BR-4. Add the links so test cases can
  trace to the rules they check.

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI Acceptance Criteria रिव्यूअर

Rework के बाद की story

इस काल्पनिक उदाहरण में product owner और security lead ने सवालों के जवाब दिए, और author ने criteria दोबारा लिखे। संख्याएँ टीम के फ़ैसले हैं, सिफ़ारिशें नहीं। अब हर criterion का observable नतीजा है, और story उन rules से traceable है जिन पर वह निर्भर है।

• AC1 — कोई भी email address भेजने पर एक ही पुष्टि संदेश, चाहे वह registered हो या नहीं।
• AC2 — registered और verified address पर single-use reset link, जो भेजे जाने के 30 मिनट बाद expire होता है; नया request पहले के सभी links रद्द करता है।
• AC3 — नया password SEC-12 पूरा करे और मौजूदा password से अलग हो। AC4 — सफल reset के बाद सभी मौजूदा sessions बंद होते हैं और ग्राहक success संदेश के साथ login पेज पर जाता है।
• AC5 — unverified account को reset link की जगह verification email जाता है (BR-4)। AC6 — प्रति account प्रति घंटे अधिकतम 5 reset requests; उसके बाद वही पुष्टि संदेश, पर कुछ भेजा नहीं जाता।
• NFR1 — reset email account की भाषा (हिंदी या अंग्रेज़ी) में। NFR2 — form टीम की accessibility checklist पास करता है। NFR3 — response time के लिए site-wide लक्ष्य PERF-2 लागू है (PERF-2 में तय reference load पर form submissions के लिए p95 2 s से कम); product owner ने इस story का अलग लक्ष्य तय नहीं किया।

US-231  Reset password by email  (v2, after review)
Links: EPIC-AUTH-3 · SEC-12 password policy · BR-4 verified accounts · PERF-2 response time

AC1  Given the "Forgot password" form, when any email address is submitted,
     then the same confirmation message is shown whether or not it is registered.
AC2  Given a registered, verified address, a reset link is sent. The link is
     single-use and expires 30 minutes after it is sent. A new request
     invalidates all earlier links.
AC3  The new password must satisfy SEC-12 and differ from the current password.
AC4  After a successful reset, all existing sessions are signed out and the
     customer is taken to the login page with a success message.
AC5  For an unverified account, the verification email is sent instead of a
     reset link (BR-4).
AC6  At most 5 reset requests per account per hour. Further requests show the
     same confirmation message and send nothing.
NFR1 The reset email is sent in the account language (Hindi or English).
NFR2 The form passes the team accessibility checklist: labelled fields,
     announced error messages, full keyboard operation.
NFR3 Response time: the site-wide target PERF-2 applies (p95 under 2 s for form
     submissions at the PERF-2 reference load); the product owner set no
     story-specific target.

आज़माएँ: AI Acceptance Criteria जनरेटर आज़माएँ: एक्सेप्टेंस क्राइटेरिया जनरेटर

Non-functional requirements का review

Non-functional ज़रूरतें story का सबसे ज़्यादा छूटने वाला हिस्सा हैं, क्योंकि story template सिर्फ़ व्यवहार पूछता है। ISO/IEC 25010 प्रोडक्ट क्वालिटी विशेषताएँ बताता है — जिनमें performance efficiency, security, reliability, compatibility और interaction capability (usability) शामिल हैं — और यह एक उपयोगी याद-सूची है: हर विशेषता के लिए पूछें कि क्या story उसे प्रभावित करती है, और अगर हाँ, तो criterion कहाँ लिखा है।

• Performance — एक संख्या, एक percentile और एक लोड: "200 concurrent users पर p95 response 2 s से कम" testable है; "तेज़" नहीं।
• Security और privacy — कौन क्या देख और बदल सकता है, कौन-सा डेटा personal है, कितने समय रखा जाता है, क्या log होता है। OWASP ASVS सत्यापन-योग्य security requirements का एक कैटलॉग है जिससे मदद ली जा सकती है।
• Accessibility — keyboard से चलाना, labels, error announcements और contrast, आम तौर पर टीम की WCAG-आधारित checklist के reference से।
• Localisation — भाषाएँ, right-to-left layout, तारीख़, संख्या और currency फ़ॉर्मैट, और messages व emails किस भाषा में जाते हैं।
• Reliability और operations — किसी dependency के बंद होने पर व्यवहार, retries, time limits, और क्या monitor होता है और किस पर alert आता है।

Mutqan के AI requirement टूल कैसे मदद करते हैं — और कहाँ रुकते हैं

Individual review चरण में AI टूल एक अतिरिक्त, बहुत तेज़ reviewer की तरह उपयोगी हैं। कोई story या requirements का सेट पेस्ट करें और वे सेकंडों में संभावित findings लौटाते हैं; फिर हर सुझाव को ड्राफ़्ट comment मानें जिसे आप स्वीकार करें, दोबारा लिखें या हटा दें। वे ड्राफ़्ट बनाते हैं; फ़ैसला इंसान करता है।

उनकी सीमाएँ वही हैं जो बिना संदर्भ वाले किसी भी reviewer की होती हैं। जब तक आप न दें, वे आपके दूसरे डॉक्यूमेंट, पिछले हफ़्ते की मीटिंग के फ़ैसले, आपके नियम या आपके यूज़र्स नहीं जानते; वे ऐसे gaps उठा सकते हैं जिनका जवाब कहीं और है, या किसी ऐसे rule से विरोधाभास चूक सकते हैं जिसे उन्होंने कभी देखा ही नहीं। बाहरी service से क्या साझा किया जा सकता है, इस पर अपने संगठन की नीति मानें, और उदाहरणों में anonymised या काल्पनिक डेटा इस्तेमाल करें।

• AI Requirement Ambiguity Detector — अस्पष्ट, धुँधले या विरोधाभासी कथन पकड़ता है और स्पष्टता के सवाल सुझाता है; RC-01 और RC-02 जैसी findings के लिए तेज़ पहला दौर।
• AI Requirement Gap Analyzer — छूटी requirements खोजता है, जैसे error handling, permissions, edge conditions और non-functional ज़रूरतें; RC-03, RC-04 और RC-08 जैसी findings।
• AI Acceptance Criteria Reviewer — acceptance criteria को testability, पूर्णता और अस्पष्टता के लिए review करता है और दोबारा लिखे सुझाव देता है जिन्हें आप ढाल सकते हैं।
• AI Acceptance Criteria Generator — user story से Given/When/Then criteria का ड्राफ़्ट बनाता है, तब उपयोगी जब story बिना criteria के आए।
• Requirements → Test Cases और AI Test Coverage Analyzer — पहला numbered requirements को requirement-to-test matrix के साथ traceable test cases में बदलता है; दूसरा requirements की तुलना मौजूदा test cases से करके untested हिस्से खोजता है।

आज़माएँ: AI Requirement अस्पष्टता डिटेक्टर आज़माएँ: AI Requirement गैप एनालाइज़र आज़माएँ: AI Acceptance Criteria रिव्यूअर

Review से test design तक

Review हुई story बेहतर test basis है: हर acceptance criterion एक या अधिक test conditions बनता है, review में जोड़े गए error paths negative test cases बनते हैं, और review में तय संख्याएँ (30 मिनट, प्रति घंटे 5 requests) boundary values बनती हैं। हर टेस्ट से उस criterion तक का link रखें जिसे वह कवर करता है, ताकि बदला criterion ठीक-ठीक बताए कि कौन-से टेस्ट अपडेट करने हैं। Criteria को अच्छी बनावट वाले test cases में बदलना test cases लिखने वाली गाइड में है।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: AI टेस्ट कवरेज एनालाइज़र आज़माएँ: User Story → टेस्ट सिनेरियो

अक्सर पूछे जाने वाले सवाल

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISO/IEC 20246:2017 — Software and systems engineering — Work product reviewsISO/IEC · 2017वर्क प्रोडक्ट की समीक्षा का सामान्य फ़्रेमवर्क — review प्रक्रिया, भूमिकाएँ और review तकनीकें।
• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• Agile Testing: A Practical Guide for Testers and Agile Teams (Lisa Crispin, Janet Gregory)Addison-Wesley (Pearson) · 2009एजाइल टेस्टिंग क्वाड्रेंट और टेस्टर डिलीवरी टीम के भीतर कैसे काम करते हैं — "सही परत पर टेस्टिंग" का आधार।
• OWASP Application Security Verification Standard (ASVS)OWASP Foundationवेब एप्लिकेशन के लिए सत्यापन-योग्य सुरक्षा आवश्यकताओं की चेकलिस्ट, तीन एश्योरेंस स्तरों में।