Chapter 4: System Requirements

🎯 Learning Objectives

By the end of this study session, you’ll be able to:

Distinguish clearly between user requirements and system requirements and explain why we need both levels of detail
Write effective user requirements that capture what stakeholders actually need in plain, understandable language
Create detailed system requirements that developers can use as blueprints for building software
Identify and categorize functional vs. non-functional requirements and understand why both are crucial for system success
Recognize the three main types of non-functional requirements (Product, Organizational, External) and provide examples of each
Explain why natural language creates problems in requirements documentation and identify specific issues like ambiguity and confusion
Choose appropriate notation methods for documenting system requirements (structured natural language, design description languages, graphical notations, mathematical specifications)
Understand the complete structure of a Software Requirements Specification (SRS) document and know what goes in each section
Identify who uses SRS documents and why different stakeholders need requirements documentation

🌟 The Big Picture

Think of system requirements as the bridge between “what people want” and “what developers build.” Imagine you’re planning to build your dream house - you wouldn’t just tell the architect “I want a nice house,” right? You’d need to specify how many bedrooms, what style, what materials, where the kitchen goes, etc.

Software requirements work exactly the same way! We start with high-level user needs (like “I want the system to help me buy concert tickets online”) and then break those down into incredibly detailed specifications that programmers can actually implement (like “When a user clicks ‘Buy Ticket,’ the system shall validate payment details within 3 seconds and update seat availability in real-time”).

This chapter teaches you how to make that translation happen effectively, avoiding the common pitfalls that lead to failed software projects. Remember: most software projects fail not because of bad code, but because of unclear or missing requirements!

📚 Core Concepts

Understanding the Two Levels: User vs. System Requirements

Let’s start with the fundamental distinction that forms the backbone of all requirements work.

User Requirements: The “What” from a Human Perspective

User requirements represent what people actually need from the system, written in language that real humans can understand. Think of these as the “big picture” statements that answer the question: “What problem are we trying to solve?”

Key characteristics:

High-level and abstract - they don’t get bogged down in technical details
Written for users and decision-makers - the people who will actually use the system or pay for it
Use natural language with simple diagrams and tables - no technical jargon required
Focus on business goals and user needs - why does this system matter?

Visual Reference (Slide 3):

The slide shows a construction worker with a hard hat holding documents, representing the user perspective - someone who needs to understand requirements without technical complexity.

System Requirements: The “How” with Technical Precision

System requirements take those user needs and break them down into detailed, technical specifications that developers can actually build from. These are your blueprint - precise, complete, and unambiguous.

Key characteristics:

Precise and detailed descriptions - leave no room for guessing
Extended versions of user requirements - they elaborate on every aspect
Use structured natural language supported by models and tables - more formal but still readable
Created during requirements analysis - this is where the real detective work happens
Serve as the starting point for design - developers use these as their roadmap
Also known as Functional Specifications - some textbooks use this term interchangeably
Form a contract between developer and customer - legally binding expectations

Visual Reference (Slide 4):

Shows a person working at a laptop with documents, representing the more technical, detailed work required for system requirements.

The Perfect Example: LIBSYS Concert Tickets

Visual Reference (Slide 7):

The document provides a brilliant real-world example that shows exactly how user requirements expand into system requirements:

User Requirement: “LIBSYS shall keep track of all data required by copyright licensing agencies in the UK and elsewhere”

System Requirements (the detailed breakdown): 1.1 On making a request for a document from LIBSYS, the requestor shall be presented with a form that records details of the user and the request made. 1.2 LIBSYS request forms shall be stored on the system for five years from the date of the request. 1.3 All LIBSYS request forms must be indexed by user, by name of the material requested and by the supplier of the request. 1.4 LIBSYS shall maintain a log of all requests that have been made to the system. 1.5 For material where authors’ lending rights apply, loan details shall be sent monthly to copyright licensing agencies that have registered with LIBSYS.

See how one simple user need explodes into five detailed technical requirements? That’s the magic (and necessity) of requirements analysis!

Who Actually Reads These Documents?

Visual Reference (Slide 6):

Understanding your audience helps you write better requirements:

User Requirements Readers:

Client Managers (the people paying for the system)
Contractor Managers (the people building the system)
System End-Users (the people who will actually use it daily)
Client Engineers (technical people on the customer side)
System Architects (high-level technical designers)

System Requirements Readers:

Software Developers (the people writing the code)
System End-Users (they need to verify the details are correct)
Client Engineers (technical validation)
System Architects (detailed design planning)

Notice how system end-users appear in both lists - they need to understand the big picture AND verify the technical details are correct!

Functional vs. Non-Functional Requirements

Visual Reference (Slide 13):

The document shows a clear hierarchy: Software System Requirements split into two main branches.

Now let’s dive into the two fundamental types of requirements that every system needs.

Functional Requirements: The “What Does It Do?”

Visual Reference (Slide 14):

Shows a technician with tools, representing the active work the system performs.

Functional requirements describe the actual work your system performs - the services it provides, how it reacts to inputs, how it behaves in different situations, and importantly, what it should NOT do.

Think of functional requirements as answering these questions:

What services does the system provide?
How does the system react to particular inputs?
How does the system behave in particular situations?
What should the system NOT do?

Real Example from HR System (Slide 15):

Here’s a perfect example of functional requirements from an Employee Self-Service system:

1.0 Basic Personal Tasks 1.1 Employees can perform routine HR administration tasks such as changing name, address, home/work telephone numbers, emergency contacts, next of kin, marriage, births or adoption details 1.2 Employees can upload common information to existing databases e.g. telephone directories and organization charts 1.3 Employees can view employees own employment history i.e. promotions, dates, appraisal reviews, training records 1.4 Employees can view conditions of employment, HR policies, procedures, information packs, benefits details

Notice how each requirement uses action verbs (perform, upload, view) - that’s your clue that these are functional requirements!

Non-Functional Requirements: The “How Well Does It Do It?”

Visual Reference (Slide 16):

Shows puzzle pieces coming together, representing how constraints fit together to shape the system.

Non-functional requirements are like the quality standards for your system - they don’t describe what it does, but how well it does it. These are often the make-or-break factors for user satisfaction!

The Three Categories of Non-Functional Requirements

Visual Reference (Slides 18-20):

The document shows a comprehensive breakdown of non-functional requirements into three main categories:

1. Product Requirements (How the product itself must perform)

Usability: How easy is it to use?
Efficiency: How fast and resource-efficient is it?
Performance: How quickly does it respond?
Space: How much memory/storage does it need?
Reliability: How often does it break down?
Portability: Can it run on different systems?

2. Process/Organizational Requirements (How it fits your organization)

Delivery: When and how should it be delivered?
Implementation: What programming languages, tools, or methods must be used?
Standards: What company or industry standards must it follow?

3. External Requirements (How it meets outside world demands)

Interoperability: How well does it work with other systems?
Ethical: Does it meet moral and ethical standards?
Legislative: Does it comply with laws and regulations?
Privacy: How does it protect personal information?
Safety: How does it prevent harm to users or environment?

Real Examples from LIBSYS (Slides 21-22):

Product Requirement Example: “The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.” This constrains the technology choices for usability reasons.

Organizational Requirement Example:
“The system development process and deliverable documents shall conform to the process and deliverables defined in XYZ-ST95.” This ensures the project follows company standards.

External Requirement Example: “The system shall not disclose any personal information about system users apart from their name and library reference number to library staff who use the system.” This meets privacy and legal requirements.

The Concert Ticket Example: Putting It All Together

Visual Reference (Slides 9-11):

Let’s walk through the complete concert ticket example to see how this all works in practice:

User Requirement: “The system must provide a facility which allows the online users to check on concert details, seat availability and purchase tickets”

System Requirements (the detailed breakdown): 1.1 The system allows the online users to view concert’s details 1.2 The users can check the seat availability for the concert they are interested in
1.3 The users can select the seating position available and make a purchase for the ticket(s) 1.4 The system will calculate the charges once the user confirmed the transaction 1.5 The system will also check on the payment details such credit card number and etc. 1.6 If invalid payment details, the system will show message 1.7 If valid, the system will proceed transaction and update the seat(s) to not available 1.8 The system will generate on-line receipt

Now let’s add some functional and non-functional requirements:

Functional Requirements (what the system does):

Process credit card payments
Generate electronic receipts

Non-Functional Requirements (how well it performs):

Performance: Payment processing must complete within 30 seconds
Security: All credit card information must be encrypted during transmission

Why Natural Language Creates Problems

Visual Reference (Slides 24-31):

The document shows a word cloud around “NATURAL LANGUAGE” with question marks, highlighting the confusion natural language can create.

Even though we use natural language (like English) to write requirements, it creates serious problems that can derail entire projects. Let’s understand why and what we can do about it.

The Core Problems with Natural Language

Visual Reference (Slide 25):

Shows various problems radiating from the natural language word cloud:

1. Lack of Clarity

Ambiguity: Words can mean different things to different people
Imprecision: Vague statements that could be interpreted multiple ways
Wordiness: Too much text makes it difficult to extract the actual requirements
Difficult to read: Complex sentences hide the real meaning

Visual Reference (Slide 26):

2. Requirement Confusion

Functional vs. non-functional mixing: People often blend what the system does with how well it should do it
System goals vs. specific requirements: High-level visions get mixed with detailed specifications
Design info creeping in: People start describing solutions instead of problems

Visual Reference (Slide 27):

3. Amalgamation

Multiple requirements get smooshed together into single, complex statements
This makes it impossible to track which requirements have been implemented

The Perfect Example of Natural Language Problems (Slide 28):

Here’s a real requirement that demonstrates multiple problems:

“LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.”

Problems with this requirement:

Amalgamation: This is actually TWO different requirements mashed together
Functional requirement 1: Payment record maintenance (Add, Edit, Delete functionality)
Functional requirement 2: Discount rate configuration
Unclear scope: What exactly does “maintains records” mean?
Ambiguous terms: What defines a “regular user”?

Why Natural Language Fails Us (Slides 29-31):

Reason 1: Same Words, Different Meanings

Visual Reference (Slide 29):

Shows different images for the word “Tool” - could mean a wrench, software application, or computer hardware. Everyone assumes their interpretation is correct!

Reason 2: Over-Flexibility

Visual Reference (Slide 30):

Shows two people talking, illustrating that the same concept can be expressed in countless different ways, leading to confusion and misinterpretation.

Reason 3: No Clear Structure

Visual Reference (Slide 31):

Shows a folder icon, representing how natural language doesn’t provide clear organization. Diagrams and structured approaches work much better for complex requirements.

Solutions: Better Ways to Document Requirements

Visual Reference (Slides 33-37):

The document outlines four main approaches to improve requirements documentation:

1. Structured Natural Language

Uses decision tables and templates for system input, process, and output (like data dictionaries)
More organized than pure natural language but still readable

2. Design Description Languages

Programming-language-like approaches such as PSL/PSA and RSL
More precise than natural language but requires technical expertise

3. Graphical Notations

Data Flow Diagrams (DFDs) - show how data moves through the system
Sequence Diagrams - show how different parts interact over time
Visual representations that can communicate complex relationships clearly

4. Mathematical Specifications

Finite-state machines - for systems with clear states and transitions
Z-specification - formal mathematical notation for precise requirements
Most precise but requires mathematical sophistication

The Software Requirements Specification (SRS) Document

Visual Reference (Slide 38):

Shows a red folder icon representing the official SRS document.

Now let’s talk about how all these requirements get organized into a comprehensive document that serves as the official blueprint for your software project.

What Makes an SRS Special

Visual Reference (Slide 39):

The SRS serves as the official statement that contains both User Requirements and System Requirements in one organized package.

Visual Reference (Slide 40):

Key Principles for a Good SRS:

Specify WHAT without HOW - describe the problem, not the solution
Complete & consistent - cover everything without contradictions
No conflicts - requirements shouldn’t fight with each other

Who Uses the SRS Document

Visual Reference (Slide 41):

Shows different user groups around a central team icon:

System Customers - people paying for the system
Project Managers - people coordinating the development
System Engineers - people designing the technical architecture
System Test Engineers - people verifying the system works correctly
System Maintenance Engineers - people who will update and fix the system later

Each group needs the SRS for different reasons, which is why it must be comprehensive yet accessible.

The Complete SRS Structure

Visual Reference (Slides 42-52):

Here’s the complete structure of a professional SRS document:

1. Preface

Document overview and authorship information

2. Introduction

Purpose: Why does this document exist?
Scope: What’s included and what’s not?
Overview: High-level summary of the system
Business Context: How does this fit into the bigger picture?

3. Glossary

Definition of terms: Essential for avoiding misunderstandings

4. User Requirements Definition

General user needs expressed in natural language

5. System Architecture

Visual Reference (Slide 45):

Shows a detailed system diagram with components like Teacher, Student, Authoring Tool, Items Bank, Scorer, and Remote Test Module, illustrating how the system pieces fit together.

6. System Requirements Specification

Functional requirements - what the system does
Non-functional requirements - how well it performs
Interface requirements - how it connects with other systems
Performance requirements - specific speed and capacity needs

7. System Models

Diagrams and formal representations (references Chapter 6 of the textbook)

8. System Evolution

Version control and change management (references Chapter 11)

9. Appendices

References and supporting documents - all the background material

10. Index

Visual Reference (Slide 50):

Shows a sample index page with alphabetically organized terms and page numbers, making the document easy to navigate.

Additional Sections (when needed):

Hardware requirements - specific equipment needs
Database requirements - data storage and management needs

🔄 Connections and Review

Let’s tie everything together and see how these concepts work as a unified system for capturing what software should do.

The Requirements Journey: From Vague Ideas to Precise Specifications

Think of requirements development as a translation process:

Start with user needs (often vague): “I want to buy concert tickets online”
Create clear user requirements (understandable): “The system must provide a facility for checking concert details, seat availability, and purchasing tickets”
Develop detailed system requirements (implementable): Eight specific technical requirements covering forms, calculations, validation, updates, and receipts
Add functional requirements (what it does): Process payments, generate receipts
Include non-functional requirements (how well): 30-second response time, encrypted transmission
Document everything in an SRS (official contract): Complete specification for developers

Why This Matters for Your Career

Whether you become a developer, project manager, business analyst, or system administrator, you’ll encounter requirements in every software project. Understanding how to:

Write clear user requirements helps you communicate with stakeholders
Create detailed system requirements ensures developers build what’s actually needed
Distinguish functional from non-functional prevents you from forgetting critical quality attributes
Recognize natural language problems saves projects from expensive misunderstandings
Choose appropriate documentation methods makes your specifications more effective
Structure an SRS properly creates professional documentation that teams can actually use

The Big Lesson: Requirements Are About Communication

Remember, requirements are fundamentally about communication - they’re how we translate human needs into technical solutions. Every technique we’ve covered (user vs. system requirements, functional vs. non-functional, structured documentation) exists to make that communication clearer and more effective.

The best software engineers aren’t just good at writing code - they’re excellent at understanding what people really need and translating those needs into precise, implementable specifications. Master these requirements skills, and you’ll be valuable in any software project!

Final thought: Most software projects that fail don’t fail because of bad programming - they fail because of unclear, incomplete, or misunderstood requirements. The investment you make in learning these concepts will pay dividends throughout your entire career! 🚀

Note51

Explorer

0.0 by Claude