Memorising definitions does not help much when a stakeholder says, “Students need faster feedback,” and you must turn that into something developers can build and testers can judge. That sentence carries no metric, no operating condition and no pass boundary, so nobody can decide whether a finished system satisfies it. Its disciplined form reads “at least 95% of result-page responses shall complete within 2.0 seconds under 500 concurrent authenticated learners”, and closing the distance between those two sentences is the whole job of requirements engineering. The running example is a 20-question mock-test portal: three stakeholder needs, four baselined requirements, four tests and one change request.
Software requirements: move from a stakeholder need to agreed scope
A stakeholder need states a problem or outcome. “Students need faster feedback” is a need. A software requirement turns it into a documented, verifiable capability or constraint: “The result page shall meet the stated response-time threshold.” A design decision selects an implementation, such as “store scores in Redis.” Keep that choice out of the requirement unless a constraint justifies it.
The requirements-engineering loop is: identify stakeholders and scope, elicit, analyse and negotiate, specify, validate, baseline, then manage change. Feedback can return the team to an earlier activity, so this is not a one-way waterfall checklist. Scope counts as agreed only when both sides can point at the same numbered list and also name what is off it: for this portal, adaptive difficulty, offline attempts and paper-wise cutoffs stay out of the first baseline.
GATE-focused readers can line up the preparation resources for the current cycle on the GATE CS Exam Preparation page.
Types of software requirements: functional, non-functional, data and interface
Classify a requirement by the question it answers, not by where it appears in a document.
Class | Question answered | Mock-test portal example |
|---|---|---|
Functional | What must the system do? | calculate a score after final submission |
Non-functional | How well or under what constraint? | at least 95% of result responses complete within 2.0 seconds under 500 concurrent authenticated learners |
Data/business rule | What facts and rules govern the result? | one recorded response per question per attempt, with +1 for correct, -0.25 for incorrect and 0 for unattempted |
External interface | What interaction crosses the system boundary? | send the final score and attempt ID to the learner dashboard |
User-level requirements express goals in reader language. System-level requirements carry IDs, conditions, outputs and acceptance criteria. The scoring rule is a domain constraint; calculating the score is system behaviour.
“Secure,” “fast,” “user-friendly” and “support many users” are not testable alone. Each needs a metric, operating condition and pass boundary.
Requirements elicitation and analysis: uncover conflicts before the SRS
Match elicitation to the evidence needed. Interview the exam-content owner about scoring policy. Observe test-taking to find workflow friction. Use a product, engineering and support workshop to settle conflicts. Inspect attempt logs for failure paths. Prototype the confirmation screen when words remain ambiguous.
Suppose the exam-content owner says answers must freeze the moment a learner presses Submit, while five learners watched during a session all expect a review step first. That is a policy source contradicting an observation source, and it has to be settled before either statement reaches the SRS. The settled rule: Submit opens review and confirmation; only Final submit freezes the 20 responses.
Before specification, remove duplicates, separate needs from solutions and resolve incompatible rules. Put unresolved conflicts in an issue log with an owner, not behind polished prose.
SRS quality: write atomic, measurable and verifiable requirements
A practical Software Requirements Specification records a unique ID, statement, rationale, source, priority, acceptance criterion, dependencies and status. Check that each entry is necessary, unambiguous, complete, consistent, feasible, verifiable and traceable. A template cannot guarantee quality.
Atomic means one required behaviour per ID, with its trigger and precondition attached, so a single test returns one pass or fail. Measurable means the statement names a quantity, a unit and a boundary: 2.0 seconds, 95%, five attempts, 15 minutes. Verifiable means someone can write that test before any code exists.
Replace vague statements with baselined requirements:
FR-01: “Until final submission, an authenticated learner shall store at most one selected option for each of 20 questions, revise any selection, and see a confirmation step before the attempt is frozen”.
FR-02: “After final submission, the system shall compute raw score as C - 0.25W, where C is correct responses and W is incorrect responses; unattempted responses add 0”.
NFR-01: “Under 500 concurrent authenticated learners, at least 95% of result-page responses shall complete within 2.0 seconds.”
NFR-02: “After five consecutive failed login attempts for one account, the system shall reject the sixth attempt and further attempts for 15 minutes; a successful login after the lock expires resets the counter.”
Five attempts and 15 minutes are policy choices, not standards; a banking product might settle on three attempts and 30 minutes. What makes NFR-02 a requirement is that whichever numbers the security owner approves are written down as a count, a boundary and a duration.
Software requirements worked example: specify and test a 20-question mock
AT-01 tests FR-01. Precondition: an authenticated learner has started a 20-question attempt. Choose B for question 7, change it to D, press Submit, and confirm that review still permits editing. Press Final submit. Expect D to remain the one stored response for question 7 and any later edit to be rejected.
AT-02 tests FR-02. Work the score line by line:
14 correct + 4 incorrect + 2 unattempted = 20 responses.
Positive marks = 14 x 1 = 14.
Penalty = 4 x 0.25 = 1.
Unattempted contribution = 2 x 0 = 0.
Raw score = 14 - 1 + 0 = 13.
PT-01 tests NFR-01. Send 1,000 result requests at the declared load of 500 concurrent authenticated learners. Since 95% of 1,000 is 950, 950 responses at or below 2.0 seconds pass. Only 949 gives 94.9%, so it fails. Record the elapsed-time distribution, environment and dataset.
ST-01 tests NFR-02. After failures 1 through 5, reject attempt 6 and an attempt at minute 14. An attempt may proceed after 15 full minutes. One successful login then resets the count.
Requirements validation and traceability: prove coverage and control change
Validation asks stakeholders whether documented behaviour solves the intended problem. Verification checks whether each requirement and its artefacts satisfy the specification. Use reviews, prototypes, test-case derivation, consistency checks and boundary tests.
A requirements traceability matrix connects needs, specifications, use cases and tests:
N1 -> FR-01 -> UC-01 -> AT-01N1 -> FR-02 -> UC-02 -> AT-02N2 -> NFR-01 -> PT-01N3 -> NFR-02 -> ST-01
Forward traceability proves every need reaches implementation and test. Backward traceability prevents unapproved features with no stakeholder need.
Change request CR-07 says: “Limit a learner to at most three revisions of any one response before Final submit.” FR-01 as baselined allows unlimited revision, so the direct impact is FR-01, UC-01 and AT-01. Revise all three, rerun AT-01 and record the new baseline. One SRS edit alone is not change control.
Software requirements in exams: question patterns and the GATE scope check
Concept questions may ask you to classify a requirement, choose the least ambiguous SRS sentence, match an elicitation technique, order activities, find an inconsistency, or interpret a traceability link. Look for the condition, metric and objective result.
The official GATE 2026 Computer Science and Information Technology syllabus names ten sections, from Engineering Mathematics to Computer Networks, and lists neither Software Engineering nor requirements engineering among them. Do not infer a GATE 2026 weightage or question distribution for this topic, and check the official syllabus of your own exam and cycle before budgeting hours to it.
Use GATE CS Subject Weightage: Where Hours Pay Off to prioritise the sections the syllabus does name, and MCQ, MSQ or NAT? GATE Question Types Explained to recognise the formats those sections are asked in.
Software requirements: the short version and an honest next step
Revise the workflow as one chain:
Need
Elicitation
Analysis
Testable SRS
Validation
Traceable baseline
Use one final self-check: if a statement cannot produce an objective pass or fail result, it is not ready to baseline.
If GATE is your immediate target, GATE Guidance by Sanchit Sir can help you allocate study across the current official syllabus, while the GATE Test Series provides syllabus-aligned practice.
