Coursify

SOFTWARE ENGINEERING

Tools for Requirements Gathering and Introduction to Nontraditional Requirements

This section presents common structured tools used in requirements gathering, including document flow charts, decision tables, and decision trees, and introduces the idea of nontraditional requirements.

Learning Goals

  • Create a document flow chart to represent the movement of information between actors, processes, and documents.
  • Construct a decision table for a small business rule or system logic problem.
  • Develop a decision tree from a textual requirement scenario and interpret its branching logic.
  • Compare document flow charts, decision tables, and decision trees in terms of purpose, strengths, and limitations.
  • Define nontraditional requirements and identify examples that extend beyond standard functional and nonfunctional classifications.

Gathering and documenting requirements accurately is one of the most critical—and most error-prone—phases of the Systems Development Life Cycle (SDLC). While natural-language descriptions are a useful starting point, they are inherently ambiguous. Structured tools such as document flow charts, decision tables, and decision trees provide analysts with precise, visual, and verifiable ways to capture process logic and business rules 2.

This section introduces each tool, demonstrates how to construct and interpret it, and then compares all three in a single framework. The lesson concludes by broadening the requirements lens to include nontraditional requirements—categories that extend beyond the familiar functional/nonfunctional divide and increasingly determine whether a system succeeds or fails in its real-world context .

Footnotes

  1. Flowcharts in Systems Analysis – Creately - Overview of flowchart types and best practices for systems analysis and requirements gathering. ↩

  2. Decision Tables vs Decision Trees in Requirements Engineering – Medium - Comparative analysis of structured decision tools in software requirements. ↩

  3. Socio-Technical Systems and Nontraditional Requirements – GeeksforGeeks - Discussion of cultural, political, and organisational requirements beyond functional/nonfunctional. ↩

Decision Table Explained with Example

Document Flow Charts

A document flow chart (also called a document flowchart or paperwork flowchart) depicts how documents and information physically or electronically move between actors, processes, and storage points within an organisation . Unlike a system flowchart (which focuses on hardware and software) or a program flowchart (which focuses on algorithmic logic), the document flow chart keeps its emphasis on who creates, receives, copies, files, and destroys each document .

Standard Symbols

SymbolShapeMeaning
ProcessRectangleAn action or task that transforms data
DocumentWavy-bottom rectangleA single document (e.g., invoice, form)
Multi-documentStacked wavy rectanglesMultiple copies of a document
DecisionDiamondA branching point (Yes/No, True/False)
TerminatorRounded rectangle / OvalStart or end of the flow
Data StoreOpen-ended rectangleA file cabinet, database, or archive
Flow LineArrowDirection of document or data movement

Swimlane Layout

Document flow charts almost always use swimlanes to separate responsibilities by department or role. Each lane shows who is performing the work, and the arrows crossing lane boundaries reveal hand-offs and potential bottlenecks 2.

In the example above, the Customer submits an order form that flows to the Sales Department for credit verification. If approved, an invoice is prepared and the Warehouse fulfils the order. Finally, Accounting records the payment. The cross-lane arrows highlight every hand-off point—each of which is a potential source of delay or error that the analyst should investigate.

Footnotes

  1. Flowcharts in Systems Analysis – Creately - Overview of flowchart types and best practices for systems analysis and requirements gathering. ↩ ↩2

  2. Document Flowchart Symbols and Swimlane Diagrams – GeeksforGeeks - Standard symbols and swimlane layout techniques for document flow charts. ↩ ↩2

When to Choose a Document Flow Chart

Use a document flow chart early in requirements gathering when you need to understand who handles what paperwork and where information physically travels. It is especially valuable when digitising a manual, paper-based process because it exposes redundant copies, unnecessary approvals, and hand-off delays .

Footnotes

  1. Flowcharts in Systems Analysis – Creately - Overview of flowchart types and best practices for systems analysis and requirements gathering. ↩

Constructing a Document Flow Chart

  1. 1
    Step 1

    Choose a single business process with a clear start event and end event. Avoid mapping the entire organisation in one diagram—break large processes into sub-processes if needed .

    Footnotes

    1. Flowcharts in Systems Analysis – Creately - Overview of flowchart types and best practices for systems analysis and requirements gathering. ↩

  2. 2
    Step 2

    List every person, department, or external entity that creates, receives, or transforms a document within the process. Each actor becomes a swimlane.

  3. 3
    Step 3

    Enumerate every form, report, memo, invoice, or electronic record that moves through the process. Note the number of copies produced at each step.

  4. 4
    Step 4

    For each document, draw the path from its origin to its final destination. Use arrows to show direction, and place decision diamonds where routing changes based on a condition .

    Footnotes

    1. Document Flowchart Symbols and Swimlane Diagrams – GeeksforGeeks - Standard symbols and swimlane layout techniques for document flow charts. ↩

  5. 5
    Step 5

    Show where documents are filed, archived, or stored (physically or electronically). Use the open-ended rectangle symbol.

  6. 6
    Step 6

    Walk through the completed chart with actual users. Verify that the flow matches reality, not just policy. Look for missing paths, redundant steps, and bottlenecks 2.

    Footnotes

    1. Flowcharts in Systems Analysis – Creately - Overview of flowchart types and best practices for systems analysis and requirements gathering. ↩

    2. Document Flowchart Symbols and Swimlane Diagrams – GeeksforGeeks - Standard symbols and swimlane layout techniques for document flow charts. ↩

Decision Tables

A decision table organises complex business logic into a compact, exhaustive matrix. It forces the analyst to consider every possible combination of conditions, thereby exposing gaps, contradictions, and redundancies that narrative requirements often conceal 2.

Anatomy of a Decision Table

A decision table is divided into four quadrants:

Condition Stub (left)Condition Entries (right)
Top halfLists all conditions (inputs)Shows the value of each condition for each rule (Y, N, or –)
Action Stub (left)Action Entries (right)
Bottom halfLists all possible actions (outputs)Marks which actions fire for each rule (X or blank)

Types of Decision Tables

  • Limited-entry tables: Conditions are binary (Yes/No or True/False) and actions are simply marked or unmarked. Easy to construct and verify .
  • Extended-entry tables: Conditions and actions can have multiple values (e.g., "High", "Medium", "Low"), allowing more compact representations but requiring more careful reading .
  • Mixed-entry tables: Some rows are limited-entry and others are extended-entry, combining the advantages of both.

Footnotes

  1. Decision Tables vs Decision Trees in Requirements Engineering – Medium - Comparative analysis of structured decision tools in software requirements. ↩ ↩2

  2. Decision Table Construction and Simplification – TutorialsPoint - Step-by-step guide to building and optimising decision tables. ↩ ↩2

Example — Employee Discount Policy

Business rule: "Full-time employees with more than 5 years of tenure receive a 20% discount. Full-time employees with 5 or fewer years receive a 10% discount. Part-time employees receive a 5% discount regardless of tenure."

ConditionsRule 1Rule 2Rule 3Rule 4
Employee is full-time?YYNN
Tenure > 5 years?YNYN
Actions
Apply 20% discountX
Apply 10% discountX
Apply 5% discountXX

Observations:

  • Rules 3 and 4 produce the same action regardless of tenure. This means the tenure condition is irrelevant for part-time employees, and these two rules can be consolidated into a single rule with a dash (–) in the tenure row—reducing the table and simplifying the implementation .
  • The table makes it immediately obvious that no rule is missing (all 22=42^2 = 4 combinations are covered) and no contradictions exist.

Footnotes

  1. Decision Table Construction and Simplification – TutorialsPoint - Step-by-step guide to building and optimising decision tables. ↩

Rule Count Formula

For a limited-entry decision table with nn binary conditions, the maximum number of rules is 2n2^n. With 3 conditions you have 23=82^3 = 8 rules; with 4 conditions, 24=162^4 = 16. As conditions grow, look for opportunities to consolidate rules using the dash (–) 'don't care' notation to keep the table manageable .

Footnotes

  1. Decision Table Construction and Simplification – TutorialsPoint - Step-by-step guide to building and optimising decision tables. ↩

Constructing a Decision Table

  1. 1
    Step 1

    Extract every factor from the requirement narrative that influences the outcome. Each condition becomes a row in the upper half of the table.

  2. 2
    Step 2

    For limited-entry tables, use Y/N. For extended-entry tables, list the specific values (e.g., 'Gold', 'Silver', 'Bronze').

  3. 3
    Step 3

    Identify every possible outcome or system response. Each action becomes a row in the lower half.

  4. 4
    Step 4

    Systematically enumerate all condition combinations. For nn binary conditions, start with 2n2^n columns. Mark the corresponding actions for each combination.

  5. 5
    Step 5

    Merge rules that differ in only one condition but produce identical actions. Replace the differing condition entry with a dash (–). This reduces table size without losing information 2.

    Footnotes

    1. Decision Tables vs Decision Trees in Requirements Engineering – Medium - Comparative analysis of structured decision tools in software requirements. ↩

    2. Decision Table Construction and Simplification – TutorialsPoint - Step-by-step guide to building and optimising decision tables. ↩

  6. 6
    Step 6

    Check for completeness (every combination is covered), consistency (no combination maps to conflicting actions), and correctness (each rule matches the intended business logic) .

    Footnotes

    1. Decision Table Construction and Simplification – TutorialsPoint - Step-by-step guide to building and optimising decision tables. ↩

Decision Trees

A decision tree represents the same logic as a decision table but in a hierarchical, branching graph. It excels at communicating sequential, "if-then-else" reasoning to stakeholders who find tables difficult to follow 2.

Structure

This tree encodes exactly the same discount policy as the decision table above. Reading from root to leaf, each path represents one decision rule. The tree naturally prunes the irrelevant tenure check for part-time employees, making the logic visually compact.

Interpreting a Decision Tree

  1. Start at the root node (topmost diamond/decision).
  2. Evaluate the condition and follow the branch matching the result.
  3. Repeat until you reach a leaf node (rectangle), which states the action to take.
  4. Each root-to-leaf path is equivalent to one rule in a decision table.

Footnotes

  1. Decision Tables vs Decision Trees in Requirements Engineering – Medium - Comparative analysis of structured decision tools in software requirements. ↩

  2. Decision Trees in Systems Analysis – SlideShare - Explanation of decision tree structure, construction, and interpretation. ↩

Watch for Combinatorial Explosion

Decision trees become unwieldy when conditions are numerous and independent. A tree with 6 binary conditions can have up to 26=642^6 = 64 leaf nodes. In such cases, a decision table may be more compact and easier to verify. Choose the representation that best fits the complexity of your problem 2.

Footnotes

  1. Decision Tables vs Decision Trees in Requirements Engineering – Medium - Comparative analysis of structured decision tools in software requirements. ↩

  2. Decision Trees in Systems Analysis – SlideShare - Explanation of decision tree structure, construction, and interpretation. ↩

Developing a Decision Tree from a Textual Requirement

  1. 1
    Step 1

    Read the requirement narrative and extract every condition or question that affects the outcome. Each becomes a decision node.

  2. 2
    Step 2

    Place the most discriminating condition (the one that most reduces the number of remaining paths) at the root. This produces a shallower, more readable tree .

    Footnotes

    1. Decision Trees in Systems Analysis – SlideShare - Explanation of decision tree structure, construction, and interpretation. ↩

  3. 3
    Step 3

    For each condition, draw one branch per possible outcome (e.g., Yes/No, or the specific values). Label each branch clearly.

  4. 4
    Step 4

    At the end of every branch path, place a rectangle containing the action or decision that applies when all preceding conditions are met.

  5. 5
    Step 5

    Trace every root-to-leaf path and confirm it matches the original textual requirement. Check that no path is missing and no path contradicts the stated rules .

    Footnotes

    1. Decision Tables vs Decision Trees in Requirements Engineering – Medium - Comparative analysis of structured decision tools in software requirements. ↩

Purpose: Traces the physical or electronic movement of documents between actors and departments.

Best for: Understanding information hand-offs, identifying bottlenecks, and mapping paper-based workflows.

Strengths:

  • Shows who handles what document
  • Reveals redundant copies and unnecessary approvals
  • Uses swimlanes for clear responsibility mapping

Limitations:

  • Does not model complex conditional logic well
  • Focuses on document movement, not data transformation
  • Can become cluttered for processes with many actors 2

Footnotes

  1. Flowcharts in Systems Analysis – Creately - Overview of flowchart types and best practices for systems analysis and requirements gathering. ↩

  2. Document Flowchart Symbols and Swimlane Diagrams – GeeksforGeeks - Standard symbols and swimlane layout techniques for document flow charts. ↩

Comparison of Structured Requirements Tools

Relative strengths across key evaluation criteria (1 = Weak, 5 = Strong)

Introduction to Nontraditional Requirements

Traditional requirements engineering classifies requirements into two broad categories:

  • Functional requirements: What the system must do (features, behaviours, inputs/outputs).
  • Nonfunctional requirements: Quality attributes the system must exhibit (performance, reliability, usability, security).

However, modern systems operate within complex socio-technical environments where success depends on factors that neither category fully captures. These are known as nontraditional requirements 2.

Why Nontraditional Requirements Matter

Ignoring nontraditional requirements is one of the most common reasons that technically sound systems fail in practice. A payroll system that violates local labour law, a healthcare app that ignores cultural attitudes toward data privacy, or an internal tool that threatens a department's political influence will face resistance—regardless of how well it performs its intended functions 2.

Footnotes

  1. Socio-Technical Systems and Nontraditional Requirements – GeeksforGeeks - Discussion of cultural, political, and organisational requirements beyond functional/nonfunctional. ↩ ↩2

  2. Cultural and Political Feasibility in Requirements – SITAMS - Academic resource on nontraditional requirements including cultural and political dimensions. ↩ ↩2

Categories of Nontraditional Requirements

Evolution of Requirements Categories

Functional Requirements Era

1970s–1980s

Early structured methods (e.g., Structured Analysis) focused almost exclusively on defining what the system must do—inputs, outputs, and data transformations."

Nonfunctional Requirements Recognised

1990s

Quality attributes like performance, security, and usability were formalised as first-class requirements. Standards like ISO 9126 emerged to classify software quality."

Socio-Technical Awareness

2000s

Researchers and practitioners acknowledged that cultural, political, and organisational factors were as important as technical quality for system success ."

Footnotes

  1. Socio-Technical Systems and Nontraditional Requirements – GeeksforGeeks - Discussion of cultural, political, and organisational requirements beyond functional/nonfunctional. ↩

Legal and Regulatory Surge

2010s

GDPR (2016/2018), HIPAA expansions, and PCI DSS updates made legal compliance a dedicated engineering concern, not just a checkbox ."

Footnotes

  1. Legal and Regulatory Requirements in Software Engineering – Apriorit - Overview of compliance-driven requirements including GDPR, HIPAA, and PCI DSS. ↩

Ethics and Sustainability

2020s

AI ethics frameworks, algorithmic fairness mandates, and green computing standards broadened the requirements landscape further. Nontraditional requirements are now integral to responsible engineering ."

Footnotes

  1. Cultural and Political Feasibility in Requirements – SITAMS - Academic resource on nontraditional requirements including cultural and political dimensions. ↩

Common Pitfall — Treating Nontraditional Requirements as 'Nice to Have'

Cultural, political, and legal requirements are not optional enhancements. A system that violates data protection law faces regulatory penalties. A system that threatens departmental power structures faces sabotage or non-adoption. Treat nontraditional requirements with the same rigour as functional and nonfunctional requirements: elicit them explicitly, document them formally, and validate them with stakeholders 3.

Footnotes

  1. Socio-Technical Systems and Nontraditional Requirements – GeeksforGeeks - Discussion of cultural, political, and organisational requirements beyond functional/nonfunctional. ↩

  2. Cultural and Political Feasibility in Requirements – SITAMS - Academic resource on nontraditional requirements including cultural and political dimensions. ↩

  3. Legal and Regulatory Requirements in Software Engineering – Apriorit - Overview of compliance-driven requirements including GDPR, HIPAA, and PCI DSS. ↩

Bringing It All Together

The structured tools and requirement categories covered in this section form a complementary toolkit:

Tool / CategoryPrimary Question It Answers
Document Flow Chart"Where does each document go, and who handles it?"
Decision Table"What should the system do for every possible combination of conditions?"
Decision Tree"What is the step-by-step decision path to an outcome?"
Nontraditional Requirements"What cultural, political, legal, ethical, or environmental factors constrain or shape the system?"

No single tool is sufficient on its own. Effective analysts combine flow charts to understand process context, decision tables to ensure logical completeness, decision trees to communicate branching logic, and nontraditional requirements analysis to anchor the system in its real-world operating environment 3.

Footnotes

  1. Flowcharts in Systems Analysis – Creately - Overview of flowchart types and best practices for systems analysis and requirements gathering. ↩

  2. Decision Tables vs Decision Trees in Requirements Engineering – Medium - Comparative analysis of structured decision tools in software requirements. ↩

  3. Socio-Technical Systems and Nontraditional Requirements – GeeksforGeeks - Discussion of cultural, political, and organisational requirements beyond functional/nonfunctional. ↩

Knowledge Check

Question 1 of 5
Q1Single choice

What is the primary purpose of a document flow chart?

Previous

Next

Tools for Requirements Gathering and Introduction to Nontraditional Requirements | SOFTWARE ENGINEERING | Coursify