Requirements define what the system must achieve. PSC questions often test SRS qualities, functional versus non-functional requirements, elicitation methods, validation, reviews, use cases, DFD/UML and requirement traceability.

Engineering Definitions

Requirement

Standard definition: A documented capability, constraint or quality that a system must satisfy.

Exam meaning: System ले गर्नुपर्ने वा पालना गर्नुपर्ने documented need।

SRS

Standard definition: Software Requirements Specification is a formal document describing functional and non-functional requirements.

Exam meaning: Software ले के गर्ने र कुन quality/constraint पालना गर्ने भन्ने formal document।

Functional requirement

Standard definition: A requirement describing a service, behavior or function the system must provide.

Exam meaning: System ले गर्ने काम/function।

Non-functional requirement

Standard definition: A requirement describing quality attributes or constraints such as performance, security and usability.

Exam meaning: System कसरी चल्नुपर्छ भन्ने quality/constraint।

Concept Teaching

Requirement errors are expensive because they affect design, code and tests. Good requirements are correct, complete, consistent, unambiguous, verifiable, traceable and feasible. Modeling makes invisible requirements visible through diagrams and scenarios.

Requirement Elicitation

Elicitation discovers stakeholder needs.

  • Interviews collect detailed stakeholder views.
  • Questionnaires collect broad feedback.
  • Observation reveals real workflow.
  • Workshops resolve conflicts quickly.
  • Document analysis studies existing forms/reports.
  • Prototyping clarifies unclear UI or process.

SRS Qualities

IEEE-style SRS quality is a common exam answer.

  • Correct: reflects real user need.
  • Complete: all required behavior included.
  • Consistent: no contradictions.
  • Unambiguous: one interpretation.
  • Verifiable: can be tested/reviewed.
  • Traceable: linked from source to design/test.
  • Modifiable: structured for change.

Modeling Tools

Use the right model for the right view.

Model Shows Use
Use case Actor-system interaction Functional scope
DFD Data movement and processes Process analysis
ER diagram Data entities and relationships Database modeling
Class diagram Object structure OO analysis/design
Sequence diagram Object interactions over time Scenario behavior
State diagram State-dependent behavior Workflow/control

Review and Validation

Requirements must be checked before design freezes.

  • Review finds ambiguity, inconsistency and missing cases.
  • Walkthrough explains requirement to stakeholders.
  • Inspection uses formal checklist.
  • Validation confirms requirements match user needs.
  • Traceability matrix maps requirements to design, code and tests.

Engineering Mechanism

  • Identify stakeholders.
  • Elicit needs using interviews/workshops/documents.
  • Classify functional and non-functional requirements.
  • Model processes, data and interactions.
  • Write SRS with clear acceptance criteria.
  • Review, validate and baseline requirements.
  • Track changes through traceability.

Diagrams / Models To Draw

  • Draw use case diagram.
  • Draw level-0 DFD/context diagram.
  • Draw ER model for sample system.
  • Draw requirement traceability matrix.

Formulas, Algorithms and Rules

  • Good requirement = necessary + unambiguous + verifiable + traceable.
  • Traceability links: source -> requirement -> design -> code -> test.
  • NFR examples: response time, availability, security, usability, maintainability.
Requirement type Example Test idea
Functional System shall generate report Check report output
Performance Response under 2 seconds Load test
Security Only authorized users access data Access-control test
Usability User completes task in 3 clicks Usability test
Reliability 99.9% uptime Operational monitoring

Exam Point

  • Always separate functional and non-functional requirements.
  • SRS qualities are high-yield.
  • Use case is not the same as DFD.
  • Requirement must be verifiable.
  • Traceability helps impact analysis.

Worked Example

“System should be fast” is weak because it is ambiguous and not verifiable. “Search results shall be displayed within 2 seconds for 95% of queries under 500 concurrent users” is measurable and testable.

Subjective Answer Pattern

  • Define requirements engineering.
  • Explain elicitation.
  • Differentiate functional/NFR.
  • Discuss SRS qualities.
  • Explain modeling and review.
  • Conclude with traceability/change control.

Common Engineering Mistakes

  • Writing vague requirements.
  • Mixing design solution into requirement too early.
  • Ignoring non-functional requirements.
  • Confusing validation and verification.
  • No acceptance criteria.

MCQ Revision

  • What is SRS?
  • Functional or non-functional: response time?
  • Which model shows actors?
  • Which quality means one interpretation?
  • What is traceability matrix?
  • What does validation check?

Final Summary

  • Requirements guide all later software work.
  • Good SRS is clear, complete and testable.
  • Modeling improves understanding.
  • Review catches defects early.
  • Traceability controls change impact.