Software Engineering

Solution

Correct Answer: (c) Product features

Explanation

• Non-functional requirements = how system behaves: Efficiency, Reliability, Stability, Portability, Performance, Security → (a),(b),(d) are NFRs.
• Product features / Functional requirements = what system does (e.g., login, billing) → Functional, not non-functional. So Product features is NOT an NFR.

Answer: (c) Product features

Solution

Correct Answer: (ii) MTBF

Explanation

Reliability metrics:

• MTBF = Mean Time Between Failures = MTTF + MTTR → overall reliability measure. Larger MTBF = more reliable.
• MTTF = Mean Time To Failure (for non-repairable)
• MTTR = Mean Time To Repair
• ROCOF = Rate of Occurrence of Failures

Hence measure of reliability is given by MTBF (and also MTTF/ROCOF variants). Mean time between success and mean reliable are not standard terms.

Answer: (ii) MTBF

Solution

Correct Answer: (iv) It complies with the available system

Explanation

CASE (Computer-Aided Software Engineering) tools are used for:

• (i) Supporting SA/SD - YES: Upper CASE tools support Structured Analysis & Design (DFD, ERD, UML)
• (ii) Maintaining data dictionary - YES: Central repository / data dictionary is core CASE function
• (iii) Checking DFD balance - YES: CASE tools do syntax/semantic checks e.g., balancing Level-0 and Level-1 DFDs, completeness checks
• (iv) It complies/compiles with available system - NOT a use. CASE tools do not compile with system nor ensure compliance with hardware/OS. That is the job of compilers/compatibility tools. This option is irrelevant to CASE purpose.

Note: Variant phrasing "It compiles with the available system" (Q29 - 2022) is same answer - also (iv).

Answer: (iv) It complies with the available system

Solution

Correct Answer: (iii) Volatile requirement

Explanation

Requirements are classified by how stable they are:

• Enduring requirements - stable, tied to the core activity of the organization; they change rarely.
• Volatile requirements - likely to change during development or after delivery because of evolving business conditions, policies, laws or technology.

A requirement expected to change because of evolving business conditions is therefore volatile.

Why other options are incorrect:

• (i) Enduring - the opposite: stable and long-lasting.
• (ii) Structural - not a standard stability category.
• (iv) Derived - a requirement obtained from other requirements, not defined by how often it changes.

Answer: (iii) Volatile requirement

Answer: (ii) Understanding and documenting user needs and requirements

The primary goal of requirement analysis is to understand the user's needs and document them (as a Software Requirements Specification, SRS) so that the right system is built — before any design or coding.

Why the others are wrong:

• (i) Coding the software — coding happens much later (in the construction phase), after requirements are understood.
• (iii) Testing the software — testing verifies that the built system meets requirements; it is a later phase.
• (iv) Designing the software architecture — design comes after requirements analysis and relies on it.

Requirement analysis answers "what must the system do?" — everything downstream (design, code, test) depends on this correct specification.

Solution

Correct Answer: (iv) It compiles with the available system

Explanation

Same as Q77 (2020):

CASE tools support:

• (i) Structured analysis & design - YES
• (ii) Data dictionary maintenance - YES
• (iii) DFD balancing checks - YES
• (iv) Compiling with available system - NOT a CASE use.

Compilers are separate; CASE is for design/analysis automation, not compilation.

Answer: (iv) It compiles with the available system

Answer: (ii) Software Requirement Specification

SRS stands for Software Requirements Specification — the formal document that completely describes the functional and non-functional requirements of the software system to be developed. It acts as the contract/agreement between the customer and the developer and forms the basis for design, implementation, testing, and acceptance.

Why the others are wrong:

• (i) Software Reliability Standard — not a standard term for SRS.
• (iii) Systematic Requirement Strategy — no such standard acronym.
• (iv) Software Risk Solution — no such standard acronym.

So SRS = Software Requirement Specification — option (ii).

Solution

Correct Answer: (ii) Unambiguous

Explanation

An unambiguous SRS ensures that every requirement has exactly one interpretation, so the client, developers and testers all understand it the same way. This is achieved with precise language, defined terms, and formal or structured notations where needed.

Why other options are incorrect:

• (i) Complete - all required functions, constraints and interfaces are included.
• (iii) Consistent - no requirement conflicts with another.
• (iv) Modifiable - the document can be changed easily while keeping its structure.

Key Points to Remember:

Characteristics of a good SRS: correct, unambiguous, complete, consistent, ranked for importance, verifiable, modifiable, traceable.

Answer: (ii) Unambiguous

Answer: (ii) Features the system must perform

Functional requirements describe what the system must do — the specific functions, features, services, or behaviours the software must provide (e.g., "the system shall allow a user to withdraw cash", "the system shall send an e-mail notification"). They define inputs, outputs, and the processing/transformation rules.

By contrast:

• (i) Constraints on the software design — these are design/implementation constraints (often called non-functional or design constraints).
• (iii) Performance and reliability requirements — these are non-functional requirements (quality attributes such as speed, security, availability).
• (iv) Documentation standards — process/standards issues, not functional behaviour.

So functional requirements = features the system must perform — option (ii).

Answer

(iv) Algorithms for software implementation

Explanation

An SRS should describe what the software must do, including functional and non-functional requirements. Detailed implementation algorithms describe how the software will be built and therefore generally belong to design/implementation documentation rather than the SRS.

Final answer: (iv) Algorithms for software implementation

Solution

Correct Answer: (b) MTBF

Explanation

Same as Q28: MTBF = Mean Time Between Failures is standard reliability measure (MTTF+MTTR). Larger MTBF = higher reliability.

Answer: (b) MTBF

Answer: (iii) Serve as a contract between client and developer

The Software Requirements Specification (SRS) is a formal document that completely describes the intended purpose, behaviour, and constraints of the software. Its main purpose is to act as a contract/agreement between the customer (client) and the developer regarding exactly what the software will do — serving as the unambiguous reference for design, development, testing, acceptance, and payment.

Why the others are wrong:

• (i) Describe coding standards — coding standards are separate process documents; the SRS is about what to build, not how to code it.
• (ii) Provide a user manual — a user manual describes the finished product to end users; the SRS is written before development.
• (iv) Define the software test cases — test cases are derived from the SRS (testers use it as a basis), but defining them is a later testing activity.

An SRS therefore captures the complete requirements — functional and non-functional — and underpins the client–developer contract.

Solution

Correct Answer: (d) Algorithms for software implementation

Explanation

Good SRS should contain Functional, Non-functional, Goals of implementation (high-level purpose). It should NOT contain algorithms / design (how to implement) - that is design phase decision. SRS is what not how.

Answer: (d) Algorithms for software implementation

Solution

Correct Answer: (ii) Stakeholder, developer

Explanation

Requirement Analysis - Two Perspectives (Pressman):

• Stakeholder issue - What users/customers want vs what they need (communication gap, conflicting views)
• Developer issue - How to model/specify requirements unambiguously for design

Alternate textbook phrasing also lists Functional vs Non-functional as types of requirements, but issues/problems during analysis are Stakeholder and Developer viewpoints.

Answer: (ii) Stakeholder, developer

Solution

Correct Answer: (i) Decision table

Explanation

A decision table lists conditions and the actions to take for each combination of those conditions, in a compact tabular form. Each column (rule) maps one combination of condition values to its actions, which makes it ideal for complex business logic.

Why other options are incorrect:

• (ii) Data dictionary - stores definitions of data items.
• (iii) Structure chart - shows the module hierarchy and calls.
• (iv) Control-flow graph - shows the flow of control in a program (used for path testing and cyclomatic complexity).

Answer: (i) Decision table

Solution

Correct Answer: (iv) Algorithms for software implementation

Explanation

A good SRS (IEEE 830) should be Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Modifiable, Traceable.

It SHOULD contain:

• Functional requirements (what system does) - (i) required
• Non-functional requirements (performance, reliability, portability) - (ii) required
• Goals of implementation (purpose, scope) - (iii) included at high level

It SHOULD NOT contain:

• (iv) Algorithms for implementation - This is design detail. SRS is what not how. Algorithm, architecture, data structures are decided in design phase, not requirements. Including them makes SRS over-constrained and reduces designer freedom.

Answer: (iv) Algorithms for software implementation

Solution

Full form: CASE = Computer-Aided Software Engineering

CASE Diagram - Components

┌─────────────────────────────────────────┐
│           CASE Environment              │
│  ┌──────────┐  ┌──────────┐  ┌────────┐ │
│  │ Upper CASE│  │Lower CASE│ │Integrated│
│  │(Front-end)│  │(Back-end)│ │ CASE   │ │
│  └──────────┘  └──────────┘  └────────┘ │
│                Repository               │
│  ┌─────────────────────────────────┐    │
│  │  Central Data Dictionary / DB   │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘

Detailed Components:

1. Upper CASE (Front-end / Planning Tools): Supports early SDLC - requirement analysis, DFD/ERD/UML modelling, prototyping, project planning. Ex: Rational Rose, Visible Analyst.

2. Lower CASE (Back-end / Development Tools): Supports later SDLC - code generation, compilation, testing, debugging, reverse engineering. Ex: Compilers, debuggers, test generators.

3. Integrated CASE (I-CASE / Workbench): Combines upper + lower + repository for full lifecycle. Provides seamless integration.

4. Central Repository / Data Dictionary: Heart of CASE - stores all artifacts (requirements, diagrams, code, tests). Ensures consistency, version control.

5. Tools Framework: UI, methodology support, portability, integration services.

Upper = analysis/design, Lower = implementation/testing, I-CASE = end-to-end.

Solution - SRS for Inventory Management System (Retail Medical Store)

SRS Structure (IEEE 830)

1. Introduction

• Purpose: Automate stock management for medicines
• Scope: Purchase, sales, expiry, reorder, GST billing
• Definitions: SKU, Batch No., Expiry Date

2. Overall Description

• Users: Pharmacist, Admin, Supplier
• Constraints: Drug license compliance, barcode hardware

3. Specific Requirements

Functional:

• F1: Add/Update/Delete medicine (name, batch, qty, expiry, supplier, price, GST)
• F2: Stock tracking + low-stock alert (<10) + expiry alert (30 days before)
• F3: Purchase order generation to supplier
• F4: Sales billing with inventory decrement + GST invoice
• F5: Returns & expired stock handling
• F6: Search by name/category/expiry
• F7: Reports: daily sales, stock, profit, expiry

Non-functional: Performance <2s search, security (login), backup, usability.

4. Risk Assessment & Management

Risk	P	Impact	Mitigation
Data loss	M	High	Daily backup, cloud sync
Expired drug sold	M	Critical	Expiry lock, alert
Supplier delay	H	M	Alternate supplier list
Unauthorized access	M	H	Role-based login

Assumptions: Barcode scanner available, GST rates known, internet for backup.

Functional vs Non-Functional Requirements

Functional Requirements

Describe WHAT the system must do — the specific functions, features, services, and behaviours the system must perform. They define inputs, processing, and outputs.

Examples:

• "The system shall allow a user to log in with username and password."
• "The system shall calculate and display the total bill including 18% GST."
• "The system shall send an e-mail notification when an order is shipped."
• "The ATM shall dispense cash only after verifying the PIN."

Non-Functional Requirements

Describe HOW well / under what constraints the system must perform — quality attributes and constraints on the system (not specific behaviours).

Categories & examples:

• Performance: "The system shall respond to a query in under 2 seconds."
• Reliability: "The system shall have 99.9% availability."
• Security: "Only authorized users shall access financial data; passwords stored encrypted."
• Usability: "A new user shall be able to complete registration without help."
• Maintainability/Portability: "The system shall run on Windows, Linux, and macOS."
• Constraints: "Must run on 4 GB RAM; must comply with GDPR."

Comparison table

Aspect	Functional Requirements	Non-Functional Requirements
Defines	What the system does	How well / constraints
Nature	Behaviour/features	Quality attributes
Verifiable by	Functional test cases	Performance/security tests, review
Example	"Withdraw cash", "send email"	"Response < 2 s", "99.9% uptime"
Failure means	Feature missing/wrong	System slow, insecure, unreliable
Priority	Core capability	Often critical for acceptance
Where captured	SRS "specific requirements" section	SRS "non-functional requirements" section

Why the distinction matters

• Ensures both capabilities (functional) and quality (non-functional) are specified and testable.
• Non-functional requirements (especially performance, security, reliability) are as important as functional ones — a system that does the right thing too slowly or inseccurely is not acceptable.

Summary: functional requirements answer what, non-functional answer how well — both are essential in the SRS and both must be verifiable.

SRS-Oriented Requirement Analysis: Hotel Management System

1. Introduction

• Purpose: automate room booking, check-in/out, billing and housekeeping for a hotel.
• Scope: reception, guests, housekeeping, restaurant billing, management reports.
• Users: Guest, Receptionist, Housekeeping staff, Manager/Admin.

2. Major user needs

User	Need
Guest	Search available rooms, book/cancel online, view bill
Receptionist	Quick check-in/out, room allocation, payment collection
Housekeeping	See room status (clean/dirty/occupied), task list
Manager	Occupancy, revenue and staff reports

3. Functional requirements

• FR1 Room management: add/update rooms, types and tariffs; show real-time availability.
• FR2 Reservation: book, modify, cancel a room for given dates; prevent double booking.
• FR3 Check-in/Check-out: record guest ID, allocate room, close the stay.
• FR4 Billing: calculate room charges, taxes, restaurant/service charges; generate invoice.
• FR5 Payment: cash, card and online payment; issue receipt.
• FR6 Housekeeping: update and track room status.
• FR7 Reports: daily occupancy, revenue, guest history.
• FR8 User management: role-based login.

4. Constraints

• Must run on a web browser and a standard database (e.g. MySQL).
• Must follow tax/billing laws and guest-ID record rules.
• Payment through an approved gateway; fixed budget and delivery time.
• Must work with existing hardware (reception PCs, printers).

5. Quality (non-functional) requirements

Quality	Requirement
Performance	Search/booking response within 3 seconds for up to 100 concurrent users
Security	Encrypted passwords, role-based access, secure payments
Reliability/Availability	99.5% uptime; daily backups
Usability	Simple screens; staff trained within one day
Scalability	Support more rooms/branches later
Maintainability	Modular design with documentation

6. Assumptions

Online payment gateway and internet are available; figures such as response time are assumed values.

In the exam, present these in the IEEE SRS layout: Introduction, Overall Description, Specific Requirements.

Requirement Analysis — Definition & Why It Is Critical

Definition

Requirement Analysis (requirements engineering) is the systematic process of:

1. Eliciting (gathering) requirements from stakeholders (users, clients, domain experts),
2. Analyzing & negotiating them (resolving conflicts, prioritizing),
3. Specifying/documenting them in an SRS (Software Requirements Specification),
4. Validating/verifying them (checking correctness, completeness, consistency, feasibility).

It answers the question "What must the software do?" before any design or coding begins.

Why it is the most critical stage of the SDLC

1. Errors here are the costliest. Studies (e.g., Boehm) show that fixing a requirements error after deployment can cost 50–200× more than fixing it during requirements analysis. A wrong requirement propagated through design and code wastes enormous effort.

2. It drives everything downstream. The SRS is the input for design, coding, testing, acceptance, and user documentation. If requirements are wrong/incomplete, every later phase inherits the defect ("garbage in, garbage out").

3. Misunderstanding is the top cause of project failure. The majority of failed/over-budget projects trace back to incomplete requirements and poor communication between stakeholders.

4. It sets the contract baseline. The SRS becomes the agreement between customer and developer: it defines scope, so change control, pricing, and acceptance testing all reference it.

5. It reduces rework and risk. Clear analysis detects incompleteness, ambiguity, and non-feasible demands early — reducing rework, schedule slippage, and cost overruns.

Consequences of skipping it

• Building the wrong product (meets the letter of a misheard requirement, not the user need).
• Scope creep, frequent changes, and endless rework.
• Impossible or un-testable expectations discovered late.

Summary: requirement analysis is critical because its errors are the most expensive to fix, it feeds every subsequent phase, it anchors the client–developer contract, and it is where feasibility and scope are defined.

Software Requirements Specification (SRS) — Overview & Components

What is an SRS?

The Software Requirements Specification (SRS) is a formal, structured document that completely describes the requirements of the software system to be built — its purpose, functions, behaviour, interfaces, and constraints. It is produced in the requirements analysis phase and serves as the contract/reference for design, implementation, testing, and acceptance.

Purpose

• Agreed baseline between customer and developer ("what to build").
• Basis for design, coding, testing (V&V), and user documentation.
• Input for estimation, planning, and change control.

Components / Structure of a good SRS

(1) Introduction

• Purpose of the SRS
• Scope of the product (what it will/won't do)
• Definitions, acronyms, and abbreviations
• References
• Overview of the document

(2) Overall Description

• Product perspective — how the product fits into the larger system (interfaces with other systems).
• Product functions — summary of major functions.
• User characteristics — who will use the system.
• Constraints — regulatory, hardware, standards, security.
• Assumptions and dependencies.

(3) Specific Requirements (the core)

• Functional requirements — each function described precisely (inputs, processing, outputs), uniquely identified, e.g., "FR-1: The system shall allow users to register".
• Non-functional requirements — performance, security, reliability, availability, usability, maintainability, portability.
• External interface requirements — user interfaces, hardware interfaces, software interfaces, communication interfaces.
• Data requirements / logical database requirements — data to be stored and relationships.
• Design constraints — standards compliance, hardware limitations.

(4) Supporting information

• Appendices, index, traceability (each requirement tied to source and to test).

Qualities a good SRS must have

Correct, Unambiguous, Complete, Consistent, Verifiable, Traceable, Modifiable, Ranked for importance (IEEE 830).

Example snippet of a functional requirement

FR-7: The system shall validate the user's login (username + password).
Input: username, password; Output: authenticated session or error message.

Summary

An SRS = Introduction + Overall Description + Specific Requirements (functional + non-functional + interfaces + constraints). Its completeness and clarity determine the success of all downstream phases.

Decision Table: Online Loan-Processing System

Conditions

• C1 Customer eligible? (Y/N)
• C2 Income level adequate? (Y/N)
• C3 Credit score good? (Y/N)
• C4 Documents verified? (Y/N)

Actions

• A1 Approve loan
• A2 Reject loan
• A3 Request additional documents
• A4 Refer to manual review (e.g. reduced amount or higher interest)

Decision table ("-" = don't care)

	R1	R2	R3	R4	R5	R6
C1 Eligible	N	Y	Y	Y	Y	Y
C2 Income adequate	-	-	Y	Y	N	N
C3 Credit score good	-	-	Y	N	Y	N
C4 Documents verified	-	N	Y	Y	Y	Y
A1 Approve loan			X
A2 Reject loan	X					X
A3 Request documents		X
A4 Manual review				X	X

Derived system actions

1. R1: not eligible, so reject whatever the other conditions are.
2. R2: eligible but documents not verified, so request more documents.
3. R3: eligible, income adequate, good credit, documents verified, so approve.
4. R4 / R5: eligible and documents verified, but only one of income/credit is satisfactory, so manual review.
5. R6: eligible and documents verified, but both income and credit are poor, so reject.

Completeness check

Without "don't cares" the table needs 2^4 = 16 rules. R1 covers 8, R2 covers 4, and R3 to R6 cover 1 each (documents verified = Y), so 8 + 4 + 4 = 16: every combination is covered and none overlaps.

The business rules above are assumptions; state them in the exam.

Purpose of the SRS & Qualities of a Good SRS

Purpose of the Software Requirements Specification (SRS)

The SRS is a formal, documented statement of the complete requirements of the software to be built. Its purposes:

1. Contract / agreement baseline — an unambiguous, agreed-upon description of what the system will do, shared by customer and developer (basis for scope, payment, acceptance).
2. Communication medium — a common reference that lets users, analysts, designers, testers, and managers understand the system consistently.
3. Basis for design and implementation — the designer derives architecture/modules from it; the coder implements to it.
4. Basis for testing / V&V — test cases, acceptance tests, and validation criteria are derived from the stated requirements.
5. Input to project planning and estimation — supports effort/cost/schedule estimation and risk analysis.
6. Change control baseline — later change requests are evaluated against the frozen SRS.

Attributes / qualities of a good SRS

A good SRS should be (quoting IEEE 830 standard characteristics):

1. Correct — every requirement stated is one the software shall actually meet (truthfully reflects the real need).
2. Unambiguous — every requirement has exactly one interpretation; no vague words like "fast", "user-friendly", "etc.". (Often checked by formal/structured specification.)
3. Complete — includes all functional and non-functional requirements, all inputs/outputs, all constraints, and defined behaviour for all inputs.
4. Consistent — no requirement conflicts with another (no contradictions between sections).
5. Verifiable — each requirement can be checked/tested by a finite process (e.g., "response < 2 s" is verifiable; "fast" is not).
6. Traceable — each requirement is uniquely identified and traceable to its origin (stakeholder need) and to design/test artifacts.
7. Ranked for importance/stable — requirements are prioritized (e.g., must/should/may) so trade-offs can be made; also modifiable yet controlled by change management.
8. Modifiable — structured so that changes can be made consistently without rewriting the document.

Structure (typical)

• Introduction (purpose, scope, definitions, references, overview)
• Overall description (product perspective, functions, user characteristics, constraints, assumptions)
• Specific requirements (functional requirements, non-functional requirements — performance, security, reliability, portability; external interfaces; design constraints)
• Appendices/index

Summary: the SRS is the agreed definition of "what to build"; a good one is correct, unambiguous, complete, consistent, verifiable, and traceable.

Solution

CASE Tools

Definition: Software tools that automate/mamper SDLC activities (see Q110).

Categories (with Diagram)

CASE Tools
   ├─ Upper CASE (Front-end) - Planning/Analysis: DFD, ERD, SRS
   ├─ Lower CASE (Back-end) - Coding/Testing: compilers, debuggers
   └─ Integrated CASE - Covers entire lifecycle + Repository

Detailed Categories:

1. Business Planning Tools - Project estimation (COCOMO tools)
2. Project Management Tools - Gantt/PERT (MS Project), tracking
3. Support Tools - Documentation, DB design, configuration
4. Analysis & Design Tools - UML (Rational Rose), DFD editors
5. Programming Tools - Code generators, compilers, 4GL
6. Integration & Testing Tools - Test case generators, coverage analyzers
7. Maintenance Tools - Reverse engineering, re-engineering

Diagram shows Upper → Design, Lower → Implementation, Repository central.

Solution

SRS - Software Requirements Specification

Definition: Complete description of what system must do (IEEE 830). Serves as contract between client & developer.

Features of SRS

Characteristics of Good SRS:

• Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Modifiable, Traceable
• Clear, concise, with glossary

Features / Contents:

• Functional Requirements - What system does (use cases)
• Non-functional - Performance, reliability, portability
• External Interfaces - User, hardware, software, communication
• Design Constraints - Standards, hardware limits
• Goals of Implementation - Purpose, scope, business goals (high level)
• Excluded: Algorithms, architecture, design details (how)

See IEEE structure in Q121.

Solution - IEEE SRS Structure (IEEE 830-1998)

1. Introduction

• 1.1 Purpose
• 1.2 Scope
• 1.3 Definitions, Acronyms, Abbreviations
• 1.4 References
• 1.5 Overview

2. Overall Description

• 2.1 Product Perspective (interfaces, context)
• 2.2 Product Functions (summary)
• 2.3 User Characteristics
• 2.4 Constraints (regulatory, hardware)
• 2.5 Assumptions and Dependencies

3. Specific Requirements

• 3.1 External Interfaces (User, Hardware, Software, Comm)
• 3.2 Functional Requirements (by feature/use case)
• 3.3 Performance Requirements
• 3.4 Design Constraints
• 3.5 Software System Attributes (Reliability, Availability, Security, Maintainability, Portability)
• 3.6 Other Requirements (DB, operations)

Appendices: Index

Good SRS is Correct, Unambiguous, Complete, Consistent, Ranked, Verifiable, Modifiable, Traceable.

Solution

Reliability

Probability of failure-free operation for specified time in specified environment.

ROCOF, MTTF, MTTR with Example

• ROCOF = Rate of Occurrence of Failures - Failures per unit time. Ex: 2 failures/year → ROCOF=2/yr, higher ROCOF = less reliable. Reciprocal of MTBF in steady state.

• MTTF = Mean Time To Failure - Average time system runs before failing (for non-repairable). Ex: 5 printers fail avg after 1000 hours → MTTF=1000h.

• MTTR = Mean Time To Repair - Avg time to repair. Ex: Avg 2 hours to fix printer → MTTR=2h.

Relations:

• MTBF = MTTF + MTTR (for repairable)
• Availability = MTTF / (MTTF+MTTR) - Ex: MTTF=1000h, MTTR=10h → Availability=1000/1010=99%
• Reliability function $R(t)=e^{-λt}$ where $λ=ROCOF$

Example: E-commerce server: MTTF=500h, MTTR=5h → MTBF=505h, Availability=99%, ROCOF≈0.002 failures/hour.

Functional and Non-functional Requirements

Functional requirements (FR)

Describe what the system must do: its functions, features, inputs, processing and outputs.

• Example (online shopping): The system shall allow a user to add items to a cart, place an order and receive an order confirmation.
• Written as "The system shall..."; tested by black-box functional tests.

Non-functional requirements (NFR)

Describe how well the system must work: quality attributes and constraints.

• Categories: performance, security, reliability, availability, usability, portability, maintainability, scalability, plus legal and standards constraints.
• Example: The system shall respond to a search within 2 seconds for 500 simultaneous users.

Comparison

Basis	Functional	Non-functional
Describes	What the system does	How the system performs (quality)
Focus	Features and behavior	Quality attributes and constraints
Source	User/business needs	Standards, constraints, quality goals
Verification	Functional testing	Performance, security, usability testing
If missing	System cannot do its job	System is unusable, slow or unsafe
Example	Login, generate invoice	Login in under 2 s, 99.9% uptime

Importance

Both must be recorded in the SRS. A system that meets all functional requirements but fails its NFRs (slow, insecure) is still a failure.

Barriers to Eliciting User Requirements

Requirements elicitation is the process of gathering requirements from stakeholders (users, clients, domain experts). Several barriers make it difficult to obtain complete, accurate, and consistent requirements.

1. Communication barriers / different vocabularies

Users describe needs in business/domain terms, while developers think in technical terms — the "language gap." Terms like "fast", "easy", "report", or "processing" mean different things to each side, causing misunderstandings and ambiguous requirements.

2. Tacit / unstated knowledge ("users don't know what they want")

Users often cannot articulate their real needs because the work is automatic/habitual for them. They may also not know the possibilities of software, so they under-specify or ask for what's easy to describe rather than what is needed.

3. Social and political barriers (organizational conflict)

Stakeholders have conflicting objectives and priorities; different departments/users may compete for limited resources or disagree on who the system should favour. Users may fear job loss, loss of autonomy/power, or added work, so they resist or withhold information. Reluctance to delegate decisions leads to bottlenecks.

4. Volatile / changing requirements

Requirements change over time — the business, market, technology, or user understanding evolves during the project. Elicited requirements may be obsolete by the time they are implemented, and users keep adding "corrections."

5. Incomplete knowledge of the problem domain

The analyst may not understand the business process deeply; users may reveal requirements incrementally only as prototypes emerge. Domain complexity (regulations, workflows) is hard to capture fully in one pass.

6. Undiscoverable/implied requirements ("whatever is cheapest/fastest")

Stakeholders often assume certain things are obvious and omit them; ambiguity in terminology/scope leads the developer to guess, producing wrong assumptions that surface much later.

7. Lack of stakeholder availability/commitment

Busy users give limited time; meetings are skipped; priorities are low — resulting in incomplete elicitation. Without a committed "champion," requirements gather slowly and inaccurately.

8. Ambiguity & interpretation of requirements data

Even recorded requirements can be ambiguous — multiple interpretations (see IEEE's unambiguous characteristic). Requirements that cannot be verified and are not traceable create confusion later.

How to reduce these barriers (brief)

• Structured elicitation techniques: interviews, questionnaires, brainstorming, focus groups, facilitated workshops (JAD — Joint Application Development), prototyping, use cases/user stories, observation, and document analysis.
• Iterative elicitation: involve users throughout; prototype to reveal implicit needs.
• Formalize & validate: record in the SRS, review with all stakeholders, use verification/validation to resolve ambiguity and conflicts.

Summary table

Barrier	Nature	Mitigation
Communication gap	Different vocabularies	Workshops, JAD, visual models
Tacit knowledge	Users can't express needs	Prototyping, observation, scenarios
Politics/conflict	Conflicting interests & fears	Facilitated negotiation, stakeholder management
Volatility	Requirements drift	Change control, iterative development
Domain complexity	Analyst lacks domain knowledge	Domain experts, iteration
Unstated assumptions	Hidden/implied needs	Questioning, checklists, formal SRS review
Low availability	Users not engaged	Scheduling, sponsorship, champions
Ambiguity	Multiple interpretations	Unambiguous SRS, validation

Summary: the main barriers to eliciting user requirements are communication gaps, tacit/unarticulated knowledge, socio-political conflicts among stakeholders, requirement volatility, domain complexity, unstated assumptions, limited stakeholder availability, and ambiguity — all best overcome with structured techniques, iteration, prototypes, and formal SRS validation.

SRS Standards (IEEE)

An SRS (Software Requirements Specification) is the document that states what the software must do and acts as an agreement between client and developer. Standards give a common structure so every SRS is complete and consistent.

Main standards

• IEEE 830-1998: Recommended Practice for Software Requirements Specifications (the classic SRS format used in syllabi).
• ISO/IEC/IEEE 29148:2018: the current standard that replaced IEEE 830 and covers requirements engineering processes and documents.

IEEE 830 structure

1. Introduction
   • 1.1 Purpose, 1.2 Scope, 1.3 Definitions, acronyms, abbreviations, 1.4 References, 1.5 Overview
2. Overall description
   • 2.1 Product perspective, 2.2 Product functions, 2.3 User characteristics, 2.4 Constraints, 2.5 Assumptions and dependencies
3. Specific requirements
   • External interfaces (user, hardware, software, communication)
   • Functional requirements
   • Performance requirements
   • Design constraints
   • Software system attributes (reliability, availability, security, maintainability, portability)
   • Other requirements
4. Appendices and index

Characteristics of a good SRS (IEEE 830)

Correct, unambiguous, complete, consistent, ranked for importance/stability, verifiable, modifiable, traceable.

Benefits of following a standard

• Common understanding between client, analysts and developers
• Fewer missing or conflicting requirements
• Easier review, testing and maintenance
• Basis for estimating cost and schedule