Requirements Engineering for Battery Systems

Managing requirements can make or break a project. This article explains the role of requirements engineering (RE) in development projects, using battery system development as an example. Executed effectively, RE contributes significantly to project success: it reduces rework, improves project estimates and ensures that the developed system meets stakeholder expectations and needs.

RE is a critical discipline in software and systems development. Team and project success depend on how well the project requirements are managed. This is an iterative process that deals with evolving requirements and includes traceability, versioning, change control and status tracking.

Why requirements engineering matters

In modern, complex system development, the importance of RE can hardly be overstated, mainly for the following reasons [1]:

1. Aligning solutions with business goals: RE ensures that the system supports the strategic goals of the organization. By translating stakeholder needs into clear, actionable requirements, it ensures that the solution provides real value.

2. Reducing development costs: RE identifies issues and ambiguities early, which significantly reduces later rework. Fixing errors after deployment can be exponentially more expensive than fixing them during the requirements phase.

3. Improving user satisfaction: involving stakeholders in requirements elicitation and validation ensures that the final product meets user expectations, which increases satisfaction and acceptance.

4. Providing a basis for planning and management: requirements are the basis for estimating resources, scheduling and risk management, and serve as benchmarks for progress and success.

5. Improving system quality: clear, testable requirements lay the foundation for thorough verification and validation, which improves the reliability, robustness and performance of the system.

6. Facilitating communication: a well-structured RE process improves communication between stakeholders, developers, testers and other project members and creates a shared understanding of what the system should do.

7. Supporting maintenance and evolution: requirements artifacts document the rationale behind design decisions, which is crucial when the system is modified or extended later.

Four questions for every project

From project start to completion, four questions should be asked continuously:

1. Who are the stakeholders?

2. What are their needs?

3. How essential is each requirement?

4. How can conflicts that arise during the project be resolved?

What makes a well-formed requirement

A well-formed requirement:

• shall be met or possessed by a system to solve a problem, achieve an objective or address a stakeholder concern,

• is qualified by measurable conditions,

• is bounded by constraints,

• defines the performance or capability of the system when used by a specific stakeholder, not the capability of the user, operator or other stakeholder, and

• can be verified, i.e. its realization in the system can be demonstrated.

The requirements management process

Requirements management can be divided into the following main steps [2–3]:

Fig. 1: Main steps of the requirements management process

The main work products of requirements specification are [1]:

1. Stakeholder requirements specification (StRS)

2. System requirements specification

3. Discipline-specific requirements specification (e.g. software)

4. Business requirements specification (BRS)

5. Glossary

Requirements analysis

Requirements analysis is a critical stage of RE in which requirements are determined, studied and refined. It transforms the collected user needs and constraints into clear, unambiguous and detailed requirements, and ensures that the system under development matches user needs and expectations.

In advanced systems engineering, requirements analysis is not a one-time activity. As understanding of the system deepens and the system evolves, requirements are continuously analyzed, refined and updated. This iterative approach keeps them relevant and accurate.

Types of requirements

Each type of requirement defines what the system should do, how it should do it, how it interacts with its environment and which constraints apply. Together they give a complete picture of what the system must be to meet stakeholder needs. Common types are [2–3]:

Functional requirements

Functional requirements describe the functions or tasks that a system or system component must perform [1]. They describe the interactions between the system and its environment, independent of implementation, and may involve calculations, data processing and other specific functionality. Performance is a quality of a function.

• Example 1: When signal x is received, the system shall close the contactors within x seconds.

• Example 2: The system shall measure the individual cell voltages with a sampling rate of 1,000 Hz.

Non-functional requirements

Non-functional requirements define criteria for judging the operation of a system rather than specific behaviour, such as performance, security, usability and reliability. They can be further divided into:

• Quality requirements: characteristics or qualities the system must have that are not covered by functional requirements [1], such as performance, availability, security, usability and reliability. Example: The system shall provide 50 kW continuous electrical power.

• Regulatory requirements: requirements resulting from applicable laws, regulations, standards or policies.

• Constraints: requirements that limit the solution space beyond what is necessary to meet the functional and quality requirements [2], for example due to budget, technology, time or existing systems. Example 1: The maximum system voltage shall not exceed 0.4 kV. Example 2: The system enclosure shall meet the requirements of protection class IP54.

• Process requirements: requirements on how the system is developed and maintained, such as development methodology, coding standards, testing, configuration management and quality assurance. They can also describe business processes that the system must support.

Requirements verification and validation

Verification and validation are two crucial processes in the requirements management life cycle. They ensure that the system meets the stakeholder requirements and fulfils its intended purpose. Carried out at several points during development, they allow errors and misunderstandings to be detected and corrected early, saving time and resources.

Validation techniques can be grouped into three classes that differ in formality and effort [1]:

1. Review techniques: walkthroughs, inspections

2. Exploratory techniques: prototyping, minimum viable product (MVP)

3. Sample development

Summary

Structured requirements engineering is one of the strongest levers for the success of battery system projects. FA Battery Engineering supports development teams in e-mobility and stationary energy storage with advanced systems engineering and RE methods, drawing on more than a decade of experience in battery system engineering.

Need structured requirements for your battery project? Explore our Systems Engineering services or talk to an expert.

References

[1] ISO/IEC/IEEE 29148, Systems and software engineering — Life cycle processes — Requirements engineering, second edition, 2018-11.

[2] IREB, CPRE – Certified Professional for Requirements Engineering, Foundation Level, Handbook.

[3] IREB, CPRE – Certified Professional for Requirements Engineering, Foundation Level, Syllabus.