Fundamentals 8 min read

Introduction to Software Requirements Engineering – Part 1

This article introduces software requirements engineering, covering its iterative process, the distinction between user and system requirements, functional versus non‑functional requirements, and the role of feasibility studies in guiding successful system development.

Architects Research Society
Architects Research Society
Architects Research Society
Introduction to Software Requirements Engineering – Part 1

Software Requirements Engineering Introduction

Software requirements engineering is the discipline of collecting and defining what services a system should provide. It focuses on assessing business feasibility, eliciting and analyzing needs, formalizing them into specifications, and verifying that they meet the customer's expectations.

The process is not strictly sequential; it is an iterative activity where user needs are repeatedly captured, refined, and validated, and system requirements are evolved in parallel.

User and System Requirements

Requirements are typically divided into two levels of detail: user requirements, which are high‑level statements for stakeholders, and system requirements, which provide the detailed specifications needed by developers, architects, and testers.

Functional vs. Non‑Functional Requirements

Functional requirements describe the primary services the system must deliver, often expressed in abstract user‑oriented language. Detailed system functional requirements specify inputs, processing, responses, and expected outputs.

Non‑functional requirements impose constraints on the system’s behavior, such as performance, security, reliability, maintainability, and legal compliance. These are often more critical than individual functional features because failing to meet them can render the entire system unusable.

Feasibility Study

Before development begins, a feasibility study determines whether the proposed system is worth implementing given budget, technical skills, schedule, and alignment with organizational goals. Its inputs include preliminary business needs and a high‑level system description, and its output is a report recommending whether to proceed.

In practice, translating business goals into measurable non‑functional requirements can be challenging, and validating such requirements may be costly, but they are essential for successful system delivery.

Overall, the article outlines the four main activities of requirements engineering—feasibility analysis, requirements capture and analysis, specification, and verification—emphasizing their iterative and interdependent nature.

software engineeringsystem analysisnon-functional requirementsrequirements engineeringfeasibility studyfunctional requirements
Architects Research Society
Written by

Architects Research Society

A daily treasure trove for architects, expanding your view and depth. We share enterprise, business, application, data, technology, and security architecture, discuss frameworks, planning, governance, standards, and implementation, and explore emerging styles such as microservices, event‑driven, micro‑frontend, big data, data warehousing, IoT, and AI architecture.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.