Requirements in Software Engineering

1. Definition

o Requirements describe what a system should do (services it provides) and the constraints
under which it operates.

o They reflect customer needs for achieving a specific purpose (e.g., controlling a device,
placing an order, finding information).

2. Requirements Engineering (RE)

o The process of finding out, analyzing, documenting, and checking system services and
constraints.

3. Inconsistency of the Term "Requirement"

o Sometimes means high-level, abstract statements of services/constraints.

o Sometimes means a detailed, formal definition of system functions.

o Difference arises due to:

▪ Clients/contracting stage → abstract, solution-independent requirements.

▪ Post-contract stage → detailed system definitions for validation and development.

4. Types of Requirements

o User Requirements

▪ High-level, abstract statements of what services the system should provide.

▪ Expressed in natural language + diagrams.

▪ Focused on what the system should do for the end-user.

o System Requirements

▪ More detailed, precise descriptions of system functions, services, and constraints.

▪ Defines exactly what is to be implemented.

▪ Sometimes called Functional Specification.

▪ May form part of the contract between buyer and developers.

Illustration (MHC-PMS example)

• One user requirement can expand into multiple detailed system requirements.

• Example:

o User Requirement: "The system shall generate reports of patient visits."

 o System Requirements:

▪ The system shall allow authorized staff to select a date range.

▪ The system shall retrieve visit records within that range.

▪ The system shall format data into a printable report.

• Traditional vs Agile View

o Traditional:
▪ Large systems usually have a separate requirements phase before
implementation.
▪ A requirements document is the main outcome (part of contract).
▪ Requirements may change later, and user reqs may be expanded into system
reqs.
o Agile:
▪ Requirements elicitation and system development are done concurrently.
▪ Rarely used in very large systems.

Functional and Non-Functional Requirements

Functional Requirements
1. Definition

• Functional requirements describe what the system should do.

• They depend on:

o The type of software being developed.

o Who the expected users are.

o The organization’s approach to writing requirements.

2. Levels of Functional Requirements

• User-level functional requirements

o Written in abstract language (simple, high-level).

o Easy for users and clients to understand.

• System-level functional requirements

o More detailed and technical.

 o Describe:

▪ Specific functions

▪ Inputs and outputs

▪ Exceptions or error handling

▪ Rules and workflows

3. Example: Book My Show (Online Movie Ticket Booking System)

Requirement 1 (High-level, Abstract):

• A user shall be able to search for movies, events, or shows based on location and date.

Requirement 2 (Medium-level, Semi-detailed):

• The system shall allow users to select preferred seats from the available seating layout before
booking.

Requirement 3 (Very Specific, Detailed):

• Each booked ticket shall be uniquely identified by a 12-digit alphanumeric booking ID, linked to the
user’s registered mobile number and email.

Notice:

• Requirement 1 = Abstract, User-level (easy to understand).

• Requirement 2 = More detailed, closer to system-level.

• Requirement 3 = Highly specific, System-level (developers’ perspective).

4. Problems of Imprecision

• Ambiguity (understanding more than single way) in functional requirements is a major cause of
software engineering problems.

• Developers may interpret vague requirements differently from what the customer expects.

• Example:

o Requirement: “Search appointments lists for all clinics.”

o Medical staff expected: Enter a patient’s name → system searches across all clinics.

o Developer may implement: User must first select a clinic, then search → more effort, less
user-friendly.

• Result:

o Misunderstandings
 o Rework (new requirements, system changes)

o Increased costs and delays

5. Qualities of Good Functional Requirements

• Complete:

o Must define all services the user needs.

• Consistent:

o Must not have contradictions.

In practice, for large/complex systems:

• It is almost impossible to achieve 100% completeness and consistency.

• Reasons:

1. Human error → mistakes/omissions in specifications.

2. Multiple stakeholders with different or conflicting needs.

3. Inconsistencies often appear later during analysis or after delivery.

6. Domain Requirements

• Definition:
Domain requirements come from the application domain (the real-world area where the
system will be used). They are not always directly stated by the user but are essential
because of the rules, constraints, and practices of that domain.
• Roles of Domain Requirements:

o Introduce new functional requirements.

o Constrain existing requirements.

o Specify how certain computations must be performed.

• Problem:

o Software engineers may not fully understand the domain.

o They may:

▪ Miss out key requirements.

▪ Write conflicting requirements.

Domain Requirements in Swiggy

Domain = Food Delivery Industry

1. Introduce new functional requirements

• Domain knowledge: In food delivery, orders must be delivered within a certain time for
freshness.

• Requirement: The system shall display the estimated delivery time before placing the order.

Without knowing the food delivery domain, an engineer might not realize that time estimation is
critical.

2. Constrain existing requirements

• Functional requirement: A user can cancel an order.

• Domain constraint: If the restaurant has already prepared the food, cancellation should not
be allowed.

• So, the domain restricts the cancellation feature.

3. Specify how computations must be performed

• In food delivery, the delivery fee is not random.

• Domain rule: Delivery charges depend on distance, time of day (peak hours), and surge
pricing.

• Requirement: The system shall calculate delivery charges based on distance × base rate +
surge factor.

This comes directly from the business domain (not just user wishes).

Problem

If engineers don’t fully understand the food delivery domain:

• They may miss rules (e.g., surge pricing).

• They may conflict requirements (e.g., allowing free cancellation anytime, which restaurants
won’t accept).

Non-Functional Requirements (NFRs)

Definition:

• They are requirements that describe how the system should work, not what it should do.

• Focus on system qualities (performance, security, usability, reliability, etc.).

 • Often more critical than functional requirements, because if NFRs fail, the whole system might be
unusable.

Types of Non-Functional Requirements

1. Product Requirements (qualities of the software itself)

o Efficiency → how fast the system runs (response time, memory use).

▪ Performance → system speed and throughput.

▪ Space → memory/disk space needed.

o Dependability → reliability, availability, fault-tolerance.

o Security → protection against unauthorized access.

o Usability → ease of use for users.

2. Organizational Requirements (come from company rules/policies)

o Operational → how the system will be used in daily work.

o Development → programming language, standards, or tools to use.

o Environmental → system’s operating environment (e.g., must run on Windows/Linux).

3. External Requirements (come from outside factors)

o Regulatory → rules from regulators (e.g., medical standards, banking laws).

o Ethical → system should respect privacy, fairness, etc.

o Legislative → legal requirements (e.g., data protection laws).

▪ Accounting → financial rules (reporting, audits).

 ▪ Safety/Security → must ensure user and data safety.

Key Insights

• NFRs affect the entire system, not just one feature.

• They often influence architecture and design (e.g., security may require authentication services
everywhere).

• They can create new functional requirements (e.g., login with card swipe for security).

• They are often written in measurable terms so they can be tested.

o Example: “System should respond within 2 seconds” (measurable).

o Vs “System should be fast” (too vague).

• Sometimes NFRs conflict with each other (e.g., security vs. usability).

Software Requirements Specification Document (SRS)

1. What it is:

o A written agreement of what the software should do.

o Includes both user needs (what users want) and system requirements (technical details).

2. Why it is needed:

o Guides developers, testers, and managers.

 o Helps avoid confusion and misunderstandings.

o Very important if an outside company is building the software.

3. Agile vs Traditional:

o In Agile, requirements change often → use short notes (user stories) instead of a big
document.

o Still, a short document is useful to record important business and reliability needs.

4. Who uses it:

5. Level of detail depends on project:

o Critical systems (e.g., medical, flight software) → very detailed.

o Outsourced projects → very detailed and precise.

o In-house/iterative projects → less detailed, changes handled during development.

6. Typical structure (based on IEEE standard):

o Introduction

o General description of system

o Functional & non-functional requirements

o Models/diagrams (if needed)

o Future changes (evolution requirements)

 o Glossary, references, index

7. Other notes:

o For large documents, add table of contents & index so people can easily find things.

o Helps keep track of system evolution and avoid design mistakes.

Requirements Specification
1. What is Requirements Specification?

• Definition:
The process of writing down all the requirements of a system in a document so that
everyone (users, developers, testers, managers) has a common understanding.

• Purpose:

o To avoid confusion later during design, coding, and testing.

o To make sure the system being built actually matches the needs of users.

• Qualities of a good requirements specification:

1. Clear → easy to read and understand.

2. Unambiguous → no double meaning.

3. Complete → nothing important is missing.

4. Consistent → no conflicts between different requirements.

• Problem in practice:

o Different stakeholders often interpret requirements differently.

o Conflicts and misunderstandings are common.

Write about User Requirements and System Requirements

2. Why Requirements Documents Avoid Design Details?

When writing requirements, the focus should be on what the system should do, not how it will be
built.
But in reality, sometimes design details creep in because:
 1. Initial architecture is needed → Helps structure the requirements by dividing them into
subsystems.

2. Existing systems → The new system must work together with old ones, which creates
design restrictions.

3. Non-functional needs → For example, safety, security, or reliability may require a specific
architecture or technology.

3. Approaches to Writing Requirements

A) Natural Language Specification

• What it is: Writing requirements in plain English (or any natural language).

• Why used: It is universal, expressive, and easy for everyone to read.

• Weakness: Can be vague and open to interpretation.

Guidelines for writing better natural language requirements:

1. Use a standard format for all requirements (so they look uniform).

2. Distinguish between:

o Mandatory requirements → use “shall”.

o Desirable requirements → use “should”.

3. Use highlighting (bold, italics, underline) for important parts.

4. Avoid technical jargon, acronyms, abbreviations.

5. Provide a rationale (reason for including the requirement and its source).

Example:

• Requirement: “The ATM shall allow users to withdraw cash within 30 seconds of request.”

• Rationale: “Fast transaction improves customer satisfaction.”

B) Structured Specifications

• What it is: Requirements written in a standard template or structured form instead of free
text.

• Why used: Helps to avoid ambiguity and ensures all important information is included.
 • How it works: Each requirement has fixed fields to fill, like a form.

Common fields included in structured specifications:

1. Description → What the function/feature does.

2. Inputs → What data it receives and from where.

3. Outputs → What it produces and where it goes.

4. Requirements/Dependencies → What it needs to work.

5. Action → The actual processing or behavior.

6. Pre-condition → What must be true before it runs.

7. Post-condition → What must be true after it runs.

8. Side effects → Any additional changes.

Advantage:

• Clearer and more systematic than natural language.

Example:

• Function: Calculate blood sugar dose in insulin pump.

• Input: Blood sugar levels.

• Output: Amount of insulin.

• Pre-condition: Blood sugar data available.

• Post-condition: Correct insulin delivered.

C) Graphical Models

• What it is: Using diagrams to show requirements.

• When useful:

o To explain state changes (system goes from one situation to another).

o To explain sequence of actions (steps taken after an event).

Examples of graphical models:

1. UML Sequence Diagrams → Show flow of messages between components over time.
 2. State Charts → Show different states of a system and transitions.

Advantage:

• Easier to visualize complex behaviors than plain text.

Example:
In an ATM:

• States: Idle → Card Inserted → PIN Verified → Transaction in Progress → Cash Dispensed
→ Idle again.

D) Mathematical Specifications

• What it is: Writing requirements using mathematical formulas or logic.

• Where used:

o In safety-critical or security-critical systems (e.g., aviation software, nuclear plants,

medical devices).

• Advantage: Very precise, avoids all ambiguity.

• Disadvantage: Hard for normal users to understand.

Example:
Instead of writing “The system shall check user login”, you write a mathematical condition:
If (entered_password == stored_password) → login_success.

4. Enhancing Requirements

Sometimes natural or structured specifications are not enough. Extra tools can be used:

1. Tables → To handle multiple conditions and outcomes.

o Example: Insulin pump uses a table to decide insulin dose based on the rate of blood
sugar change.

2. Diagrams → For user interaction, system state changes, or workflows.

3. Supporting materials → Screenshots, mock-ups, or prototypes to clarify.

5. Key Takeaways

• Requirements specification = documenting what the system should do.

• Needs to be clear, complete, consistent, unambiguous.

• Should focus on behavior not design (but some design leaks in).

• Writing methods:

o Natural language (simple but vague).

o Structured forms (organized, less ambiguity).

o Graphical models (visual, good for processes).

o Mathematical models (precise, used in critical systems).

• Best practice = combine natural language + diagrams + tables.