Stage 1 – Project Framing & Concept of Operations

Capstone Design

Imron Rosyadi

Stage 1 – Project Framing & Concept of Operations

From Needs to Validated Systems using the V‑Model & ISO/IEC/IEEE 29148

Capstone Design – Stage 1 Focus Session

This is the first deep‑dive session into Stage 1 of the capstone process. Students have already seen the big picture (V‑Model, nine stages).

Goal of this deck: - Zoom in on Stage 1 – Project Framing & Concept of Operations. - Explain 29148: Business or Mission Analysis and Stakeholder Identification in concrete, undergraduate‑friendly terms. - Show how this becomes DCP‑100A Project Proposal. - Use ECE‑relevant examples so they see why this matters for their projects.

Remind them: Stage 1 is about what & why, not how. No schematics, no detailed code yet – those come later.

Learning Objectives – Stage 1 Session

By the end of this session, you will be able to:

1. Explain the purpose of Stage 1 – Project Framing & Concept of Operations (ConOps).
2. Describe the 29148 Business or Mission Analysis process and its typical activities.
3. Describe the 29148 Stakeholder Identification process and why it is critical.
4. List the key contents and deliverables of DCP‑100A Project Proposal.
5. Apply these ideas to ECE capstone examples and avoid “solution first” thinking.

Emphasize: these are practical objectives. Students should walk away knowing exactly what they must produce for Stage 1 and why each part exists in industry practice.

Where Stage 1 Fits in the V‑Model

Note

Stage 1 lives at the very top‑left: - Define the business/mission need. - Understand the operational context. - Identify who cares (stakeholders).

Draw their attention to the highlighted Stage 1 box. Explain: if Stage 1 is weak or rushed, everything downstream (requirements, design, tests) will be misaligned.

Analogy: if you start building a bridge without agreeing on where it needs to connect and what it should carry (cars? trains?), the detailed design can be “beautiful” but completely wrong.

Stage 1 in the Course Framework

In course terms (from the intro deck):

• V‑Model Level: Concept / Need
• 29148 Processes:
  • Business or Mission Analysis
  • Stakeholder Identification

Capstone Activities (Stage 1):

• Define the problem domain and business/mission need.
• Analyze existing solutions and their limitations.
• Characterize environment & context:
  • Users
  • Constraints
  • External systems
• Select a solution class (type of solution), not a design.
• Produce a Concept of Operations (ConOps).

Key Deliverable:

• DCP‑100A – Project Proposal
  • Problem statement
  • Stakeholder map
  • Operational scenarios
  • High‑level success criteria

Tip

Stage 1 is about the story of the project: Who has what problem, in what context, and what would “success” look like?

Connect back to the earlier “Course Stages Overview” slide. Tell them: DCP‑100A is the artifact that proves you did Stage 1 properly. Gate review for Stage 1 will focus strongly on: - Clarity of problem. - Completeness of stakeholder picture. - Realistic, well‑explained ConOps.

ISO/IEC/IEEE 29148 – Processes in Stage 1

In Stage 1 we primarily apply:

1. Business or Mission Analysis
   • Why does this system exist?
   • What business or mission outcomes must it support?
2. Stakeholder Identification
   • Who cares about this system?
   • Who is affected, who operates it, who maintains it, who pays for it?

Later stages use other 29148 processes (Stakeholder Needs, System Requirements, etc.), but Stage 1 is the front door.

Clarify that 29148 is a requirements engineering standard. We’re using only a subset of its processes.

For this lecture, we’ll zoom into: - What Business/Mission Analysis looks like in a capstone context. - How to systematically identify stakeholders so nobody critical is forgotten.

29148: Business or Mission Analysis – Concept

Purpose: To understand the business context or mission context that drives the need for a new or modified system.

Typical questions it answers:

• What problem or opportunity are we addressing?
• What is the mission (for non‑commercial systems) or business goal (for commercial ones)?
• What outcomes do stakeholders care about?
• What is the operational environment (physical, technical, organizational)?
• What constraints limit possible solutions?

Important

If you can’t articulate the mission/business case, you don’t yet have a good project.

Use examples that students understand: - Mission: “Provide safe, reliable power to a remote village.” - Business goal: “Reduce lab equipment downtime by 30% to save maintenance costs.”

Explain: Engineers often get “assignments” like “build an app” or “design a sensor node,” but 29148 wants us to ask why first.

Business vs Mission – ECE Examples

Business‑oriented example:

Project: Smart Lab Energy Monitor

• Business problem: Lab electricity bills are high; facilities wants to cut costs without compromising experiments.

• Desired outcomes:

  • Identify energy‑hungry equipment and usage patterns.
  • Provide actionable data to lab managers.

Mission‑oriented example:

Project: Disaster‑Resilient Sensor Network

• Mission context: Emergency services need situational awareness after earthquakes or floods.

• Desired outcomes:

  • Maintain communication when mains power and some infrastructure are down.
  • Provide key sensor data (e.g., water level, gas leak detection) to responders.

Use these to highlight the difference: - Business: focus on cost, efficiency, competitive advantage. - Mission: focus on public safety, research goals, teaching, etc.

But both require clear problem framing and outcomes before we talk about specific hardware or software.

29148: Business/Mission Analysis – Typical Activities

In 29148, activities commonly include:

1. Problem / Opportunity Definition
   • Describe current situation (AS‑IS).
   • Describe desired future situation (TO‑BE).
2. Context and Environment Analysis
   • Operational environment (physical, network, regulatory).
   • Systems and processes that interact with your proposed system.
3. Operations Concept Analysis
   • High‑level description of how the system will be used over time.
4. Feasibility Consideration
   • Technical feasibility (can we build it?).
   • Resource feasibility (time, budget, skills).
5. Business/Mission Case Formulation
   • Rationale for doing the project (benefits vs costs/risks).

Translate “standard‑speak” into capstone‑speak:

• You’re not writing a full corporate business case, but you are expected to:
  • Clearly state the problem.
  • Analyze the context.
  • Outline how the proposed system will be used (ConOps).
  • Argue that the project is worth doing and feasible in two semesters.

Business/Mission Analysis vs Requirements

• Stage 1:
  • What is the problem or mission?
  • In what context do we operate?
  • What high‑level outcomes do we want?
• Stage 2 & 3:
  • Turn this context into requirements.
  • First in stakeholder language (Stage 2), then in technical form (Stage 3).

Note

Stage 1 sets the direction; Stages 2–3 formalize what exactly must the system do.

Sometimes students try to write detailed requirements in Stage 1. Clarify: Stage 1 should stop at “what problem, what context, what kind of solution”. Precision and testability come later.

29148: Stakeholder Identification – Concept

Purpose: To identify all parties that have an interest in the system or are affected by it, so their needs can be captured later.

“Stakeholder” includes:

• Direct end users
• Operators and maintainers
• Managers and decision‑makers
• Safety or regulatory bodies
• IT/network admins, lab technicians
• Faculty advisors, sponsors, teaching staff (in our course)

Warning

Missing a critical stakeholder early → hidden requirements pop up late, causing rework, scope creep, or project failure.

Example: A team builds a lab monitoring system only thinking of professors as stakeholders. Later they discover: - Lab technicians need maintenance alerts. - IT department cares about network security. - Facilities team needs specific data formats.

Each “late discovery” means rework. Stakeholder identification aims to minimize that.

Stakeholder Types – ECE Capstone Context

Typical stakeholder roles in our projects:

• Primary users
  • Students, lab technicians, clinicians, drivers, etc.
• System owners / sponsors
  • Faculty PI, industry partner, lab manager.
• Support and maintenance
  • IT support, lab techs, biomedical engineers.
• Regulators / compliance
  • Safety office, ethics board, sometimes external standards (e.g., FCC, medical).

In this course specifically, also include:

• Course staff
  • Instructor, TA → care about grading, documentation, safety.
• University services
  • Campus network/security, facilities.
• Future teams
  • Students who may extend or maintain your system next year.

Stress that “stakeholder” is broader than “the person who asked for the project.” Encourage teams to be inclusive when brainstorming stakeholders, then prioritize which ones are most critical for Stage 1.

Stakeholder Identification – Typical Activities

As described in 29148, tailored to our course:

1. Identify candidate stakeholders
   • Brainstorm a list of all who might interact with or be affected by the system.
2. Classify / group stakeholders
   • Users, owners, maintainers, regulators, external systems, etc.
3. Analyze stakeholder interests
   • What does each group want from the system?
   • What concerns or constraints do they have?
4. Prioritize stakeholders
   • Which ones are critical to success or acceptance?
5. Document a stakeholder map
   • For DCP‑100A: roles, interests, potential conflicts.

Tip

Treat stakeholder identification as a living activity – you may discover new stakeholders later, but Stage 1 should capture the obvious major ones.

Make this tangible: - Suggest using a simple table or diagram listing each stakeholder group and their key interests. - Mention that this feeds directly into Stage 2 (Stakeholder Requirements), where we turn these interests into STR-*.

From 29148 Processes to Stage 1 Deliverables

29148 Says You Should:

• Analyze business/mission context.
• Identify and classify stakeholders.
• Understand the operational environment.

In this course, you will:

• Write a Problem Statement and Context section.
• Create a Stakeholder Map.
• Define Operational Scenarios / Use cases.
• Propose a high‑level concept of operations (ConOps).

All of this goes into:

DCP‑100A – Project Proposal

Sections typically include:

1. Background & Problem Description
2. Business/Mission Need and Objectives
3. Stakeholder Identification & Roles
4. Operational Context & Environment
5. Concept of Operations (ConOps)
6. Preliminary Solution Class and Scope
7. Risks & Feasibility (high level)

Remind students: DCP‑100A does not lock every detail forever. But it does become a baseline for later traceability. If the mission or stakeholders change significantly later, that’s a controlled change, not a casual pivot.

Concept of Operations (ConOps) – What It Is

A Concept of Operations (ConOps) is a narrative and graphical description of:

• How the system will be used in its real environment.
• Who interacts with it and what they do.
• Sequences of events (before, during, after use).
• Operational modes (normal operation, startup, shutdown, failure modes, maintenance).

It is written mainly in stakeholder language, not low‑level engineering details.

Note

Think of ConOps as a storyboard of your system in action.

Contrast ConOps with design docs: - ConOps: “Lab technician logs in, sees alerts, acknowledges them.” - Design: “We use MQTT broker X, JSON payload Y, database Z.”

In Stage 1 we focus on ConOps; specific design choices belong in later stages.

ConOps – Typical Content (Adapted from 29148)

A good ConOps in DCP‑100A should cover:

1. Overview of the system’s purpose
   • One or two paragraphs in plain language.
2. Operational environment
   • Physical: lab, vehicle, hospital room, outdoor, etc.
   • Technical: network, power, existing systems.
3. Operational scenarios
   • Step‑by‑step story of typical use cases.
   • Include normal and abnormal (error/failure) cases.
4. Roles and responsibilities
   • Who does what during operation, setup, maintenance.
5. Assumptions and constraints
   • “We assume campus Wi‑Fi is available.”
   • “System must run on battery for at least 8 hours.”

Tell students: ConOps is where you clearly show reviewers that you understand real‑world use, not just technology.

Gate reviewers will ask: “Is this scenario realistic? Are key actors included? Are constraints recognized?”

Multi‑Scenario ConOps – Smart Lab Sensor Network

Example Project: Smart Lab Sensor Network (from intro deck).

Scenario 1 – Normal Operation:

1. Sensors in each lab periodically measure temperature and humidity.
2. Nodes send data wirelessly to a gateway.
3. Gateway forwards data to a campus server.
4. Dashboard displays real‑time conditions for each lab.
5. Lab tech checks dashboard at start of day.

Scenario 2 – Alarm Condition:

1. Temperature in Lab 3 > 28°C for >10 minutes.
2. Node continues to send readings; server detects pattern.
3. System generates an alert within 2 minutes.
4. Lab tech receives visual and/or email alert.
5. Tech inspects room, adjusts HVAC or notifies facilities.

Scenario 3 – Maintenance Mode:

1. Tech puts node into maintenance mode from dashboard.
2. Node stops generating alarms but still logs data.
3. Tech replaces sensor and runs a quick sanity check.

Explain how these scenarios would appear in the DCP‑100A ConOps section: - Give each scenario a name and brief description. - Use sequence lists or simple time‑sequence diagrams.

Emphasize: each scenario hints at later requirements, but we don’t yet formalize them as STR-* or REQ-*. That’s Stage 2–3.

Visualizing ConOps – High‑Level ECE Example

• This is not architecture design yet; it’s a conceptual view of how things interact.
• Helps you explain operational flow in ConOps: sensor → gateway → server → user.

Make the distinction clear: - This diagram at Stage 1 is descriptive: “There will likely be sensor nodes, some central gateway, some dashboard.” - Detailed protocols, exact hardware, and internal module breakdown belong in Stage 4.

But such a diagram helps stakeholders visualize the proposed solution class and operations.

Stage 1 Activities – Course‑Level View

Your Stage 1 work, step‑by‑step:

1. Clarify the project idea
   • From sponsor brief, faculty suggestion, or your team’s idea.
   • Rephrase it in your own words, check your understanding with advisor/sponsor.
2. Perform Business/Mission Analysis
   • Define the problem or mission clearly.
   • Analyze benefits, costs, and risks at a high level.
3. Identify Stakeholders
   • List stakeholders, their roles, and their interests.
4. Analyze Operational Context
   • Where and when will the system be used?
   • What external systems does it touch?
5. Develop ConOps (Scenarios & Modes)
   • Create several key operational scenarios that illustrate usage.
6. Check Feasibility & Scope
   • Ensure the project is doable within time and resources.
7. Write & Submit DCP‑100A
   • Integrate all the above into a coherent Project Proposal.

Encourage teams to iterate: - Talk to stakeholders → refine problem statement → update ConOps. - Don’t treat DCP‑100A as “one and done”; treat drafts as normal.

Advise them to start a shared document early and refine over 1–2 weeks rather than last‑minute.

DCP‑100A – Suggested Structure

A typical DCP‑100A might include these numbered sections:

1. Introduction & Background
   • Project title, team members, sponsor/advisor.
   • Brief background of application domain.
2. Problem / Mission Statement
   • Clear, concise summary of the problem or mission.
3. Business/Mission Objectives & Value
   • What improvements or outcomes are expected?
4. Stakeholder Identification & Roles
   • Table or diagram of stakeholders (role, interest, influence).
5. Operational Context & Constraints
   • Environment, existing systems, regulatory or safety constraints.
6. Concept of Operations (ConOps)
   • Operational scenarios
   • Modes of operation (normal, degraded, maintenance)
7. Preliminary Solution Class & Scope
   • Proposed type of solution (e.g., “wireless sensor network + web dashboard”).
   • Out‑of‑scope items, key assumptions.
8. Initial Risks and Feasibility Assessment
   • Major technical, schedule, or resource risks.

Mention: Your instructor may give a template for DCP‑100A – follow it, but this structure explains the intent behind each section.

Also note that DCP‑100A should be readable to a non‑technical stakeholder; avoid jargon when possible or explain it.

Example – Partial DCP‑100A for Smart Lab Sensor Network

Problem / Mission Statement (example):

Teaching laboratories in the ECE department currently rely on manual checks by lab technicians to detect thermal issues that may damage equipment or create uncomfortable working environments. There is no central, real‑time view of lab conditions, leading to delayed detection of overheating and inefficient energy use.

Business/Mission Objectives:

• Provide real‑time visibility of temperature/humidity in all teaching labs.
• Enable early detection of overheating to protect equipment and occupants.
• Support data‑driven energy optimization by facilities staff.

Stakeholder Snapshot (excerpt):

Stakeholder	Role	Interest / Concern
Lab Technicians	Primary users	Easy monitoring, reliable alerts
Facilities Manager	System owner/sponsor	Energy savings, reduced damage costs
IT Department	Network/security support	Secure, low‑maintenance integration
Faculty Instructors	Indirect users	Minimal disruption to teaching

ConOps Scenario (short excerpt):

Each morning, the lab technician opens a web dashboard that shows the current temperature and humidity in all labs. If any lab has been above 28°C for more than 10 minutes, the dashboard displays a red alert icon. The technician can click the alert to see a trend graph and notes, then decides whether to adjust HVAC or contact facilities.

Use this as a concrete illustration. Ask students whether this text answers: - What is the current pain? - What value does the new system provide? - Who are key stakeholders and what do they care about?

Highlight that no specific microcontroller or wireless protocol is mentioned yet – and that’s intentional.

ECE Example – Embedded Medical Monitor

Project concept: A wearable heart‑rate and activity monitor for post‑surgery patients, sending data to hospital staff.

Business/Mission Analysis (high‑level):

• Mission: Reduce hospital readmissions by monitoring recovery at home.
• Current state: Nurses rely on occasional phone calls and clinic visits.
• Desired state: Continuous monitoring to detect issues early.

Stakeholders (initial list):

• Patients (primary wearers)
• Cardiologists and nurses (data users)
• Hospital IT/security (data storage, privacy)
• Regulatory bodies (medical device requirements)
• Family members (secondary stakeholders)

ConOps scenario (simplified):

1. Before discharge, nurse configures wearable with patient ID and thresholds.
2. Patient wears device at home; it measures heart rate and activity continuously.
3. Device transmits periodic summaries and real‑time alerts via smartphone gateway.
4. Hospital dashboard flags patients whose metrics exceed pre‑set thresholds.
5. Nurse reviews alerts daily and follows up with selected patients.

Use this to show how Stage 1 for a medical device must already think about: - Regulatory aspects (data privacy, reliability). - Operational environment (home use, battery life, connectivity).

Again, emphasize: no need to specify exact ADC or BLE module in Stage 1. Focus is on context and operations.

ECE Example – Autonomous Campus Shuttle (Controls/Embedded)

Project concept: A scaled autonomous shuttle (small vehicle platform) for campus tours on predefined routes.

Business/Mission Analysis:

• Mission: Demonstrate future autonomous transit, improve visitor experience.
• Current state: Human‑driven carts for guided tours.
• Desired outcomes: Reduced staffing, novel experience, data for research.

Stakeholders:

• Campus visitors (passengers)
• Shuttle operators / supervisors
• Campus safety & risk management
• Vehicle maintenance staff
• Research group (using data/logs)

ConOps highlights:

• Normal operation: shuttle follows route, stops at landmarks, announces info.
• Abnormal: obstacle detected → shuttle slows/stops and requests human takeover.
• Maintenance: daily pre‑drive check and periodic calibration by staff.

This example helps controls / robotics‑oriented students see that Stage 1 still applies: - Safety stakeholders and procedures must be recognized early. - Campus risk management might impose constraints (e.g., max speed, areas where driving is prohibited).

These factors must be visible in DCP‑100A, not discovered right before demo day.

Stakeholder Map – Simple Visual

• Each arrow represents a relationship (use, ownership, support, impact).
• You can annotate with keywords (e.g., “uses”, “maintains”, “funds”).

Encourage teams to draw a similar diagram (whiteboard, then digitize) during Stage 1. Then turn it into a neat artifact for DCP‑100A.

This helps reveal missing stakeholders: “Wait, who approves device installations in labs? Safety office?”

Activity – Stakeholder Brainstorm (In‑Class)

Quick exercise (5–7 minutes):

1. In groups (or individually), pick one of these example systems:

   • Campus bike‑sharing system with smart locks.
   • Remote lab access system for ECE experiments.
   • Smart parking lot occupancy system.

2. List as many stakeholder groups as you can think of.

3. Classify each as:

   • Primary user, indirect user, owner/sponsor, maintainer, regulator, course staff, etc.

4. Share 1–2 surprising stakeholders with the class.

Tip

When you pick a project idea for your team, do the same exercise and put the results into your DCP‑100A.

Actually run this if time allows. Use it to show them how quickly stakeholder lists expand beyond “the obvious one user.”

Capture common misses: - Security/IT. - Cleaning staff (for physical installations). - Other departments sharing the same lab space.

Stage 1 Deliverables – Key Quality Criteria

For the Stage 1 Gate Review (DCP‑100A), reviewers will look for:

1. Clear Problem / Mission Statement
   • Specific, understandable, not just “build X”.
2. Coherent Business/Mission Case
   • Why is this worth doing? Who benefits?
3. Comprehensive Stakeholder Identification
   • At least all major categories relevant to the project.
4. Concrete, Realistic ConOps
   • Several well‑thought‑out operational scenarios.
5. Realistic Scope & Feasibility
   • Fits within calendar, resources, and team skills.

Important

If your DCP‑100A cannot convince reviewers that you understand the problem, context, and stakeholders, you will likely not pass the Stage 1 Gate.

Be honest that failing Stage 1 gate is possible – but avoid scaring them unproductively. Frame it as: “We would rather catch unclear projects now than watch them collapse in Week 10.”

Encourage teams to ask for feedback on drafts early.

Avoiding “Solution‑First” Thinking

Common trap: > “We want to build a system using Raspberry Pi + LoRa + MQTT because it’s cool.”

Missing: Who needs what, and why?

Instead, ask first:

• What problem are we solving?
• Who are the stakeholders, and what do they care about?
• In what environment will this run (Wi‑Fi? cellular? no network)?
• What constraints exist (power, safety, cost, privacy)?

Only then choose: microcontroller vs SBC vs FPGA, LoRa vs Wi‑Fi, etc.

Warning

“Technology shopping list” ≠ Stage 1. You must lead with needs, context, and ConOps.

You can tell a personal anecdote if you have one: a project that over‑specified its tech stack early and later discovered it didn’t fit stakeholder needs or constraints.

Reinforce: Stage 1 is designed to protect teams from premature tech commitment.

Linking Stage 1 to Traceability

• Stage 1 does not yet produce STR-* IDs, but it feeds into them.
• Every stakeholder requirement in Stage 2 should trace back to:
  • A stakeholder identified in Stage 1.
  • A business/mission objective from Stage 1.

Note

Think of Stage 1 as building the roots of the traceability tree.

Connect back to the earlier “Traceability: Backbone of the Project” slides from the course intro:

• Stage 1 justifies why the later requirements exist.
• During final reviews, we may ask: “Which mission objective does this requirement serve?”

That’s the upstream traceability from REQ-* and STR-* back to Stage 1.

Summary – Stage 1 Key Points

1. Stage 1 – Project Framing & ConOps applies 29148’s:
   • Business or Mission Analysis
   • Stakeholder Identification
2. Your main job is to understand and document:
   • The problem/mission and business value.
   • The stakeholders and their roles.
   • The operational context and concept of operations.
3. The primary deliverable is DCP‑100A Project Proposal, which must:
   • Convince reviewers that the project is meaningful, feasible, and well‑framed.
   • Lay the foundation for Stage 2 stakeholder requirements (STR-*).
4. Strong Stage 1 work prevents late surprises and supports clean traceability through the V‑Model.

Important

Before you design circuits or write code, you must first engineer a well‑framed problem and mission. That is the essence of Stage 1.

Close by previewing what comes next:

• Next session: we turn the stakeholder and mission understanding from Stage 1 into Stakeholder Requirements (Stage 2).
• Suggest homework: draft a preliminary problem statement and identify at least 5 stakeholder groups for your project idea.

Invite specific questions about: - What level of detail is expected in DCP‑100A. - How to handle projects with unclear sponsors. - How to document uncertainty or assumptions in Stage 1.