Requirements Engineering and SRS Overview

Requirements Engineering

• Requirements for a system detail what the system should do
• Requirements Engineering (RE) is the process of finding, analyzing, documenting, and checking these services and constraints
• The term "requirement" isn't consistently used; it can range from a high-level, abstract statement to a detailed, formal definition of a system function

SRS (Software Requirements Specification)

• The SRS is an official statement of what developers should implement
• It's essential when an outside contractor creates the software system
• SRS = User Requirements + System Requirements

User Requirements

• User requirements are statements, in natural language plus diagrams, of the services a system should provide to the user and the constraints under which it must operate
• They describe the functionality in a way system users can understand, omitting technical detail

System Requirements

• System requirements are more detailed descriptions of features, services, and constraints of the system software
• The system requirements document (functional specification) details what will be executed and can be a part of a contract between the system buyer and the software developer

Functional Requirements

• These are statements of what services the system should provide—reactions to different inputs and system behaviors in various situations
• They can also specify what the system should not do

Non-Functional Requirements

• These are constraints on the system's services or functionality
• They include time constraints, development process rules, and standards
• They often apply to the whole system, rather than individual features or services
• Examples include performance (speed, response time), security, availability, reliability, interoperability, safety, and confidentiality

Writing Requirements

• Non-functional requirements should be written quantitatively, in order to be objectively tested
• Natural language requirements can be problematic because of their flexibility and scope for ambiguity
• Structured specifications offer a standard format, making requirements more consistent, and minimizing ambiguity

Requirements Document Structure

• The overall level of detail depends on the type of system and development process used.
• Critical systems require extensive detail; outsourcing projects need clear, specific requirements
• Iterative in-house projects can use far less detail

IEEE Standard for Requirements Documents

• A detailed structure for a requirements document is recommended
• It describes versions, the project need, how the system functions and works with other systems and details the technical terminology

Example Requirements

• The MHC-PMS should generate monthly cost reports for drugs prescribed by each clinic
• The system will automatically generate a report summarizing dispensed drugs, costs, and prescribing clinics on the last working day of each month, accessible to authorized users.
• Other examples covered include appointment lists, staff identification, and insulin pump functionalities.

Agile Approach

• Requirements in business systems often change rapidly, making the Agile approach beneficial
• The Agile method focuses on incremental development and quick response to changing requirements
• User stories, written on cards, are used to prioritize and design the next development increment.

Users of a Requirements Document

• Customers specify requirements, checking if they meet their needs
• Managers use the document for project planning and bids
• System Engineers use it to understand the system to be made
• Test Engineers create system validation tests
• Maintenance Engineers understand and trace relationships between system parts