Note51

0.0 by Qwen

14 min read

Chapter 4: System Requirements

User Requirements vs System Requirements (overview)

Definition

  • User Requirements: High-level, abstract statements about what users and procurers need, written in natural language with diagrams and tables.
  • System Requirements: Precise, detailed descriptions (extended versions of user requirements) in a structured form of natural language supported by models and tables; starting point for design and often called functional specifications.

Causes

  • Need to communicate different levels of detail to different readers (users vs implementers).

Goals / Objectives

  • Capture what users need at a high level (User Requirements).
  • Produce detailed, unambiguous specifications developers can implement and test (System Requirements).

Importance

  • User requirements inform stakeholders and procurement; system requirements form the contract between developer and customer and guide design.

Procedures

  • Elicit user requirements (natural language + diagrams).
  • Derive system requirements during requirement analysis, structuring them with models, tables and precise wording.

Advantages & Disadvantages

  • Advantages (of separating them):
    • User Requirements are easy for non-technical stakeholders to read.
    • System Requirements are precise enough for design and development.
  • Disadvantages (implied):
    • Natural-language user requirements can be ambiguous; transforming to precise system requirements requires careful analysis.

Impact / Effect

  • Clear separation reduces misunderstanding between customer-facing needs and developer-facing specifications.

Examples

  • See LIBSYS example (next subtopic).

Key Takeaways

  • User requirements = high-level, for users; system requirements = detailed, for implementers.
  • System requirements are the basis for design and the developer–customer contract.

Examples: LIBSYS (User vs System requirements)

Definition

  • Example illustrating conversion of a single user requirement into multiple detailed system requirements.

Causes

  • A high-level need (“keep track of all data required by copyright licensing agencies”) requires many specific behaviors from the system.

Goals / Objectives

  • Show how one user requirement expands into multiple, testable system requirements.

Importance

  • Demonstrates necessity of decomposition for clarity and implementability.

Procedures

  • Decompose user-level statement into specific actionable items (forms, storage, indexing, logging, reporting).

Advantages & Disadvantages

  • Advantage: Detailed system items (1.1–1.5) enable testing and clear implementation.
  • Disadvantage: More text and detail to manage and review.

Impact / Effect

  • Provides testable, traceable requirements that can be assigned to design and coding tasks.

Examples (preserved from notes)

  • User Requirement:
      1. LIBSYS shall keep track of all data required by copyright licensing agencies in the UK and elsewhere
  • Derived System Requirements:
    • 1.1 Present requester a form recording user and request details when requesting a document.
    • 1.2 Store LIBSYS request forms for five years from the date of request.
    • 1.3 Index all request forms by user, material name and supplier.
    • 1.4 Maintain a log of all requests made to the system.
    • 1.5 For materials with authors’ lending rights, send monthly loan details to registered copyright licensing agencies.

Key Takeaways

  • A single user statement can map to several precise system requirements.
  • System requirements must be specific about storage, indexing, retention and reporting.

Main difference between User and System Requirements

Definition

  • Comparison summary.

Causes

  • Different audiences and purposes.

Goals / Objectives

  • Clarify why system requirements are more detailed.

Importance

  • Ensures team uses the right document for the right audience.

Procedures

  • Not applicable (comparison)

Advantages & Disadvantages

  • System requirement: more precise and detailed than user requirement because of intended different readers.

Impact / Effect

  • Use user requirements for stakeholders; system requirements for developers, architects and testers.

Examples

  • As shown in LIBSYS example.

Key Takeaways

  • System requirements are more precise and detailed than user requirements.
  • Each targets different readers and purposes.

Exercise (Past Year Question): Online Concert Ticket — User & System Requirements

Definition

  • Practical assignment previously given in the course.

Causes

  • To test students’ ability to write both user and system requirements.

Goals / Objectives

  • Prepare user requirement (2 marks) and system requirement (7 marks) for an online concert ticket function.

Importance

  • Tests ability to move from high-level user needs to implementable system requirements.

Procedures

  • Provide:
    • One user requirement statement.
    • Multiple system requirement items detailing view, check, select, payment validation, seat update, receipt, etc.

Advantages & Disadvantages

  • Not applicable

Impact / Effect

  • Demonstrates expected granularity between user and system requirements in exam marking.

Examples (from notes)

  • User Requirement:
    1. The system must provide a facility which allows online users to check concert details, seat availability and purchase tickets.
  • System Requirements (numbered 1.1–1.8 in notes):
    1.1 Allow online users to view concert details.
    1.2 Allow users to check seat availability.
    1.3 Allow users to select seating positions and purchase tickets.
    1.4 Calculate charges once user confirms transaction.
    1.5 Check payment details (e.g., credit card number).
    1.6 Show message if payment details invalid.
    1.7 If valid, proceed with transaction and mark seats not available.
    1.8 Generate online receipt.

Key Takeaways

  • User requirement is short; system requirements expand into many numbered, precise behaviors.
  • Exam marking emphasizes more points for detailed system requirements.

Functional vs Non-Functional Requirements

Definition

  • Functional Requirements: Specify services the system must provide, how the system should behave in situations, system reactions to inputs, and what the system should not do.
  • Non-Functional Requirements: Constraints on product, process or external factors (usability, performance, reliability, portability, standards, legislative, safety, privacy, etc.).

Causes

  • Need to capture both what the system does and how well / under which constraints it must operate.

Goals / Objectives

  • Functional: define system behavior and services.
  • Non-functional: define quality attributes, constraints and organizational/environmental needs.

Importance

  • Both types are essential: functional for correctness, non-functional for acceptability, performance, compliance and maintainability.

Procedures

  • Elicit functional tasks as service statements and scenarios.
  • Elicit non-functional constraints and categorize them: product, process/organizational, external requirements.

Advantages & Disadvantages

  • Advantage: Separating them clarifies acceptance criteria and design trade-offs.
  • Disadvantage: Non-functional items can be harder to measure and may be overlooked if not explicitly captured.

Impact / Effect

  • Functional requirements guide implementation; non-functional drive architecture, testing and compliance.

Examples (from notes)

Functional example (HR system, Employee Self Service):

  • 1.0 Basic Personal Tasks:
    • 1.1 Employees can change name, address, phone numbers, emergency contacts, next of kin, marriage, births or adoption details.
    • 1.2 Employees can upload common info to existing databases (telephone directories, org charts).
    • 1.3 Employees can view their employment history (promotions, appraisal reviews, training).
    • 1.4 Employees can view conditions of employment, HR policies, procedures, information packs, benefits.

Non-functional examples (categories and specific items):

  • Product Requirements: Usability, Performance, Space, Reliability, Portability.
  • Process/Organizational Requirements: Delivery, Efficiency, Implementation, Standards.
  • External Requirements: Interoperability, Ethical, Legislative, Privacy, Safety, Security.
  • Concrete examples from LIBSYS:
    • Product requirement: 8.1 The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets.
    • Organizational requirement: 9.3.2 The development process and deliverables shall conform to process XYZ-ST95.
    • External requirement: 10.6 The system shall not disclose personal information of users apart from name and library reference number to library staff.

Key Takeaways

  • Functional requirements state what the system does; non-functional state constraints and qualities.
  • Non-functional requirements include product, process/organizational and external/legal categories.

Problems with Natural Language (in requirements)

Definition

  • Limitations and risks when using unstructured natural language for requirements.

Causes

  • Natural language is flexible, ambiguous, wordy and inconsistent across stakeholders.

Goals / Objectives

  • Explain why natural language alone is insufficient for precise requirements.

Importance

  • Identifies the need for structured, graphical or formal notations to avoid confusion.

Procedures

  • Review issues: ambiguity, lack of clarity, confusion between functional/non-functional, over-flexibility, no clear partitioning.

Advantages & Disadvantages

  • Advantages of NL: easy for users to read and write.
  • Disadvantages of NL (from notes):
    • Lack of clarity and ambiguity.
    • Over-flexibility (same meaning expressed many ways).
    • No clear partitioning between system goals and design info.
    • Confusion between functional and non-functional requirements.
    • Wordy and difficult to standardize.
    • Same word may be used for different concepts; same concept can have many words.

Impact / Effect

  • Natural-language requirements can lead to misunderstandings, incorrect designs and errors that surface late.

Examples (from notes)

  • Problem example in LIBSYS accounting requirement:
    • “4.5 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 ay receive discounted rates.”
    • This mixes payment record maintenance and discount configuration, causing ambiguity about who gets discounts and how configuration works.

Key Takeaways

  • Natural language is necessary but insufficient alone; without structure it causes confusion and ambiguity.
  • Use other notations or structured NL to reduce misinterpretation.

Notations for System Requirements Specification (SRS)

Definition

  • Various forms (notations) used to write system requirements precisely.

Causes

  • Need to reduce ambiguity of natural language and express requirements in implementable, testable forms.

Goals / Objectives

  • Provide a palette of notations so SRS can be clear, precise and usable by developers and testers.

Importance

  • Choosing the right notation reduces misinterpretation and improves the SRS quality.

Procedures

  • Possible notations listed in notes:
    • Structured natural language (constrained templates)
    • Design description languages (specification languages like PSL/PSA, RSL)
    • Graphical notations (DFD, sequence diagrams)
    • Mathematical specifications (finite-state machines/sets, Z-specification)
    • Decision tables (templates for system input → process → output, like a data dictionary)

Advantages & Disadvantages

  • Advantages:
    • Structured NL improves readability and reduces ambiguity.
    • Graphical notations help scope and represent requirements visually.
    • Formal/mathematical specs give unambiguous semantics for critical systems.
    • Decision tables clearly map inputs to outputs for conditional logic.
  • Disadvantages:
    • Formal languages can be hard for stakeholders to read.
    • Graphical notations may hide low-level detail.
    • Mixed notations require careful cross-referencing to stay consistent.

Impact / Effect

  • Using mixed notations (structured NL + diagrams + formal specs where needed) yields an SRS that is complete, precise and suited to multiple readers.

Examples (from notes)

  • Graphical: DFDs, Sequence Diagrams.
  • Formal: Finite-state machines, Z-specification.
  • Specification languages: PSL/PSA, RSL.
  • Decision tables and data-dictionary-like templates for inputs/processes/outputs.

Key Takeaways

  • Use structured NL, diagrams and formal specs together to make SRS precise and readable.
  • Decision tables and DFDs are practical tools to reduce ambiguity.

Software Requirements Document (SRS) — Purpose and Users

Definition

  • Software Requirements Document (SRS): Official statement of system requirements that specifies what the system should do (not how). It should be complete, consistent and free of conflicts.

Causes

  • Need for a single authoritative document used by multiple stakeholders.

Goals / Objectives

  • Provide a formal, traceable, and shared specification for customers, developers, testers and maintainers.

Importance

  • The SRS is used by system engineers, customers, test engineers, project managers, SRS users and maintenance engineers.

Procedures

  • Create SRS with structured sections and models; ensure completeness and consistency.

Advantages & Disadvantages

  • Advantages: central, authoritative specification; supports testing and maintenance.
  • Disadvantages: Not explicitly listed in notes but implied: SRS must be carefully maintained to avoid divergence from design/implementation.

Impact / Effect

  • A well-structured SRS improves design, testing and maintenance and reduces later misunderstandings.

Examples (users of SRS listed)

  • System Engineers, System Customers, System Test Engineers, Project Manager, SRS users, System Maintenance Engineers.

Key Takeaways

  • SRS is the official, detailed specification of what the system must do, used across the project lifecycle.

Structure of the SRS (chapter-by-chapter breakdown from notes)

Definition

  • Table of contents / structure recommended for a comprehensive SRS.

Causes

  • Requirement to organize many kinds of requirements, models and evolution concerns.

Goals / Objectives

  • Show required sections to make SRS usable and maintainable.

Importance

  • Following a consistent structure helps readers quickly find required information.

Procedures

  • SRS structure enumerated in notes (preserve all items):

    • Preface
    • Introduction
      • Purpose
      • Scope
      • Overview
      • Business Context
    • Glossary
      • Definition of terms
    • User requirements definition
      • General user requirements
    • System architecture (chapter referenced as Chapter 6 in notes)
      • Items definition and architecture diagrams (e.g., modules like Item Bank, Remote Test Module)
    • System requirements specification
      • Functional requirements
      • Non-functional requirements
      • Interface requirements
      • Performance requirements
    • System models (Chapter 6 referenced)
    • System evolution (versions, change history; Chapter 11 referenced)
    • Appendices
      • Separate chapters or appendices for Hardware and Database requirements (explicitly mentioned)
    • References (supporting documents)
    • Index (notes include an example index of terms and pages)

Advantages & Disadvantages

  • Advantages: Comprehensive coverage including user definitions, architecture, detailed requirements, models and evolution.
  • Disadvantages: Large SRS can be long and require maintenance (implied).

Impact / Effect

  • A well-structured SRS supports traceability from user needs through architecture to detailed requirements and future evolution/versioning.

Examples (content items preserved from notes)

  • Indexed items and example elements: Forms, Grid, Article Manager, Editor, Database, Security, Status, Update, User, Web Publishing System.
  • Example requirement chapters and items (Chapter and index snippets are preserved exactly as in notes).

Key Takeaways

  • The SRS should be structured from Preface to Index and include user requirements, architecture, detailed system requirements, models, evolution, appendices for hardware/database and references.
  • Include glossary and index for clarity.

SRS Quality Rules (from notes)

Definition

  • How the SRS should be written.

Causes

  • Need for clarity, implementability and lack of conflicts.

Goals / Objectives

  • Ensure SRS specifies what without how, is complete & consistent and has no conflicting statements.

Importance

  • High-quality SRS reduces implementation errors and rework.

Procedures

  • Use appropriate notations, include required sections, and ensure traceability between user requirements and system requirements.

Advantages & Disadvantages

  • Advantages: Clear, testable, and maintainable requirements.
  • Disadvantages: Requires discipline and good processes to maintain.

Impact / Effect

  • A good SRS makes design, implementation and testing straightforward and reduces disputes between stakeholders.

Examples

  • The notes emphasize “Specify WHAT without HOW; Complete & consistent; No conflict.”

Key Takeaways

  • SRS must be precise, unambiguous and organized; avoid including design decisions in the SRS.

SRS Models and Evolution

Definition

  • Sections in SRS that capture models (diagrams, state machines) and plans for system evolution (versioning).

Causes

  • Need to represent behavior and structure visually and to plan for future changes.

Goals / Objectives

  • Provide system models (DFD, sequence diagrams, finite-state machines) and record version/evolution information (Chapter 11 reference in notes).

Importance

  • Models help designers and testers understand system interactions; evolution sections track changes and versions.

Procedures

  • Include system models chapter and system evolution/version history chapter; appendices for hardware and database requirements.

Advantages & Disadvantages

  • Advantages: Better comprehension and traceability; easier maintenance planning.
  • Disadvantages: More documentation to keep current.

Impact / Effect

  • Improves communication among architects, developers and maintainers; supports controlled evolution.

Examples (from notes)

  • Diagrams shown for Items Definition and Remote Test Module; references to DFD and sequence diagrams and formal models (finite-state/Z).

Key Takeaways

  • Include system models and evolution/versioning in the SRS for clarity and maintainability.

Appendices (Hardware, Database) and References

Definition

  • Supporting SRS material placed in appendices for clarity.

Causes

  • Some requirements (hardware, DB) are large or platform-specific and better kept separate.

Goals / Objectives

  • Separate cross-cutting or large technical details from the core SRS narrative.

Importance

  • Keeps main SRS focused while providing necessary technical detail.

Procedures

  • Create separate chapters or appendices for Hardware and Database requirements; include references to supporting documents.

Advantages & Disadvantages

  • Advantage: Cleaner main document; technical teams can read appendices relevant to them.
  • Disadvantage: Appendices add to document size and require maintenance.

Impact / Effect

  • Easier navigation and role-specific access to details.

Examples

  • Notes explicitly mention separate chapter/appendices for Hardware and Database requirements.

Key Takeaways

  • Use appendices for hardware and database specs; always include references supporting the SRS.

Final Key Points from Chapter 4

Definition

  • Chapter covers differences between user/system requirements, functional vs non-functional, problems with natural language, SRS notations and full SRS structure.

Causes

  • Not specified in notes

Goals / Objectives

  • Teach how to write clear user and system requirements, choose notations, and structure an SRS.

Importance

  • A good SRS is the foundation for correct design, implementation, testing and maintenance.

Procedures

  • Elicit user needs, derive precise system requirements, classify functional/non-functional requirements, address natural-language issues with structured notation, and assemble a structured SRS with models and appendices.

Advantages & Disadvantages

  • Not specified beyond per-section content

Impact / Effect

  • Following the chapter reduces ambiguity, improves traceability and supports system evolution.

Examples

  • LIBSYS example; Online Concert Ticket exercise; HR self-service functional examples; concrete non-functional examples for LIBSYS.

Key Takeaways

  • Always separate user and system requirements and make system requirements precise.
  • Capture functional and non-functional needs explicitly.
  • Use structured NL, diagrams and formal notations where appropriate to avoid NL pitfalls.
  • Organize the SRS with Preface, Intro, Glossary, User requirements, Architecture, System requirements, Models, Evolution, Appendices and References.

Graph View

Backlinks