Software Engineering Principles: Requirements Engineering

Requirement (IEEE Definition):
- Something a user needs to solve a problem or reach a goal.
- A condition or capability a software system must have to meet a contract, standard, or formal rule.
Requirements Engineering: The process of discovering, writing down, and managing what a customer needs from a system and the limits it must work within.
Main Purpose: Acts as the blueprint for software design and forms the checklist for testing to ensure the finished product does what users need.
Understanding the Problem Domain: Simple real-world situations can create complicated software rules. Keep requirements clear and brief, but make sure you understand the context well enough to describe the right system behavior.

User Requirements:
- High-level summaries written in simple everyday language with diagrams.
- Explain the services the system provides and how it will be used from the customer's point of view.
System Requirements:
- A detailed, structured document that spells out exactly what functions, services, and limits the system has.
- Acts as a formal contract between the client and the developers.

Functional Requirements (FR):
- Statements of what the system must do.
- Detail features, user inputs, system outputs, error handling, screen behaviors, and workflows.
Non-Functional Requirements (NFR):
- Statements of how well the system should do its job and the rules it must follow.
- Cover performance targets, security, reliability, budget, deadlines, and the programming languages used.

NFR Categories:
- Product Requirements: How the software behaves for the user, such as usability, reliability, portability across platforms, and efficiency (memory usage and speed).
- Organizational Requirements: Rules from the company building the software, such as delivery deadlines, coding standards, and development tools.
- External Requirements: Rules from outside sources, including legal requirements, privacy rules, safety laws, and connecting with other systems.
Measuring Non-Functional Requirements:
- Speed: Transactions processed per second, user response time, screen refresh time.
- Size: Memory required in kilobytes or hardware chip limits.
- Ease of Use: Time taken to train a new user, number of help screens available.
- Reliability: How often the system fails, average operating time between crashes, and system availability.
- Robustness: Time taken to restart after a crash, likelihood of data loss during failure.
- Portability: Ease of running on different operating systems or devices.

Unitary (Focused): Covers only one feature or task at a time.
Complete: Contains all the needed details in one place with nothing left out.
Consistent: Does not contradict or clash with any other requirement.
Non-Conjugated (Atomic): Split into simple, separate statements instead of joining multiple ideas with words like "and".
Traceable: Easily linked back to business goals and forward to the final code and test cases.
Feasible: Can realistically be built within the project's budget, time, and technology limits.
Unambiguous: Has only one clear meaning so that everyone understands it the same way.
Mandatory: An essential feature that the system cannot work without.
Verifiable: Can be proven to work through testing, demonstrations, or inspection.

Problems with Everyday Language:
- Ambiguity & Confusion: Everyday words can be interpreted in multiple ways, leading people to mix up features with system constraints.
- Poor Structure: Hard to keep large, complex systems well-organized when writing in plain sentences.
Common Mistakes to Fix:
- Ambiguity: Wording that allows more than one interpretation.
- Vague Statements (Platitudes): Claims that cannot be measured or tested (such as "the app must be user-friendly" or "the system must be fast").
- Omissions: Leaving out important limits, exceptions, or boundary numbers.
- Inconsistencies: Statements that contradict each other in different parts of the document.
- Mixed Levels of Detail: Blending big-picture overviews with low-level coding details in the same section.
- Mixing FRs and NFRs: Combining what the system should do with how it should be built in the same sentence.
Writing Best Practices:
- Use a clear numbering system (like 3.2.1).
- Use keywords strictly: shall means a mandatory requirement; should means an optional or desirable feature.
- Avoid subjective terms (such as "easy", "simple", or "fast") and open-ended words (such as "maximize" or "optimize"). Replace them with specific, measurable targets.

Structured Language: Uses standard forms or templates to keep requirements clear and consistent.
Program Description Language (PDL): Uses code-like wording (pseudocode) with simple logic to describe how a process works.
Graphical Notations: Uses visual diagrams (such as Use-Case diagrams) paired with explanatory text.
Formal Specifications: Uses precise mathematical logic and state models to specify requirements without confusion.

Purpose: The single official document where customers, managers, developers, and testers agree on what product will be made.
Document Qualities: Accurate, clear, complete, testable, consistent, easy to update, and traceable.

Traceability Types:
- Forward Traceability: Tracking stakeholder needs into requirements, and tracking requirements down into design, code, and test cases.
- Backward Traceability: Tracking the written code and tests back up to the requirements, and back up to the original business requests.
Standard Document Structure:
- Introduction: Document purpose, system boundaries (scope), definitions, and source references.
- General Description: Big-picture overview, major functions, intended user background, and project limitations.
- System Architecture: High-level blueprint showing how modules and components connect.
- Specific Requirements: Numbered lists of all detailed functional and non-functional requirements.
- Appendices & Index: Hardware details, extra background data, and page numbers.