Unit 2: Understanding Software Development Lifecycles and Requirements Specifications

Application Development and Emerging Technologies

Module 3: Documentation and Process

Deliverables
Module Overview
In modern software development, understanding and visualizing workflows is crucial for
efficient system design. Process models and diagrams serve this purpose by providing graphical
representations of business operations, system processes, or data flows. They reveal the sequence
of activities, decisions, and interactions needed to complete a process, helping identify bottlenecks,
inefficiencies, or redundancies. Across different development domains such as software, database,
network, and website development, process modeling and diagramming techniques are essential
for planning, analysis, and improvement of systems.
Key modeling tools include Use Case Diagrams, Data Flow Diagrams (DFDs), and UML
Class Diagrams, which communicate system functionalities, interactions, and structures
effectively. Complementing these are project artifacts, such as Requirement Specification
Documents, Design Documents, and Test Plans, which formalize requirements, visualize designs,
and validate functionality. By mastering these tools and techniques, students gain the ability to
translate user requirements into actionable designs and structured, testable software solutions.

Learning Outcomes
After completing this module, you should be able to:

1. Identify the key components of process models, process diagrams, use case diagrams,
DFDs, and UML class diagrams.
2. Explain the importance of process modeling and diagramming in different development
domains.
3. Construct simple use case diagrams, DFDs, and UML class diagrams for given
scenarios.
4. Analyze workflows to identify inefficiencies, redundancies, or missing processes in a
system.
5. Evaluate project artifacts (requirements, design documents, test cases) to ensure
alignment with system requirements.

Core Content
Process Models and Diagrams
Process models are graphical or mathematical representations of how a business or
workflow operates. They show the sequence of activities, tasks, decisions, events, and
relationships needed to complete a process from start to finish. These models help people visualize,

1
Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
analyze, and improve workflows by clearly revealing bottlenecks, duplicated tasks, delays, and
inefficient resource usage.
Process diagrams, sometimes called process maps or flowcharts, are a visual type of
process model. They use shapes (like rectangles, diamonds, and arrows) to illustrate how work
flows, including who does what and when choices must be made. They are widely used in training,
documentation, operations, systems analysis, and quality improvement.
In short, process models help organizations understand how work is currently done and
how it can be improved, while process diagrams serve as clear visual tools for communicating
processes to teams, users, decision-makers, or developers.

Why Process Models Matter

1. They make complex workflows easier to understand
2. They help identify inefficiencies and wasted time
3. They support better planning, redesigning, and automating processes
4. They improve communication between stakeholders, employees, and developers

Real-World Examples
Scenario Process Model Purpose Sample Output
Enrollment process in a school Identify delays and steps that Enrollment workflow model
require manual handling
Ordering food using an app Map actions from placing Food delivery process
order to delivery flowchart
Hospital patient admission Analyze waiting time and Patient admission process
treatment flow model

Types of Process Models and Diagrams Across Development Domains

Different development fields use specific process models and diagramming techniques to
plan, design, visualize, and improve system workflows. These tools help ensure clarity, accuracy,
stakeholder alignment, and efficient development cycles.

Software Development

Common Process Models

Model Description When Used
Waterfall Linear, step-by-step phases Stable, well-defined
requirements
Agile Iterative, flexible, customer-driven Rapid changes and continuous
feedback
Spiral Combines iteration with risk analysis High-risk, large-scale projects
V-Model Validation–verification focused Safety-critical systems

2
 Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
Common Diagrams
Diagram Type Purpose Example
Use Case Diagram Shows system functions from user Login, register, search
perspective
Class Diagram Models objects, attributes, and Student–Course–Instructor
relationships
Sequence Diagram Shows order of interactions over time Online ordering sequence
Activity Diagram Workflow of tasks or decisions Purchase process
Deployment Diagram Hardware + software mapping Cloud deployment mapping

Database Development

Common Process Model

• Waterfall or Iterative models are used based on data requirements stability and revision
frequency.

Common Diagrams
Diagram Type Purpose Example
ER Diagram Shows data entities + relationships Student–Subject–Enrollment
DFD (Data Flow Maps how data moves and transforms Registration data flow
Diagram)
Schema Diagram Represents database tables + keys SQL schema for employees

Network Development
Common Process Model
• Phased or lifecycle-based similar to Waterfall (planning → design → implement → test
→ maintain).

Common Diagrams
Diagram Type Purpose Example
Network Diagram Shows nodes, connections, and LAN/WAN architecture
topology
DFD Illustrates network data processing Email data routing
Flowchart Shows decision-based routing steps Firewall traffic filtering

Website Development

Common Process Model

• Agile and Iterative are popular because web content and UX frequently change.

3
Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
Common Diagrams
Diagram Type Purpose Example
Wireframe Layout and structure of web pages Homepage wireframe
Mock-up High-fidelity design and UI Mobile app screen design
visualization
Site Map Navigation and hierarchy structure Menu → Subpages mapping
Flowchart Shows user navigation paths Checkout flow

Use Case Diagram

A Use Case Diagram is a visual representation that depicts the interactions between users
(actors) and a system, illustrating the functional requirements and expected behavior of the system
from the users' perspective. It focuses on what the system does, not how it does it, providing a
high-level overview of system behavior and relationships.
A Use Case Diagram shows how different actors engage with various use cases (specific
functionalities) within the system. It captures the system’s functions and the interactions with users
or external systems.

Importance of Use Case Diagram

• Identifies and clarifies system requirements from the user's viewpoint.
• Facilitates communication among stakeholders, developers, and analysts.
• Defines system scope and boundaries clearly.
• Supports requirement gathering, system design, and validation processes.
• Useful for planning, documentation, and ensuring alignment between user needs and
system development.

Symbols in Use Case Diagrams

• Actors: Represent users or external systems interacting with the system, shown as stick
figures.
• Use Cases: Functionalities or services provided by the system, shown as ovals.
• System Boundary: A rectangle surrounding use cases, defining the scope of the system.
• Relationships: Lines connecting actors and use cases, including:
o Association: Basic interaction between actor and use case.
o Include: Indicates a mandatory sub-functionality included in a use case.
o Extend: Represents optional or conditional behavior extending a use case.
o Generalization: Inheritance relationship among actors or use cases.

Step-by-Step Guide in Creating a Use Case Diagram

1. Identify the Actors
• Determine the users or external systems interacting with your system. Primary
actors (main users) – usually placed on the left side of the system boundary.
Secondary actors (external systems or supporting actors) – usually placed on the
right side.

4
Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
• Example: In an online bookstore, actors could be Customer, Admin, and Payment
Gateway.
2. Identify the Use Cases
• List the functionalities the system must provide to the actors.
• Example: Search Book, Place Order, Process Payment, Manage Inventory.
3. Define the System Boundary
• Draw a rectangle to represent the system, placing all use cases inside it.
• Example: A rectangle labeled “Online Bookstore System” enclosing all system
functionalities.
4. Establish Relationships Between Actors and Use Cases
• Draw lines to connect actors to the use cases they interact with.
• Example: Customer → Search Book, Customer → Place Order, Payment Gateway
→ Process Payment.
5. Add Include and Extend Relationships
• Identify mandatory sub-functions (include) or optional extensions (extend).
• Example: Place Order may include Validate Inventory, and Place Order may
extend Apply Discount.
6. Check for Generalization
• Determine if any actors or use cases share common behavior.
• Example: Both Admin and Customer inherit from a general actor User.
7. Review and Refine the Diagram
• Ensure all system functionalities and interactions are represented clearly.
• Validate with stakeholders to confirm accuracy and completeness.

Figure 1. Example Use Case Diagram for Online Bookstore System

5
Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies

Data Flow Diagram

A DFD visually shows how data moves through a system: where it comes from (external
entities), what processes transform it, where it is stored (data stores), and where it goes (outputs).
DFDs are great for analysis because they focus on data movement and transformations rather than
code.

Main Components
• Processes — circles / rounded rectangles (data transforms here).
• Data Flows — arrows (movement of data).
• Data Stores — open-ended rectangles (databases, files).
• External Entities — squares (users/systems outside the scope).

DFD Level
• Level 0 (Context Diagram): Entire system as one process + external entities.
• Level 1: Decomposes Level 0 into main subprocesses and primary data
stores/flows.
• Level 2+ : Further decomposition of complex subprocesses into finer detail.

Step-by-Step Procedure to Create a DFD

1. Define the system boundary and purpose
• Decide what system/process you are modeling and what the diagram should show
(scope).
• Example: “Online Course Enrollment — show how enrollment requests become
enrolled student records.”
2. Identify external entities (sources & sinks)
• List users and external systems that interact with your system.
• Example: Student, Registrar, Payment Gateway.
3. Identify major inputs and outputs
• For each external entity, note the data they send and receive.
• Example: Student → “Enrollment Request”; System → “Enrollment
Confirmation”.
4. List the high-level processes
• Describe the main transformations that occur to data (use short verb phrases).
• Example: Validate Request, Process Payment, Update Student Records.
5. Identify data stores
• Determine where data is stored or retrieved (DB tables, files).
• Example: Students DB, Courses DB, Payments Log.
6. Draw a Context Diagram (Level 0)
• Draw a single central process (the system) with arrows to/from external entities
showing major data flows.
• Keep it simple: system in center, entities around it.

6
 Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
7. Decompose into Level 1 processes
• Break the single process into 3–7 main subprocesses. Connect these with data
flows, and show interactions with data stores and external entities.
• Label each process clearly (Process 1: “Validate Enrollment”).
8. Refine to Level 2 (if needed)
• For any complex Level 1 process, expand it into smaller steps (Level 2), showing
detailed data flows and intermediate stores.
• Example: “Process Payment” → (a) Authorize Card, (b) Record Transaction, (c)
Send Receipt.
9. Review data flows for completeness and consistency
• Ensure every data flow has a source and a destination; no orphaned arrows. Check
naming consistency (use nouns for data, verb phrases for processes).
10. Validate with stakeholders
• Walk through the DFD with users, analysts, or developers to confirm it matches
reality and catches missing or redundant steps.
11. Iterate and version-control the diagram
• Update the DFD as requirements change. Keep versions and a short changelog.

Tips and Best Practices

1. Name clearly: Processes = verb + noun (e.g., “Validate Enrollment”); Data flows = data
noun (e.g., “Enrollment Request”).
2. Limit Level 1 to 3–7 processes for clarity.
3. Use consistent symbols and a legend if your audience may be unfamiliar.
4. Avoid mixing control flow with data flow — DFDs show data movement, not program
control or timing.
5. Keep context-level simple; add complexity only in lower levels.
6. Traceability: link DFD elements to requirements (use IDs) so validation and testing are
easier.

Common Mistakes to Avoid

1. Orphaned data flows (flows with no source or sink).
2. Ambiguous process names (e.g., “Process1” instead of “Validate Payment”).
3. Modeling control flow or UI navigation as a DFD (use activity/sequence diagrams instead).
4. Overcrowding Level 0 with too many details — it should be high-level.
5. Forgetting to validate with actual users — DFDs are only useful if accurate.

Rules and Guidelines in Drawing Data Flow Diagrams

Creating a Data Flow Diagram (DFD) requires following specific rules at each level to
maintain clarity, consistency, and accuracy. These rules ensure that the system is represented
properly from the highest-level overview down to detailed subprocesses.

7
Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
A. Rules for Level 0 (Context Diagram)
Level 0 shows the entire system as one single process.
1. The diagram must contain only one process, labeled Process 0, representing the whole
system.
2. The diagram must show interactions between the system and external entities (users,
devices, departments, systems).
3. No data stores should appear at this level.
4. Each data flow and external entity must be clearly named and should not repeat or cause
confusion.
5. The diagram must be simple and small enough to fit on one page for easy
understanding.
6. All data flows shown at Level 0 must match the inputs and outputs in Level 1, ensuring
consistency.

B. Rules for Level 1 Diagram

Level 1 breaks down Process 0 into major subprocesses.
1. Process 0 must be decomposed into two or more subprocesses (e.g., Process 1.0,
Process 2.0).
2. Each subprocess must have a unique number and descriptive name, using verb + noun
format (e.g., "Validate Request").
3. Data stores may now appear since internal storage is already considered at this level
4. External entities and data flows from Level 0 must remain visible and consistent.
5. Avoid crossing arrows and ensure clear data flow direction using arrowheads.

C. Rules for Level 2 Diagram

Level 2 further expands any complex subprocess from Level 1 into smaller, detailed
tasks.
1. A Level 2 diagram must match the inputs and outputs of the Level 1 process it expands.
2. Additional decomposition should be done only if needed to clarify system functionality.
3. Labels must remain consistent with upper levels to avoid confusion.
4. Maintain clean layout and readable flow lines, avoiding clutter.

D. General Rules for All DFD Levels

1. Every process must have at least one input and one output.
2. Naming is very important:
• Processes: Verb + Noun (e.g., "Verify Payment")
• Data Flows: Nouns (e.g., "Payment Details")
3. All symbols must follow standard DFD notation (Gane and Sarson):
• Process — Rounded rectangle
• Data Flow — Arrow
• Data Store — Open-ended rectangle (one-side)
• External Entity — Rectangle

8
 Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
4. No control flow or decision-making symbols (e.g., diamonds) should be used — that
belongs to Flowcharts or Activity Diagrams.
5. Keep diagrams simple, organized, and readable — avoid overcrowding.

UML (Unified Modeling Language) Class Diagram

A UML (Unified Modeling Language) Class Diagram is a type of static structure
diagram that represents the structure of a system by showing its classes, attributes, operations
(methods), and the relationships among objects. It is a key tool in object-oriented design,
providing a visual blueprint of a system.

Key Elements of a UML Class Diagram

1. Class – Represented as a rectangle divided into three compartments:
• Top compartment: Displays the class name (bold and centered).
• Middle compartment: Lists the attributes (data members) of the class.
• Bottom compartment: Lists the methods or operations the class can perform.
2. Relationships – Lines connecting classes that depict associations:
• Association: A basic connection between classes.
• Inheritance (Generalization): An “is-a” relationship where one class inherits
from another.
• Aggregation: A “whole-part” relationship where the part can exist
independently.
• Composition: A stronger “whole-part” relationship where the part cannot exist
without the whole.
• Dependency: Indicates that one class depends on another.
• Multiplicity: Specifies how many instances of a class relate to instances of
another class.

Purpose of UML Class Diagram

Class diagrams help in understanding overall system architecture, defining and
designing classes, and facilitating communication between stakeholders in the software
development process. They are also foundational for code generation in object-oriented
programming and are used extensively for both conceptual and detailed design.

Step-by-Step Guide in Creating a UML Class Diagram

1. Identify the Classes
• Determine the main objects or entities in the system.
• Examples: In a library system, classes could be Book, Member, Librarian.
2. List Class Attributes
• Identify the data each class should store.
• Example: Book may have title, author, ISBN.
• Attributes are listed in the middle compartment of the class rectangle.
3. Define Class Methods (Operations)

9
Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
• Determine the behaviors or functions each class can perform.
• Example: Book may have borrow(), return().
• Methods are listed in the bottom compartment of the class rectangle.
4. Determine Relationships Between Classes
• Analyze how classes interact or are connected. Common relationships include:
o Association: Basic connection (e.g., Member borrows Book).
o Inheritance (Generalization): “Is-a” relationship (e.g., Librarian
inherits from Person).
o Aggregation: “Whole-part” relationship, part exists independently
(e.g., Department has Professors).
o Composition: Strong “whole-part” relationship, part cannot exist
without whole (e.g., House has Rooms).
o Dependency: One class depends on another (e.g., Invoice depends on
Customer).
5. Define Multiplicity
• Specify how many instances of a class can relate to instances of another class.
• Example: One Member can borrow multiple Books (1 → *).
6. Draw the Diagram
• Represent each class as a rectangle with three compartments (name, attributes,
methods).
• Connect classes using lines to show relationships and annotate with multiplicity
where applicable.
7. Review and Refine
• Check the diagram for completeness and accuracy.
• Ensure relationships correctly reflect system behavior.
• Make sure the diagram is clear and easy to read.

Project Artifacts
Project artifacts are essential documents and deliverables produced throughout the
software development life cycle (SDLC). They help capture, communicate, and verify
requirements, design, and testing to ensure successful project progression.

Requirements Specification Document (RSD)

Also called the Software Requirements Specification (SRS), this document:
• Contains detailed descriptions of the system's functional and non-functional
requirements.
• Serves as a formal agreement between stakeholders and developers on what the
software should do.
• Includes use cases, user stories, constraints, assumptions, and acceptance criteria.
• Provides a foundation for the design, development, and testing phases.

10
 Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
Example. For an online bookstore:
• Functional requirement: Users must be able to search for books by title, author, or
ISBN.
• Non-functional requirement: Search results must be returned within 2 seconds.
• Use case: Customer searches for a book → System displays matching results →
Customer selects a book → System shows book details.

Design Documents
These documents include the Software Architecture Document (SAD) and Detailed Design
Document (DDD):
• Define the system's architecture, components, interfaces, and data flow.
• Use models such as UML diagrams (class, sequence, activity) to visualize structure
and behavior.
• Architecture documents cover high-level system organization and technology
choices.
• Detailed design documents specify module-level design and interactions.

Example: For the same online bookstore:

• Class diagram: Shows classes like Book, Customer, and Order with attributes and
methods.
• Sequence diagram: Illustrates the steps when a customer places an order, from
selecting a book to completing payment.

Test Plans and Test Cases

• Test Plan: Defines the scope, approach, resources, and schedule for testing
activities.
• Describes types of testing (unit, integration, system, acceptance) and the testing
environment.
• Test Cases: Detail specific scenarios to verify that the software meets requirements.
o Each test case includes inputs, execution steps, expected results, and
pass/fail criteria.

Example: For the online bookstore:

• Test case: Verify that the checkout process calculates the total price correctly.
o Input: 2 books priced at $10 each, with 5% tax.
o Steps: Add books to cart → Proceed to checkout → Apply tax.
o Expected result: Total price = $21.

11
Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies

Synthesis
Process models and diagrams serve as the foundation for understanding and improving
workflows across different domains. By representing sequences, decisions, and interactions
visually, they make complex processes accessible and actionable. For example, process diagrams
in software development or hospital management highlight inefficiencies and allow teams to
redesign operations for improved performance. Similarly, DFDs and UML diagrams provide
structured, detailed representations of system processes, data flow, and object relationships, which
are essential for accurate analysis and development.
Project artifacts complement these visual tools by formalizing requirements, designs, and
testing procedures. Requirements Specification Documents ensure stakeholders and developers
align on expectations, while design documents and UML diagrams provide a roadmap for system
construction. Test plans and cases validate functionality and confirm the system meets intended
objectives. Collectively, process models, diagrams, and artifacts enable developers to plan,
communicate, and execute projects systematically, improving efficiency, accuracy, and quality.

Key Takeaways
The following are the key takeaways from this module:
• Process models provide a visual representation of workflows, helping identify
inefficiencies.
• Process diagrams (flowcharts) clearly communicate work sequences and decision points.
• Use Case Diagrams focus on what the system does, showing actors and system interactions.
• DFDs depict how data moves through a system, emphasizing transformations and storage.
• UML Class Diagrams model objects, attributes, methods, and relationships in object-
oriented systems.
• Project artifacts (RSD, design docs, test plans) formalize requirements, designs, and
validation processes.
• Different development domains (software, database, network, website) use specific models
and diagrams for clarity.
• Include, Extend, and Generalization relationships enhance use case diagrams by showing
sub-functions and inheritance.
• Proper decomposition in DFDs (Level 0 → Level 1 → Level 2) ensures clarity and detailed
analysis.
• Clear labeling, standard symbols, and stakeholder validation are essential for accurate
diagrams.

Supplementary Resources
If you’d like to explore the topic further or deepen your understanding, here are some
optional readings and materials you can check:

12
 Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies

Readings
Hironori, W. (2025). Guide to the Software Engineering Body of Knowledge v4.0a. IEEE
Computer Society. [Link]
[Link]
Pressman, R.S. (2024). Software Engineering. A Practitioner’s Approach 7th Edition. McGraw
Hill. [Link]
7th_ed_software_engineering_a_practitioners_approach_by_roger_s._pressman_.pdf

References
5 Basic software development Process models - InvoZone. (n.d.). InvoZone.
[Link]
choose/
Data Flow Diagram - Everything you need to know about DFD. (n.d.).
[Link]
Ibrahim, R., & Yen, S.Y. (2010). Formalization of the Data Flow Diagram Rules for Consistency
Check. International Journal of Software Engineering and Application. 1(4).
[Link]
Miro. (n.d.). What is a Data Flow Diagram? Examples, Symbols, and Use Cases.
[Link] [Link]
Patterson, B. (n.d.). Data flow diagram: Components, purpose, and how to create. RudderStack.
[Link]
Process Model: Definition, explanation, and use cases | Vation Ventures. (n.d.).
[Link]
and-use-cases
Sulemani, M., & Sulemani, M. (n.d.). What is a software process model? Top 7 models explained.
Educative. [Link]
Contributor, T. (2020, July 24). use case diagram (UML use case diagram). WhatIs.
[Link]
Awati, R., & Stuart, A. (2024, May 10). What is business process modeling? TechTarget.
[Link]
GeeksforGeeks. (2025, May 19). Levels in Data Flow Diagrams (DFD). GeeksforGeeks.
[Link]
diagrams-dfd/

13
Unit 2: Understanding Software Development Lifecycles and Requirements Specifications
Application Development and Emerging Technologies
GeeksforGeeks. (2025, May 19). What is DFD (Data Flow Diagram)? GeeksforGeeks.
[Link]
diagram/
GeeksforGeeks. (2025, July 23). Software Development Life Cycle (SDLC) models.
GeeksforGeeks. [Link]
software-development-models-used-in-industry/
Belcic, I., & Stryker, C. (2025, August 20). Process modeling. IBM.
[Link]
Miller, J. (2025, November 10). Process modeling: your blueprint for getting work done. Nintex.
[Link]

14