Software Engineering Project Management (ISYS 1106 / 1108 / 3474)

Week 1 – Comprehensive Study Guide

Overview

This week's content introduces the foundational concepts of Software Engineering Project Management (SEPM) and its vital intersection with Requirements Engineering (RE). It explores the definition of a project, the reasons why software projects frequently fail, and the critical role of stakeholder communication. Furthermore, the materials detail the methodologies used to manage projects (such as Waterfall and Agile), how to structure a Work Breakdown Structure (WBS), and how to document project foundations using a Vision & Scope Document or a Project Charter.

Key Concepts

Project

Definition: A project is a temporary endeavor undertaken to create a unique product or service. It consists of a group of inter-related activities planned and executed in a certain sequence.

Why it matters: Projects are critical components of a business strategy used to manage changes in technology, infrastructure, and work processes.

Example: Developing a new software solution or introducing a new system across multiple business units.

Project Management (PM)

Definition: A formalised and structured method of managing change in a rigorous manner, focusing on producing defined deliverables by a certain time, to a defined quality, and with a given level of resources and budget.

Why it matters: All projects are carried out under conditions of uncertainty. Effective PM minimizes this uncertainty and manages the human factors and complex interdependencies that can derail success.

Requirements

Definition: A specification of what should be implemented, describing how the system should behave, its properties, attributes, or constraints on the development process.

Why it matters: Incomplete or wrong requirements are the leading cause of project failure. Getting them wrong cripples the resulting system and is incredibly difficult to rectify later.

Stakeholder

Definition: A person or organization who influences the system's requirements or who is impacted by that system.

Why it matters: Missing stakeholders means missing requirements. Different stakeholders have different views, needs, and expectations that must be balanced for the project to be accepted.

Vision & Scope Document

Definition: A document that collects all business requirements into a single deliverable, defining the business case for the project in non-technical language.

Why it matters: It sets the stage for subsequent development work by specifying and justifying the project to executive sponsors and funding authorities.

Detailed Explanations

1. The Reality of Software Projects and Failure

Developing software is not just about writing code; it involves complex processes, communication, and management. Projects often fail due to:

• Incomplete requirements (13.0%)
• Lack of user involvement (12.4%)
• Lack of resources (10.5%)
• Unrealistic expectations (9.9%)

All projects operate under uncertainty due to human factors, complex interfaces, and assumptions that may turn out to be wrong. The cost of correcting these errors grows rapidly as the project progresses through its life-cycle.

2. Requirements Engineering (RE)

Requirements act as a translation of user problems into a form that can be converted into a software system. RE engineers act as translators between the "User World" (stakeholders without technical knowledge) and the "Software System" (developers using technical jargon).

There are multiple types of requirements:

• Business Requirements: Why the organization is doing the project and expected benefits
• User Requirements: Captured via use cases
• System Requirements: Include functional requirements, external interfaces, quality attributes (non-functional requirements), and constraints

3. Goals of Project Management (The Triple Constraint)

Project performance is measured by the degree to which three main goals are achieved:

• Scope: What needs to be done (capabilities and deliverables)
• Cost: The resources and budget required
• Time: The schedule and deadlines

Note: Quality is sometimes considered a fourth goal, or integrated as a part of the Scope.

4. Vision & Scope Document Breakdown

This document sits on the boundary between PM and RE. It contains four main sections:

Business Requirements

Covers the background, business opportunity, and business risks. It importantly includes Success Criteria, which must be SMART (Specific, Measurable, Attainable, Relevant, Time-Bound). Avoid vague terms like "good, easy, fast, secure."

Vision of the Solution

Summarizes the long-term intent of the product (Vision Statement) and lists its major features.

Scope and Limitations

Identifies what portion of the vision will be built in the current release. It clearly draws the boundary of what is out of scope to manage expectations.

Business Context

Details stakeholder profiles, project priorities, and the operating/deployment environment.

5. Project Charter (PMBOK)

The Project Management Body of Knowledge (PMBOK) outlines the Project Charter, which serves a nearly identical purpose to the Vision & Scope document but has a different structure. You should never use both in the same project.

The Charter includes:

• Purpose and Objectives (Mission statement and deliverables)
• Overview and Schedules (Includes milestones and a Work Breakdown Structure)
• Resource Requirements and Personnel/Stakeholders
• Evaluation Methods and Risk Management (Disasters and contingency plans)

6. Project Methodologies

Methodologies document the steps to bring a project to completion.

• Waterfall / Traditional: Linear sequential model where requirements are locked early, and development starts only after planning. It is inflexible to changes.
• V-Modell: An improvement on Waterfall with a greater emphasis on testing (verification done before coding), but still inflexible.
• Agile: Relies on iterative cycles, lean governance, and continual customer involvement.

7. Work Breakdown Structure (WBS): Traditional vs. Agile

Traditional WBS: Very detailed, phase-oriented, and dictates exactly who is doing what and when.

Agile WBS: Acts more like a high-level release plan. It is feature-oriented, maps dependencies among features/epics, and importantly, includes no allocation in advance to particular team members.

Diagrams and Processes

The Requirement Translation Process

User World (User Problems) ↔ Requirements Engineer (Translator) ↔ Software System (Developers)

Context Diagram Flow

Context diagrams depict the scope at a high level without revealing system internals.

External Entity (e.g., User) ↔ [Labeled Flows (Data/Signals)] ↔ [System Boundary (Circle)]

Types of Requirements Hierarchy

Business Requirements / Rules → Vision & Scope Document → User Requirements → Functional & System Requirements → Software Requirements Specification

Important Definitions

Key Takeaways

• Software engineering requires strong soft skills, conflict resolution, negotiation, and communication, alongside coding
• Projects primarily fail due to issues bordering PM and Requirements Engineering, such as incomplete requirements and lack of user involvement
• "Having interest in the system" does not automatically mean a stakeholder has an "interest in the project's success"
• Success metrics in a Vision & Scope document must be quantitative and measurable (SMART). Words like "good," "fast," or "robust" are unacceptable
• The Vision & Scope document and the Project Charter serve the same purpose; you must choose one format at the beginning of the project and not use both
• Traditional WBS assigns specific team members to tasks in advance, whereas Agile WBS focuses on high-level features and epics without pre-allocating tasks to individuals

Possible Exam / Quiz Questions

1. Concept Explanation

Explain the difference between a business assumption and a business dependency in the context of a Vision & Scope document.

Hint: Assumptions are statements believed to be true without proof, while dependencies relate to external factors like third-party deliverables.

2. Scenario-Based

A client provides the following success metric for their new application: "The system should be scalable and process orders fast." Why is this a poor success metric, and how would you fix it based on course principles?

Hint: It uses vague qualitative terms instead of quantitative, measurable metrics. A fix would be: "Process 1000 orders per minute with a response time under 2 seconds."

3. Short Answer

What are the three core goals (the "triangle") of Project Management?

Hint: Scope, Cost, and Time.

4. WBS Evaluation

You are reviewing a Work Breakdown Structure (WBS) for an Agile project. You notice that "Task 2.1: Implement Login UI" is assigned to "Developer John" for weeks 3-4. Why is this incorrect according to Agile WBS principles?

Hint: Agile WBS does not allocate tasks to particular team members in advance.

Additional Notes

Overlap of PM and RE

The course heavily emphasizes that Project Management and Requirements Engineering are deeply intertwined. Documents like the Business Case, Vision & Scope, and Project Charter sit directly on the boundary between these two disciplines.

Cost of Error Correction

The cost of fixing a requirement error grows exponentially as the project moves from the analysis stage through design, coding, and testing. This highlights why investing time in thorough Vision & Scope documentation is critical.