Problem Identification and Requirements Engineering

Introduction and context

A major project begins long before a circuit is soldered, code is compiled, or a prototype is tested. It begins with a defensible answer to a prior question: what electrical engineering problem is worth solving, for whom, and under what constraints? Weak projects often start with a technology—such as a microcontroller, photovoltaic panel, battery, or machine-learning model—and then search for a problem. Strong projects begin with an authentic need and select technology only after the need, context, evidence, and success conditions have been understood.

Problem identification and requirements engineering provide the bridge between an observed need and an implementable engineering project. Problem identification establishes the gap between the present condition and a desirable condition. Requirements engineering translates that gap into statements that are sufficiently precise to guide design, verification, procurement, safety assessment, and acceptance.

In electrical engineering, requirements may concern voltage, current, power, energy, bandwidth, accuracy, response time, reliability, thermal behaviour, electromagnetic compatibility, maintainability, cost, or regulatory compliance. They may also describe interfaces with people, buildings, communication networks, utility systems, and other equipment. Requirements engineering is therefore both a technical and a socio-organisational activity.

Learning objectives

By the end of this chapter, a student should be able to:

1. Distinguish a symptom, need, problem statement, solution, and requirement.
2. Analyse stakeholders, operating context, assumptions, risks, and system boundaries.
3. Formulate answerable research questions and testable hypotheses.
4. Develop functional, technical, performance, interface, safety, regulatory, and verification requirements.
5. Prioritise and negotiate requirements using transparent criteria.
6. Write a requirements specification and construct a traceability structure.
7. Recognise ethical, environmental, cybersecurity, and governance responsibilities.

From observation to an engineering problem

An observation is a fact or perception: a feeder experiences frequent interruptions, a laboratory instrument gives unstable readings, or a rural clinic cannot depend on refrigeration. An engineering need is the desired capability or improvement. A problem is the evidence-based gap between current performance and required performance. A solution is a proposed means of addressing the problem. These must not be confused.

For example, “build an IoT monitoring system” is a solution idea, not a problem statement. A better formulation is: “Maintenance personnel cannot identify abnormal temperature rise in distribution-board connections early enough to prevent unplanned interruption.” The proposed IoT system may or may not be the best response.

A useful problem statement identifies:

• the affected system or population;
• the undesirable condition and its evidence;
• the operational, safety, economic, or social consequence;
• the context and boundary of the investigation; and
• the improvement that would count as success.

A problem statement should be specific without prematurely prescribing a design. It should also be feasible within the project’s time, skills, equipment, budget, and access to data.

Need, objective, research question, and requirement

These concepts operate at different levels:

The distinction prevents a common error: treating a proposed component or technology as the requirement. “The system shall use an Arduino” is usually a design decision. “The controller shall sample each sensor at least once per second” is a requirement if that rate is justified by the required detection performance.

Authenticity and evidence of need

An authentic electrical engineering need is supported by evidence rather than enthusiasm alone. Evidence may include maintenance records, energy bills, outage logs, measured waveforms, interviews, site observations, incident reports, standards, published research, or a documented user workflow. A student should triangulate evidence: a claim made in an interview becomes more credible when supported by measurements or records.

A practical evidence record includes the source, date, measurement method, uncertainty or limitation, and relevance. For an electrical measurement, record instrument identification, calibration status, range, sampling rate, connection arrangement, and safety precautions. Measurements on live systems require competent supervision and an approved risk assessment.

The scale of a problem must also be distinguished from its severity. A rare event may have catastrophic consequences; a frequent inconvenience may have modest consequences but offer a valuable opportunity for improvement. A simple risk-screening model is:

where R is a risk score, L is a likelihood rating, and I is an impact rating. In a qualitative matrix, both ratings may be ordinal scores such as 1 to 5; the product is a prioritisation aid, not a probability of loss. If numerical probabilities and monetary consequences are available, an expected-loss model may be more appropriate:

where p is the probability of an event and C is its consequence cost. The assumptions must be stated because estimates may be uncertain, correlated, or incomplete.

Stakeholder and context analysis

A stakeholder is any person, group, organisation, or system that can affect the project, is affected by it, or has authority over it. Typical stakeholders include end users, operators, maintainers, customers, sponsors, manufacturers, utilities, safety officers, regulators, nearby communities, and future owners. A stakeholder is not necessarily the person who commissions the project. The person who pays, uses, maintains, approves, and is exposed to risk may be different.

Stakeholder analysis

Stakeholder analysis should answer four questions:

1. What does the stakeholder need or fear?
2. What authority, knowledge, data, or resources does the stakeholder possess?
3. How could the project affect the stakeholder?
4. How and when should the stakeholder participate?

A power–interest matrix is a useful starting point. High-power, high-interest stakeholders require close engagement; high-power, low-interest stakeholders should be kept satisfied; low-power, high-interest stakeholders should be kept informed and consulted; and low-power, low-interest groups should still be monitored where ethical or safety concerns exist. The matrix is not a substitute for judgement: a community with little formal power may nevertheless bear substantial environmental risk.

Use interviews for experience and tacit knowledge, observation for actual practice, document analysis for formal constraints, and workshops for resolving conflicting needs. Ask neutral questions. “What happens when the alarm activates?” is more informative than “Would you like an app?” Record disagreements rather than concealing them.

Context and system boundary

Context analysis examines the environment in which the proposed system operates. Relevant dimensions include:

• physical: temperature, humidity, dust, vibration, enclosure, altitude, access, and hazardous locations;
• electrical: supply voltage, frequency, fault level, earthing, harmonics, transients, load variation, and isolation;
• operational: duty cycle, user competence, maintenance intervals, start-up and shutdown procedures;
• information: sensor data, communication links, timestamps, storage, privacy, and cybersecurity;
• organisational: ownership, approval, procurement, training, liability, and budget;
• legal and regulatory: electrical codes, occupational safety, radio rules, data protection, and environmental obligations.

Define what is inside and outside the system boundary. For a battery-monitoring project, cells, sensors, controller, communication link, dashboard, operator, charger, and disposal process may all be relevant. If the charger is excluded, the specification must state the interface assumptions and hazards that remain outside the project.

A context diagram should show external actors and systems, inputs, outputs, energy flows, information flows, and hazardous interactions. Even a text description can expose missing interfaces: who supplies power, who receives an alarm, what happens if communication fails, and who is authorised to reset the equipment?

Formulating research questions and hypotheses

A major project may be primarily design-oriented, experimental, analytical, or mixed. Its research question must match its evidence and resources. A good question is focused, answerable, significant, and ethically acceptable. It identifies the subject, intervention or comparison, outcome, and context where relevant.

Examples include:

• How does measurement sampling interval affect the detection latency of a motor bearing-temperature anomaly?
• Can a low-cost current sensor estimate single-phase load energy within a specified error under non-sinusoidal loads?
• What control strategy reduces battery peak current while maintaining the required motor acceleration?

A hypothesis is a provisional, testable prediction. For example: “Under the defined load profile, adaptive sampling reduces average communication energy by at least 20% without increasing missed-event rate above 1%.” This statement identifies an intervention, comparison or baseline, measurable outcomes, and a threshold.

A null hypothesis may be written as H₀: μ_A − μ_B = 0, where μ_A and μ_B are population mean outcomes for two conditions. An alternative hypothesis may be H₁: μ_A − μ_B ≠ 0. Such statistical notation is appropriate only when repeated observations, a defined sampling plan, and suitable assumptions exist. A small engineering prototype study may instead use confidence intervals, error bounds, plots, and repeatability analysis rather than claiming broad statistical generalisation.

The independent variable is deliberately changed or categorised; the dependent variable is measured as an outcome; controlled variables are held constant; and confounders affect the outcome but are not properly controlled. State the baseline clearly. “Improved accuracy” has no meaning without a reference instrument, operating range, error metric, and environmental conditions.

For a measured value x and reference value x_ref, absolute error is:

and percentage error, when x_ref ≠ 0, is:

The sign indicates bias direction; the magnitude indicates size. These equations assume comparable quantities and a meaningful reference value. For quantities that may cross zero, a full-scale or absolute-error specification may be more appropriate than percentage-of-reading error.

Requirements engineering

Requirements engineering is the systematic process of eliciting, analysing, documenting, validating, prioritising, managing, and verifying requirements. It is iterative: stakeholder understanding changes when prototypes, measurements, hazards, and cost constraints reveal new information.

Categories of requirements

Functional requirements describe what the system shall do: measure current, disconnect a load, log an event, issue an alarm, or regulate a voltage.

Performance requirements quantify behaviour: accuracy, response time, throughput, resolution, availability, efficiency, overshoot, or operating range.

Technical requirements constrain implementation or physical characteristics: supply range, insulation, sensor interface, processor capacity, enclosure rating, thermal limit, or communication protocol. Technical constraints should be justified because unnecessary constraints can prevent better solutions.

Interface requirements define exchanges with users, electrical equipment, mechanical structures, software, and networks. Include signal levels, connector conventions, timing, protocol, polarity, isolation, and failure behaviour.

Safety requirements address protection against shock, fire, overcurrent, overheating, unintended motion, stored energy, and hazardous failure. Safety requirements should follow applicable legislation, institutional procedures, and recognised standards rather than informal assumptions.

Regulatory and compliance requirements arise from applicable electrical installation rules, product safety standards, electromagnetic compatibility requirements, radio regulations, environmental rules, and data-protection law. The exact standards depend on jurisdiction and product category; students must confirm the current editions with the supervisor and competent authority.

Reliability, maintainability, and sustainability requirements address service life, diagnostic coverage, repairability, spare parts, energy use, materials, disposal, and lifecycle impact.

Characteristics of a good requirement

A good requirement is necessary, unambiguous, singular, feasible, consistent, verifiable, traceable, and prioritised. Prefer “The logger shall store at least 30 days of one-minute RMS-current records” to “The logger shall provide adequate long-term storage.” The first statement identifies a measurable capacity and sampling condition.

Use “shall” for a mandatory requirement, “should” for a preferred but negotiable characteristic, and “may” for an optional capability. Avoid vague terms such as user-friendly, robust, fast, intelligent, safe, and low cost unless they are operationally defined.

A useful requirement record contains an identifier, statement, rationale, source, priority, assumptions, verification method, owner, revision, and links to related requirements. For example:

The word “shall” does not itself make a requirement valid. The rationale and verification method expose whether the requirement is necessary and testable.

Deriving and prioritising requirements

Requirements are derived from stakeholder needs, hazards, operating scenarios, standards, physical laws, and project objectives. A scenario such as “operator receives a warning during an overheating event” can yield functional, timing, interface, usability, power, and safety requirements.

Prioritisation should be explicit. The MoSCoW scheme classifies requirements as Must, Should, Could, or Won’t for the current release. Alternatively, assign weighted scores. If a requirement’s value score is v and implementation effort is e, a simple prioritisation index is:

where both values must be defined on stated scales and e > 0. This index is not an objective economic law; it is a decision aid. Safety and legal requirements must not be demoted merely because their implementation effort is high.

Conflicts are normal. A stakeholder may request continuous wireless transmission, while a battery constraint favours infrequent communication. Resolve the conflict by identifying the underlying need, quantifying alternatives, documenting assumptions, and obtaining approval for trade-offs. Do not silently relax a requirement.

Verification and validation

Verification asks, “Did we build the system according to its specified requirements?” Validation asks, “Did we specify and build the right system for the real need?” A device can pass voltage, timing, and accuracy tests yet fail validation if users cannot interpret its alarm or if it does not operate in the installation environment.

Common verification methods are:

• Inspection: examination of drawings, labels, code, materials, or workmanship.
• Analysis: calculation, simulation, modelling, or review of test data.
• Demonstration: showing a capability under defined conditions.
• Test: controlled measurement using specified instruments and procedures.

Each quantitative requirement needs a test condition, equipment, method, tolerance, acceptance criterion, and record format. Consider measurement uncertainty. If an acceptance limit is 70 °C and the instrument uncertainty is ±2 °C, a reading of 69.5 °C does not automatically prove compliance with a strict 70 °C limit. The decision rule should be agreed before testing.

Traceability and change control

A traceability matrix links need → objective → requirement → design element → test → result. It prevents orphan requirements with no test and tests with no requirement. It also supports change impact analysis. If a sensor’s range changes, the team can identify affected requirements, circuit elements, software functions, safety analyses, and verification procedures.

Control changes through a revision history and a change request stating the reason, impact, cost, schedule, risk, and approval. Version control applies not only to software but also to schematics, bills of materials, calculations, test procedures, datasets, and requirement documents.

Worked example: monitoring overheating in a distribution panel

This illustrative case concerns a small commercial building in which maintenance staff report intermittent trips and discoloured conductors in a low-voltage distribution panel. The project team does not assume that monitoring is the final solution.

Background and problem. Maintenance records show six unexplained interruptions in twelve months. A visual inspection identifies heat damage near one termination, but no continuous temperature data exist. The need is early detection of abnormal thermal behaviour without exposing staff to unnecessary live work.

Stakeholder and context analysis. The facilities manager needs fewer interruptions and actionable alarms. Electricians need safe installation and accessible maintenance data. Building occupants need continuity of service. The safety officer requires a risk assessment and isolation procedure. The project supervisor controls the academic scope. The panel operates indoors, but temperature, dust, electrical noise, enclosure access, and communication loss must be considered. The prototype boundary includes sensors, signal conditioning, controller, local alarm, data logging, and a non-invasive test setup; modification of the live panel is excluded until separately authorised.

Research question. “Within the defined laboratory and simulated panel conditions, can a low-voltage isolated temperature-monitoring prototype identify a sustained abnormal temperature rise within 10 s while maintaining a false-alarm rate below the agreed limit?” The team defines the abnormal event, reference thermometer, sampling interval, test temperatures, number of repeats, and false-alarm calculation before testing.

Requirements. Examples include:

• The system shall measure each monitored point over 0–100 °C.
• The displayed temperature shall be within ±2 °C of the reference under stated laboratory conditions.
• The system shall sample each channel at least once per second.
• It shall generate a local alarm within 10 s of a temperature exceeding 70 °C continuously for 5 s.
• It shall record timestamp, channel, measured value, and alarm state.
• Loss of a sensor signal shall be indicated as a fault and shall not be reported as a safe temperature.
• The prototype shall be powered from an electrically safe isolated supply during evaluation.
• Testing on operational distribution equipment shall require written authorisation, competent supervision, and an approved procedure.

Approach. The team develops a block diagram, hazard analysis, sensor calibration plan, software state diagram, and verification matrix. Calibration uses several known reference points rather than a single point. Alarm tests include sustained threshold crossings, short excursions, sensor disconnection, power interruption, and communication loss.

Outcome. Suppose the prototype meets the ±2 °C accuracy criterion at the tested points and detects all sustained events within the timing limit, but fails to distinguish a disconnected sensor from a low temperature. The correct engineering conclusion is partial compliance, not success. The fault-handling requirement must be redesigned and retested. The project may demonstrate technical feasibility without claiming that it prevents every panel failure; a thermal warning is not a substitute for correct installation, inspection, protection, and maintenance.

Learning points. The case shows why authentic evidence precedes technology selection, why safety boundaries must be explicit, why failure modes belong in requirements, and why verification results should be reported honestly.

Ethics, safety, regulation, and sustainability

Electrical engineering decisions can cause shock, fire, service interruption, privacy harm, or environmental damage. A student must not treat academic status as permission to work on energised systems. Follow institutional electrical-safety rules, lockout and isolation procedures, personal protective equipment requirements, competent supervision, and laboratory approvals.

Ethical reporting requires preserving inconvenient results, documenting exclusions, and avoiding unsupported claims. If data are collected from users, obtain informed consent where required, minimise personal data, restrict access, and explain retention and disposal. A camera, location record, or network identifier may create privacy obligations even when the project is primarily electrical.

Cybersecurity is relevant whenever equipment is networked. Define authentication, update responsibility, logging, least privilege, safe failure behaviour, and protection against unauthorised control. “Connected” is not automatically “intelligent” or secure. Artificial intelligence may assist anomaly detection or requirements analysis, but training data, false alarms, explainability, cybersecurity, bias, and human responsibility must be addressed. AI-generated requirements or code require engineering review and verification; they are not evidence of compliance.

Sustainability should be considered across the lifecycle: embodied materials, standby power, repairability, battery replacement, hazardous substances, recycling, and end-of-life data deletion. A technically efficient device can have poor lifecycle performance if it is disposable or difficult to repair.

Common challenges and best practices

Common challenges include solution-first thinking, requirements written at an unsuitable level of detail, dependence on one stakeholder, hidden assumptions, unmeasured success criteria, scope expansion, contradictory requirements, and unsafe access to field equipment. Teams also underestimate the time needed for calibration, test fixtures, approvals, procurement, and iteration.

Best practice is to:

1. Start with evidence and a neutral problem statement.
2. Identify all affected and authoritative stakeholders.
3. Record context, assumptions, exclusions, and hazards.
4. Convert needs into measurable, testable requirements.
5. Separate mandatory constraints from design preferences.
6. Assign priorities, owners, sources, and verification methods.
7. Prototype uncertain interfaces early.
8. Maintain traceability and controlled revisions.
9. Validate with representative users and operating conditions.
10. Report limitations and residual risks explicitly.

Chapter Summary

Problem identification defines an evidence-based gap without prematurely selecting a technology. A sound project connects an authentic need to objectives, research questions, requirements, design decisions, and verification evidence. Stakeholder analysis reveals differing needs, authority, risks, and responsibilities, while context analysis defines physical, electrical, organisational, informational, legal, and environmental conditions.

Requirements engineering converts needs into functional, performance, technical, interface, safety, regulatory, reliability, maintainability, and sustainability requirements. Good requirements are necessary, unambiguous, feasible, measurable, verifiable, prioritised, and traceable. Research questions and hypotheses must match the available evidence and method. Verification demonstrates conformity to requirements; validation demonstrates suitability for the real need. Ethical conduct, safety approval, cybersecurity, privacy, sustainability, and honest reporting are integral engineering responsibilities rather than final additions.

Key Terms

Problem statement: Evidence-based description of a gap between current and desired conditions.

Engineering need: Desired capability or improvement that motivates a project.

Stakeholder: Person, organisation, or system affected by or able to influence the project.

System boundary: Deliberate definition of what is included in the system and what is external.

Context analysis: Examination of the physical, electrical, operational, organisational, and regulatory environment.

Functional requirement: Statement of what a system shall do.

Performance requirement: Quantified statement of how well or how quickly a system shall operate.

Technical requirement: Constraint on characteristics, materials, interfaces, or implementation.

Interface requirement: Definition of an exchange between systems, equipment, users, or software.

Safety requirement: Condition intended to prevent or limit harm.

Regulatory requirement: Obligation arising from law, code, or applicable standard.

Verification: Demonstration that specified requirements have been met.

Validation: Demonstration that the resulting system addresses the real need.

Traceability: Ability to link needs, requirements, designs, tests, and results.

Hypothesis: Testable prediction about a relationship or outcome.

Independent variable: Variable deliberately changed or categorised in an investigation.

Dependent variable: Measured outcome of an investigation.

Measurement uncertainty: Estimated range associated with a measured result.

Change control: Formal management of revisions and their consequences.

Requirements baseline: Approved version of requirements used to control design and testing.

Review Questions

5 Short Answer Questions

1. Distinguish an engineering need from a proposed solution.
2. Name four categories of stakeholders in an electrical engineering project.
3. What is the difference between verification and validation?
4. State four characteristics of a good requirement.
5. Why should a system boundary be defined before detailed design?

5 Long Answer Questions

1. Explain how interviews, observations, records, and measurements can be combined to establish an authentic engineering need.
2. Describe a complete stakeholder and context analysis for a battery energy-storage monitoring project.
3. Explain the process of converting a stakeholder need into functional, performance, safety, and verification requirements.
4. Discuss the role of traceability and change control in a major electrical engineering project.
5. Explain how safety, regulation, privacy, cybersecurity, and sustainability influence requirements engineering.

3 Analytical / Application Questions

1. A proposed smart meter is described as “accurate, affordable, secure, and user-friendly.” Rewrite this description as at least six measurable requirements and give a verification method for each.
2. A battery-powered sensor must detect an event lasting 3 s, but communication consumes most of the energy. Formulate a research question, identify variables and confounders, and propose a verification plan.
3. A prototype passes all laboratory tests but users ignore its alarms in the intended workplace. Analyse whether this is primarily a verification failure, a validation failure, or both, and recommend corrective actions.

Multiple Choice Questions with Answers

Question 1

Which statement is a problem statement rather than a proposed solution?

A. Build an IoT monitoring system for a motor

B. Install a wireless temperature sensor on every panel

C. Maintenance staff cannot identify abnormal panel heating early enough to prevent interruptions

D. Use a microcontroller with a cloud dashboard

Correct Answer: C. Maintenance staff cannot identify abnormal panel heating early enough to prevent interruptions

Question 2

Which requirement is most directly a performance requirement?

A. The system shall use a particular microcontroller

B. The system shall generate an alarm within 10 s of a sustained threshold condition

C. The enclosure shall be painted blue

D. The prototype shall include a development board

Correct Answer: B. The system shall generate an alarm within 10 s of a sustained threshold condition

Question 3

What does validation primarily ask?

A. Was the circuit soldered correctly?

B. Did the design meet its bill of materials?

C. Did the system address the real stakeholder need?

D. Was the software compiled without errors?

Correct Answer: C. Did the system address the real stakeholder need?

Question 4

A measured value is 49 V and the reference is 50 V. What is the percentage error using the reference value?

A. −2%

B. 1%

C. 2%

D. 50%

Correct Answer: A. −2%

Question 5

Which is an appropriate verification method for checking whether a connector has the specified pin arrangement?

A. Inspection

B. Stakeholder brainstorming

C. Market forecasting

D. Random sampling without a criterion

Correct Answer: A. Inspection

Question 6

Why is “the system shall be user-friendly” generally a weak requirement?

A. It is too technical

B. It cannot be operationally measured without further definition

C. It always violates electrical regulations

D. It specifies too many interfaces

Correct Answer: B. It cannot be operationally measured without further definition

Question 7

In a requirements traceability structure, which link is most appropriate?

A. Need to requirement to test result

B. Colour to budget to advertisement

C. Component brand to supervisor preference only

D. User name to circuit voltage only

Correct Answer: A. Need to requirement to test result

Question 8

Which statement about a safety requirement is correct?

A. It may be ignored if implementation is expensive

B. It should be replaced by a preferred component choice

C. It addresses prevention or limitation of harm under defined conditions

D. It applies only after the prototype is completed

Correct Answer: C. It addresses prevention or limitation of harm under defined conditions

Question 9

If a project team changes the sensor range, what should change control examine?

A. Only the title page

B. Affected requirements, designs, risks, tests, cost, and schedule

C. Only the colour of the enclosure

D. Nothing if the prototype still powers on

Correct Answer: B. Affected requirements, designs, risks, tests, cost, and schedule

Question 10

Which statement best describes a hypothesis?

A. An untestable expression of enthusiasm

B. A mandatory electrical code

C. A testable prediction about an outcome or relationship

D. A list of purchased components

Correct Answer: C. A testable prediction about an outcome or relationship