3. Requirement Engineering & Types of Requirements

CSS Optional — Paper-II, Section-B · P-II.VI.3 · Covers syllabus items requirement engineering, requirement, types of requirements, functional requirements, non-functional requirements. The most repeated Web Engineering topic: asked in 2019, 2020 and 2021. Full model answers in section 7.

1. What Is a Requirement?

IEEE 610.12 defines a requirement as (1) a condition or capability needed by a user to solve a problem or achieve an objective; (2) a condition or capability that must be met by a system to satisfy a contract, standard or specification; (3) a documented representation of either.

2. What Is Requirement Engineering (RE)?

The systematic process of discovering, documenting, validating and managing requirements throughout a system's life. Output: an agreed, verifiable requirements specification that design, development and testing are built against.

3. Role of RE in Web Engineering (CSS 2021)

• Aligns stakeholders: web projects have many (clients, marketing, designers, end users, regulators) with conflicting goals.
• Controls volatility: web requirements change constantly; RE provides change control and traceability.
• Captures quality requirements early: usability, performance, security and availability decide web success — they must be explicit, not assumed.
• Reduces cost of errors: fixing a requirement error after release costs many times more than fixing it during RE.
• Basis for testing and acceptance: every test case traces back to a requirement.
• Prevents scope creep and supports realistic estimates for tight web deadlines.

Web-specific RE challenges (Kappel): multidisciplinary stakeholders; end users often unavailable/unknown; volatile requirements; unpredictable operational environment; legacy integration; critical quality aspects; content quality; UI quality; developer inexperience; fixed launch dates.

Principles for web RE: understand the system context; involve stakeholders; define requirements iteratively; focus on architecture; be risk-oriented.

4. Types of Requirements

Web-specific requirement types (Kappel, based on ISO/IEC 9126): functional, content, quality (functionality, usability, portability, scalability, reliability, efficiency, security, maintainability), system environment, user interface, evolution, and project constraints.

5. Functional vs Non-Functional Requirements

NFR classification (Sommerville):

• Product: usability, efficiency (performance, space), dependability (reliability, availability), security.
• Organizational: environmental, operational, development (language, process, standards).
• External: regulatory, ethical, legislative (privacy, accessibility laws, PECA 2016 in Pakistan).

6. Characteristics of a Good Requirement (IEEE 830)

Correct, unambiguous, complete, consistent, ranked for importance, verifiable (testable), modifiable, traceable.

• Bad: "The site shall be fast and user-friendly." (not verifiable)
• Good: "The home page shall load within 2 seconds on a 4G connection for 95% of requests."

7. Model Answer — FR and NFR for a Website (CSS 2019, 2020, 2021)

Example: University Online Admission Portal

Functional requirements

1. Applicants shall register with CNIC, email and mobile number and verify the email by OTP.
2. Applicants shall fill an admission form, choose up to 3 programs, and upload documents (PDF/JPG, max 2 MB each).
3. The system shall generate a fee challan and accept online payment via bank/mobile wallet.
4. The system shall compute merit (e.g. 70% entry test + 30% HSSC) and publish merit lists.
5. Admins shall verify documents and approve or reject applications with comments.
6. Applicants shall track application status and receive email/SMS notifications.

Non-functional requirements

1. Performance: pages load in ≤ 2 s for 95% of requests; merit list generation in ≤ 5 min.
2. Scalability: support 20,000 concurrent users on the last day of applications.
3. Availability: 99.9% uptime during the admission window.
4. Security: HTTPS (TLS 1.2+); passwords hashed (bcrypt); role-based access; protection against SQL injection and XSS.
5. Usability: a first-time applicant completes the form in under 15 minutes without help; English and Urdu interfaces.
6. Compatibility: latest two versions of Chrome, Firefox, Safari and Edge; responsive on mobile.
7. Accessibility: WCAG 2.1 level AA.
8. Maintainability: admins update program lists and dates without code changes.

---

🎯 CSS Exam Angle

Table of differences + a concrete website example with 5–6 FRs and 5–6 measurable NFRs is the formula that scores. Always make NFRs quantified — examiners notice "fast" vs "≤ 2 s for 95% of requests".

📌 Past CSS Paper Frequency

⚠️ MCQ Traps

• "The system shall respond within 2 s" is non-functional (performance), even though it mentions a response.
• "Users shall log in with a password" is functional; "passwords shall be stored hashed" is non-functional (security).
• User requirements = client language; system requirements = detailed developer language.
• A requirement that cannot be tested is not verifiable — a defect in the requirement itself.

---

✅ Self-Check (with Answers)

Q1. Classify: (a) "Users can filter products by price"; (b) "The site shall support 5,000 concurrent users"; (c) "Checkout shall follow the State Bank's e-payment regulations".

Ans: (a) Functional. (b) Non-functional — scalability/performance. (c) Non-functional — external/regulatory (also a domain requirement).

Q2. Rewrite "The website should be secure" as a verifiable requirement.

Ans: "All pages shall be served over HTTPS with TLS 1.2 or higher; passwords shall be stored using bcrypt; accounts shall lock for 15 minutes after 5 failed login attempts."

Q3. Why are non-functional requirements especially critical for web applications?

Ans: Users are anonymous and have alternatives one click away, so slow, insecure, unavailable or hard-to-use sites lose users even if every feature works; and web apps face global scale and constant attack.

Q4. List four web-specific RE challenges.

Ans: Multidisciplinary stakeholders; unknown/unavailable end users; highly volatile requirements; unpredictable operational environment (devices, browsers, load); also legacy integration and fixed launch dates.

Q5. Differentiate user and system requirements.

Ans: User requirements are high-level statements in natural language for clients and users ("students can apply online"). System requirements are detailed technical specifications for developers ("store each application with a unique ID; send confirmation email within 1 minute").

📜 Past-Paper Questions & MCQs (CSS 2016–2026)

2016 · Paper-II · Q8(a) · 8 marks

Q. Explain the principles of requirements engineering of web applications.

Ans.

• Understand the problem and the business goals before any design: what is the site for, and who are the users?
• Involve all stakeholders: owners, content authors, users and administrators. Web users are diverse and often unknown, so use personas and scenarios.
• Capture both functional and non-functional needs: content, navigation and interaction as well as performance, security, usability, accessibility and compatibility.
• Work iteratively: requirements change quickly on the web, so elicit, prototype and review in short cycles.
• Prioritise (must, should, could) and negotiate conflicts.
• Model the requirements (use cases, scenarios, storyboards, navigation and content models).
• Validate, trace and manage change: review with users, link each requirement to design and tests, and control changes.
• Document clearly and keep the requirements understandable for both users and developers.

2019 · Paper-II · Q7(c), 2020 · Q8(c), 2021 · Q8(b), 2025 · Q8(a) · 6–7 marks

Q. Explain functional and non-functional requirements in the context of web application development, with a suitable example (list them for a website).

Ans.

• Importance in web engineering: non-functional requirements (performance, security, usability) often decide the success of a website, and they should be measurable.