DE · EN

Call us

build 6ddc7a35 | content blog-content@417154f · 338 posts | profiles 32 · corpus 315 | ● 0 skipped | built 2026-10-21 12:35 UTC format run

$ soultec get service/requirements-engineering -o yaml$ soultec get service/requirements-engineering -o json$ soultec get service/requirements-engineering -o toml$ soultec get service/requirements-engineering -o xml$ python3 requirements-engineering.pyPS> ./requirements-engineering.ps1$ go run requirements-engineering.go$ node requirements-engineering.js

apiVersion: soultec.ch/v1kind: Servicemetadata: name: requirements-engineering locale: en labels: group: consulting capability/strategy: 2.87 capability/architecture: 2.51 annotations: source: src/content/services/en/requirements-engineering.md route: /en/services/requirements-engineering/ schema: /nerd/schema/services.json markdown: /en/services/requirements-engineering.mdspec: title: Requirements Engineering group: consulting audience: [enterprise, provider] order: 6 tags: [strategy, architecture] summary: >- Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left. photoNeed: >- A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table stub: false draft: false sections: - heading:

What it is for

body: | So that the technology fits the business processes rather than the other way round. Requirements engineering is the tool for reconciling technology, processes and what people actually need, before a decision is made. Without that step you procure what was convincing in the demo, and afterwards adapt whatever can be adapted. - heading:

How it runs

body: | Systematically, in workshops. We help define and capture every relevant requirement and figure: functional and non-functional, and in particular the numbers that later decide the architecture. That includes an analysis of today's system usage and an outlook over the next five years as the measure for scaling. Requirements shared by several services are captured once. The result also carries a budget request. - heading:

What the workshops cover

body: | Not everything at once, but these topics come up in every project: - Availability requirements, meaning RPO and RTO - Capacity and performance, today and over the planned horizon - System and storage performance - Security - Data centre locations - Data protection - Application realities and legacy systems The last one is the one most often missing and the most expensive to add late. An application that needs a particular database version has a say in the architecture, whatever else was planned. - heading:

Why it comes first

body: | Because other services build on it. A data management design without known access patterns and retention periods is guesswork, and a disaster recovery design without RPO and RTO is not a design. Requirements engineering is therefore rarely the project somebody rings about, and often the one the project should have started with.status: corpus: 315 solutions: - {ref: solutions/hpe/hpe-server, score: 0.41} - {ref: solutions/hpe/hpe-server/hpe-synergy, score: 0.41} - {ref: solutions/ibm, score: 0.41} - {ref: solutions/ibm/ibm-power10, score: 0.41} alsoLike: - {ref: services/enterprise-architecture, score: 1.00} - {ref: services/it-strategie, score: 1.00} - {ref: posts/vmware-license-changes-2025, score: 0.52} experts: - {ref: experts/aldo-gwerder, score: 0.36} - {ref: experts/steven-rodenburg, score: 0.34} - {ref: experts/fabian-faessler, score: 0.33} search: /en/search.json

{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "requirements-engineering", "locale": "en", "labels": { "group": "consulting", "capability/strategy": 2.87, "capability/architecture": 2.51 }, "annotations": { "source": "src/content/services/en/requirements-engineering.md", "route": "/en/services/requirements-engineering/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/requirements-engineering.md" } }, "spec": { "title": "Requirements Engineering", "group": "consulting", "audience": [ "enterprise", "provider" ], "order": 6, "tags": [ "strategy", "architecture" ], "summary": "Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left.", "photoNeed": "A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table", "stub": false, "draft": false, "sections": [ { "heading": "

What it is for

", "body": "So that the technology fits the business processes rather than the other way round.\nRequirements engineering is the tool for reconciling technology, processes and what people\nactually need, before a decision is made.\n\nWithout that step you procure what was convincing in the demo, and afterwards adapt whatever\ncan be adapted." }, { "heading": "

How it runs

", "body": "Systematically, in workshops. We help define and capture every relevant requirement and\nfigure: functional and non-functional, and in particular the numbers that later decide the\narchitecture.\n\nThat includes an analysis of today's system usage and an outlook over the next five years as\nthe measure for scaling. Requirements shared by several services are captured once. The\nresult also carries a budget request." }, { "heading": "

What the workshops cover

", "body": "Not everything at once, but these topics come up in every project:\n\n- Availability requirements, meaning RPO and RTO\n- Capacity and performance, today and over the planned horizon\n- System and storage performance\n- Security\n- Data centre locations\n- Data protection\n- Application realities and legacy systems\n\nThe last one is the one most often missing and the most expensive to add late. An\napplication that needs a particular database version has a say in the architecture,\nwhatever else was planned." }, { "heading": "

Why it comes first

", "body": "Because other services build on it. A data management design without known access patterns\nand retention periods is guesswork, and a disaster recovery design without RPO and RTO is\nnot a design.\n\nRequirements engineering is therefore rarely the project somebody rings about, and often the\none the project should have started with." } ] }, "status": { "corpus": 315, "solutions": [ { "ref": "solutions/hpe/hpe-server", "score": "0.41" }, { "ref": "solutions/hpe/hpe-server/hpe-synergy", "score": "0.41" }, { "ref": "solutions/ibm", "score": "0.41" }, { "ref": "solutions/ibm/ibm-power10", "score": "0.41" } ], "alsoLike": [ { "ref": "services/enterprise-architecture", "score": "1.00" }, { "ref": "services/it-strategie", "score": "1.00" }, { "ref": "posts/vmware-license-changes-2025", "score": "0.52" } ], "experts": [ { "ref": "experts/aldo-gwerder", "score": "0.36" }, { "ref": "experts/steven-rodenburg", "score": "0.34" }, { "ref": "experts/fabian-faessler", "score": "0.33" } ], "search": "/en/search.json" }}

apiVersion = "soultec.ch/v1"kind = "Service"[metadata]name = "requirements-engineering"locale = "en"[metadata.labels]group = "consulting""capability/strategy" = 2.87"capability/architecture" = 2.51[metadata.annotations]source = "src/content/services/en/requirements-engineering.md"route = "/en/services/requirements-engineering/"schema = "/nerd/schema/services.json"markdown = "/en/services/requirements-engineering.md"[spec]title = "Requirements Engineering"group = "consulting"audience = ["enterprise", "provider"]order = 6tags = ["strategy", "architecture"]summary = "Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left."photoNeed = "A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table"stub = falsedraft = false[[spec.sections]]heading = "

What it is for

"body = '''So that the technology fits the business processes rather than the other way round.Requirements engineering is the tool for reconciling technology, processes and what peopleactually need, before a decision is made.Without that step you procure what was convincing in the demo, and afterwards adapt whatevercan be adapted.'''[[spec.sections]]heading = "

How it runs

"body = '''Systematically, in workshops. We help define and capture every relevant requirement andfigure: functional and non-functional, and in particular the numbers that later decide thearchitecture.That includes an analysis of today's system usage and an outlook over the next five years asthe measure for scaling. Requirements shared by several services are captured once. Theresult also carries a budget request.'''[[spec.sections]]heading = "

What the workshops cover

"body = '''Not everything at once, but these topics come up in every project:- Availability requirements, meaning RPO and RTO- Capacity and performance, today and over the planned horizon- System and storage performance- Security- Data centre locations- Data protection- Application realities and legacy systemsThe last one is the one most often missing and the most expensive to add late. Anapplication that needs a particular database version has a say in the architecture,whatever else was planned.'''[[spec.sections]]heading = "

Why it comes first

"body = '''Because other services build on it. A data management design without known access patternsand retention periods is guesswork, and a disaster recovery design without RPO and RTO isnot a design.Requirements engineering is therefore rarely the project somebody rings about, and often theone the project should have started with.'''[status]corpus = 315search = "/en/search.json"[[status.solutions]]ref = "solutions/hpe/hpe-server"score = "0.41"[[status.solutions]]ref = "solutions/hpe/hpe-server/hpe-synergy"score = "0.41"[[status.solutions]]ref = "solutions/ibm"score = "0.41"[[status.solutions]]ref = "solutions/ibm/ibm-power10"score = "0.41"[[status.alsoLike]]ref = "services/enterprise-architecture"score = "1.00"[[status.alsoLike]]ref = "services/it-strategie"score = "1.00"[[status.alsoLike]]ref = "posts/vmware-license-changes-2025"score = "0.52"[[status.experts]]ref = "experts/aldo-gwerder"score = "0.36"[[status.experts]]ref = "experts/steven-rodenburg"score = "0.34"[[status.experts]]ref = "experts/fabian-faessler"score = "0.33"

<?xml version="1.0" encoding="UTF-8"?><manifest kind="Service"> <apiVersion>soultec.ch/v1</apiVersion> <metadata> <name>requirements-engineering</name> <locale>en</locale> <labels> <group>consulting</group> <entry key="capability/strategy">2.87</entry> <entry key="capability/architecture">2.51</entry> </labels> <annotations> <source>src/content/services/en/requirements-engineering.md</source> <route>/en/services/requirements-engineering/</route> <schema>/nerd/schema/services.json</schema> <markdown>/en/services/requirements-engineering.md</markdown> </annotations> </metadata> <spec> <title>Requirements Engineering</title> <group>consulting</group> <audience> <item>enterprise</item> <item>provider</item> </audience> <order>6</order> <tags> <item>strategy</item> <item>architecture</item> </tags> <summary>Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left.</summary> <photoNeed>A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table</photoNeed> <stub>false</stub> <draft>false</draft> <sections> <section> <heading>

What it is for

</heading> <body>So that the technology fits the business processes rather than the other way round.Requirements engineering is the tool for reconciling technology, processes and what peopleactually need, before a decision is made.Without that step you procure what was convincing in the demo, and afterwards adapt whatevercan be adapted. </body> </section> <section> <heading>

How it runs

</heading> <body>Systematically, in workshops. We help define and capture every relevant requirement andfigure: functional and non-functional, and in particular the numbers that later decide thearchitecture.That includes an analysis of today's system usage and an outlook over the next five years asthe measure for scaling. Requirements shared by several services are captured once. Theresult also carries a budget request. </body> </section> <section> <heading>

What the workshops cover

</heading> <body>Not everything at once, but these topics come up in every project:- Availability requirements, meaning RPO and RTO- Capacity and performance, today and over the planned horizon- System and storage performance- Security- Data centre locations- Data protection- Application realities and legacy systemsThe last one is the one most often missing and the most expensive to add late. Anapplication that needs a particular database version has a say in the architecture,whatever else was planned. </body> </section> <section> <heading>

Why it comes first

</heading> <body>Because other services build on it. A data management design without known access patternsand retention periods is guesswork, and a disaster recovery design without RPO and RTO isnot a design.Requirements engineering is therefore rarely the project somebody rings about, and often theone the project should have started with. </body> </section> </sections> </spec> <status> <corpus>315</corpus> <solutions> <item> <ref>solutions/hpe/hpe-server</ref> <score>0.41</score> </item> <item> <ref>solutions/hpe/hpe-server/hpe-synergy</ref> <score>0.41</score> </item> <item> <ref>solutions/ibm</ref> <score>0.41</score> </item> <item> <ref>solutions/ibm/ibm-power10</ref> <score>0.41</score> </item> </solutions> <alsoLike> <item> <ref>services/enterprise-architecture</ref> <score>1.00</score> </item> <item> <ref>services/it-strategie</ref> <score>1.00</score> </item> <item> <ref>posts/vmware-license-changes-2025</ref> <score>0.52</score> </item> </alsoLike> <experts> <item> <ref>experts/aldo-gwerder</ref> <score>0.36</score> </item> <item> <ref>experts/steven-rodenburg</ref> <score>0.34</score> </item> <item> <ref>experts/fabian-faessler</ref> <score>0.33</score> </item> </experts> <search>/en/search.json</search> </status></manifest>

# Code generated by the soultec.ch build. DO NOT EDIT.import jsonPAGE = { "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "requirements-engineering", "locale": "en", "labels": { "group": "consulting", "capability/strategy": 2.87, "capability/architecture": 2.51, }, "annotations": { "source": "src/content/services/en/requirements-engineering.md", "route": "/en/services/requirements-engineering/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/requirements-engineering.md", }, }, "spec": { "title": "Requirements Engineering", "group": "consulting", "audience": ["enterprise", "provider"], "order": 6, "tags": ["strategy", "architecture"], "summary": "Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left.", "photoNeed": "A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table", "stub": False, "draft": False, "sections": [ { "heading": "

What it is for

", "body": ( "So that the technology fits the business processes rather than the other way round.\n" "Requirements engineering is the tool for reconciling technology, processes and what people\n" "actually need, before a decision is made.\n" "\n" "Without that step you procure what was convincing in the demo, and afterwards adapt whatever\n" "can be adapted." ), }, { "heading": "

How it runs

", "body": ( "Systematically, in workshops. We help define and capture every relevant requirement and\n" "figure: functional and non-functional, and in particular the numbers that later decide the\n" "architecture.\n" "\n" "That includes an analysis of today's system usage and an outlook over the next five years as\n" "the measure for scaling. Requirements shared by several services are captured once. The\n" "result also carries a budget request." ), }, { "heading": "

What the workshops cover

", "body": ( "Not everything at once, but these topics come up in every project:\n" "\n" "- Availability requirements, meaning RPO and RTO\n" "- Capacity and performance, today and over the planned horizon\n" "- System and storage performance\n" "- Security\n" "- Data centre locations\n" "- Data protection\n" "- Application realities and legacy systems\n" "\n" "The last one is the one most often missing and the most expensive to add late. An\n" "application that needs a particular database version has a say in the architecture,\n" "whatever else was planned." ), }, { "heading": "

Why it comes first

", "body": ( "Because other services build on it. A data management design without known access patterns\n" "and retention periods is guesswork, and a disaster recovery design without RPO and RTO is\n" "not a design.\n" "\n" "Requirements engineering is therefore rarely the project somebody rings about, and often the\n" "one the project should have started with." ), }, ], }, "status": { "corpus": 315, "solutions": [ { "ref": "solutions/hpe/hpe-server", "score": "0.41", }, { "ref": "solutions/hpe/hpe-server/hpe-synergy", "score": "0.41", }, { "ref": "solutions/ibm", "score": "0.41", }, { "ref": "solutions/ibm/ibm-power10", "score": "0.41", }, ], "alsoLike": [ { "ref": "services/enterprise-architecture", "score": "1.00", }, { "ref": "services/it-strategie", "score": "1.00", }, { "ref": "posts/vmware-license-changes-2025", "score": "0.52", }, ], "experts": [ { "ref": "experts/aldo-gwerder", "score": "0.36", }, { "ref": "experts/steven-rodenburg", "score": "0.34", }, { "ref": "experts/fabian-faessler", "score": "0.33", }, ], "search": "/en/search.json", },}if __name__ == "__main__": print(json.dumps(PAGE, indent=2, ensure_ascii=False))

# Code generated by the soultec.ch build. DO NOT EDIT.$Page = [ordered]@{ apiVersion = 'soultec.ch/v1' kind = 'Service' metadata = [ordered]@{ name = 'requirements-engineering' locale = 'en' labels = [ordered]@{ group = 'consulting' 'capability/strategy' = 2.87 'capability/architecture' = 2.51 } annotations = [ordered]@{ source = 'src/content/services/en/requirements-engineering.md' route = '/en/services/requirements-engineering/' schema = '/nerd/schema/services.json' markdown = '/en/services/requirements-engineering.md' } } spec = [ordered]@{ title = 'Requirements Engineering' group = 'consulting' audience = @('enterprise', 'provider') order = 6 tags = @('strategy', 'architecture') summary = 'Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left.' photoNeed = 'A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table' stub = $false draft = $false sections = @( [ordered]@{ heading = '

What it is for

' body = @'So that the technology fits the business processes rather than the other way round.Requirements engineering is the tool for reconciling technology, processes and what peopleactually need, before a decision is made.Without that step you procure what was convincing in the demo, and afterwards adapt whatevercan be adapted.'@ } [ordered]@{ heading = '

How it runs

' body = @'Systematically, in workshops. We help define and capture every relevant requirement andfigure: functional and non-functional, and in particular the numbers that later decide thearchitecture.That includes an analysis of today's system usage and an outlook over the next five years asthe measure for scaling. Requirements shared by several services are captured once. Theresult also carries a budget request.'@ } [ordered]@{ heading = '

What the workshops cover

' body = @'Not everything at once, but these topics come up in every project:- Availability requirements, meaning RPO and RTO- Capacity and performance, today and over the planned horizon- System and storage performance- Security- Data centre locations- Data protection- Application realities and legacy systemsThe last one is the one most often missing and the most expensive to add late. Anapplication that needs a particular database version has a say in the architecture,whatever else was planned.'@ } [ordered]@{ heading = '

Why it comes first

' body = @'Because other services build on it. A data management design without known access patternsand retention periods is guesswork, and a disaster recovery design without RPO and RTO isnot a design.Requirements engineering is therefore rarely the project somebody rings about, and often theone the project should have started with.'@ } ) } status = [ordered]@{ corpus = 315 solutions = @( [ordered]@{ ref = 'solutions/hpe/hpe-server' score = '0.41' } [ordered]@{ ref = 'solutions/hpe/hpe-server/hpe-synergy' score = '0.41' } [ordered]@{ ref = 'solutions/ibm' score = '0.41' } [ordered]@{ ref = 'solutions/ibm/ibm-power10' score = '0.41' } ) alsoLike = @( [ordered]@{ ref = 'services/enterprise-architecture' score = '1.00' } [ordered]@{ ref = 'services/it-strategie' score = '1.00' } [ordered]@{ ref = 'posts/vmware-license-changes-2025' score = '0.52' } ) experts = @( [ordered]@{ ref = 'experts/aldo-gwerder' score = '0.36' } [ordered]@{ ref = 'experts/steven-rodenburg' score = '0.34' } [ordered]@{ ref = 'experts/fabian-faessler' score = '0.33' } ) search = '/en/search.json' }}$Page | ConvertTo-Json -Depth 32

// Code generated by the soultec.ch build. DO NOT EDIT.package mainimport ( "encoding/json" "os")var page = map[string]any{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": map[string]any{ "name": "requirements-engineering", "locale": "en", "labels": map[string]any{ "group": "consulting", "capability/strategy": 2.87, "capability/architecture": 2.51, }, "annotations": map[string]any{ "source": "src/content/services/en/requirements-engineering.md", "route": "/en/services/requirements-engineering/", "schema": "/nerd/schema/services.json", "markdown": "/en/services/requirements-engineering.md", }, }, "spec": map[string]any{ "title": "Requirements Engineering", "group": "consulting", "audience": []any{"enterprise", "provider"}, "order": 6, "tags": []any{"strategy", "architecture"}, "summary": "Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left.", "photoNeed": "A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table", "stub": false, "draft": false, "sections": []any{ map[string]any{ "heading": "

What it is for

", "body": "So that the technology fits the business processes rather than the other way round.\n" + "Requirements engineering is the tool for reconciling technology, processes and what people\n" + "actually need, before a decision is made.\n" + "\n" + "Without that step you procure what was convincing in the demo, and afterwards adapt whatever\n" + "can be adapted.", }, map[string]any{ "heading": "

How it runs

", "body": "Systematically, in workshops. We help define and capture every relevant requirement and\n" + "figure: functional and non-functional, and in particular the numbers that later decide the\n" + "architecture.\n" + "\n" + "That includes an analysis of today's system usage and an outlook over the next five years as\n" + "the measure for scaling. Requirements shared by several services are captured once. The\n" + "result also carries a budget request.", }, map[string]any{ "heading": "

What the workshops cover

", "body": "Not everything at once, but these topics come up in every project:\n" + "\n" + "- Availability requirements, meaning RPO and RTO\n" + "- Capacity and performance, today and over the planned horizon\n" + "- System and storage performance\n" + "- Security\n" + "- Data centre locations\n" + "- Data protection\n" + "- Application realities and legacy systems\n" + "\n" + "The last one is the one most often missing and the most expensive to add late. An\n" + "application that needs a particular database version has a say in the architecture,\n" + "whatever else was planned.", }, map[string]any{ "heading": "

Why it comes first

", "body": "Because other services build on it. A data management design without known access patterns\n" + "and retention periods is guesswork, and a disaster recovery design without RPO and RTO is\n" + "not a design.\n" + "\n" + "Requirements engineering is therefore rarely the project somebody rings about, and often the\n" + "one the project should have started with.", }, }, }, "status": map[string]any{ "corpus": 315, "solutions": []any{ map[string]any{ "ref": "solutions/hpe/hpe-server", "score": "0.41", }, map[string]any{ "ref": "solutions/hpe/hpe-server/hpe-synergy", "score": "0.41", }, map[string]any{ "ref": "solutions/ibm", "score": "0.41", }, map[string]any{ "ref": "solutions/ibm/ibm-power10", "score": "0.41", }, }, "alsoLike": []any{ map[string]any{ "ref": "services/enterprise-architecture", "score": "1.00", }, map[string]any{ "ref": "services/it-strategie", "score": "1.00", }, map[string]any{ "ref": "posts/vmware-license-changes-2025", "score": "0.52", }, }, "experts": []any{ map[string]any{ "ref": "experts/aldo-gwerder", "score": "0.36", }, map[string]any{ "ref": "experts/steven-rodenburg", "score": "0.34", }, map[string]any{ "ref": "experts/fabian-faessler", "score": "0.33", }, }, "search": "/en/search.json", },}func main() { enc := json.NewEncoder(os.Stdout) enc.SetEscapeHTML(false) enc.SetIndent("", " ") if err := enc.Encode(page); err != nil { os.Exit(1) }}

// Code generated by the soultec.ch build. DO NOT EDIT.const page = { apiVersion: "soultec.ch/v1", kind: "Service", metadata: { name: "requirements-engineering", locale: "en", labels: { group: "consulting", "capability/strategy": 2.87, "capability/architecture": 2.51, }, annotations: { source: "src/content/services/en/requirements-engineering.md", route: "/en/services/requirements-engineering/", schema: "/nerd/schema/services.json", markdown: "/en/services/requirements-engineering.md", }, }, spec: { title: "Requirements Engineering", group: "consulting", audience: ["enterprise", "provider"], order: 6, tags: ["strategy", "architecture"], summary: "Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left.", photoNeed: "A working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table", stub: false, draft: false, sections: [ { heading: "

What it is for

", body: "So that the technology fits the business processes rather than the other way round.\n" + "Requirements engineering is the tool for reconciling technology, processes and what people\n" + "actually need, before a decision is made.\n" + "\n" + "Without that step you procure what was convincing in the demo, and afterwards adapt whatever\n" + "can be adapted.", }, { heading: "

How it runs

", body: "Systematically, in workshops. We help define and capture every relevant requirement and\n" + "figure: functional and non-functional, and in particular the numbers that later decide the\n" + "architecture.\n" + "\n" + "That includes an analysis of today's system usage and an outlook over the next five years as\n" + "the measure for scaling. Requirements shared by several services are captured once. The\n" + "result also carries a budget request.", }, { heading: "

What the workshops cover

", body: "Not everything at once, but these topics come up in every project:\n" + "\n" + "- Availability requirements, meaning RPO and RTO\n" + "- Capacity and performance, today and over the planned horizon\n" + "- System and storage performance\n" + "- Security\n" + "- Data centre locations\n" + "- Data protection\n" + "- Application realities and legacy systems\n" + "\n" + "The last one is the one most often missing and the most expensive to add late. An\n" + "application that needs a particular database version has a say in the architecture,\n" + "whatever else was planned.", }, { heading: "

Why it comes first

", body: "Because other services build on it. A data management design without known access patterns\n" + "and retention periods is guesswork, and a disaster recovery design without RPO and RTO is\n" + "not a design.\n" + "\n" + "Requirements engineering is therefore rarely the project somebody rings about, and often the\n" + "one the project should have started with.", }, ], }, status: { corpus: 315, solutions: [ { ref: "solutions/hpe/hpe-server", score: "0.41", }, { ref: "solutions/hpe/hpe-server/hpe-synergy", score: "0.41", }, { ref: "solutions/ibm", score: "0.41", }, { ref: "solutions/ibm/ibm-power10", score: "0.41", }, ], alsoLike: [ { ref: "services/enterprise-architecture", score: "1.00", }, { ref: "services/it-strategie", score: "1.00", }, { ref: "posts/vmware-license-changes-2025", score: "0.52", }, ], experts: [ { ref: "experts/aldo-gwerder", score: "0.36", }, { ref: "experts/steven-rodenburg", score: "0.34", }, { ref: "experts/fabian-faessler", score: "0.33", }, ], search: "/en/search.json", },};console.log(JSON.stringify(page, null, 2));

# 85 lines · YAML · validated at build# 104 lines · JSON · validated at build# 124 lines · TOML · validated at build# 140 lines · XML · validated at build# 140 lines · Python · read back at build, equals the JSON record# 137 lines · PowerShell · read back at build, equals the JSON record# 144 lines · Go · read back at build, equals the JSON record# 129 lines · JavaScript · read back at build, equals the JSON record · served at /en/services/requirements-engineering.md

Service · consulting

Requirements Engineering

Reconcile technology with processes and user needs before you buy. Otherwise you buy what demonstrated well and use whatever is left.

Topics Strategy 2.87 Architecture 2.51

04Solutions

02Capabilities

315Corpus

photograph wantedA working session with a customer: a whiteboard with a real diagram, or two people over a laptop across a table

What it is for

So that the technology fits the business processes rather than the other way round. Requirements engineering is the tool for reconciling technology, processes and what people actually need, before a decision is made.

Without that step you procure what was convincing in the demo, and afterwards adapt whatever can be adapted.

How it runs

Systematically, in workshops. We help define and capture every relevant requirement and figure: functional and non-functional, and in particular the numbers that later decide the architecture.

That includes an analysis of today’s system usage and an outlook over the next five years as the measure for scaling. Requirements shared by several services are captured once. The result also carries a budget request.

What the workshops cover

Not everything at once, but these topics come up in every project:

Availability requirements, meaning RPO and RTO
Capacity and performance, today and over the planned horizon
System and storage performance
Security
Data centre locations
Data protection
Application realities and legacy systems

The last one is the one most often missing and the most expensive to add late. An application that needs a particular database version has a say in the architecture, whatever else was planned.

Why it comes first

Because other services build on it. A data management design without known access patterns and retention periods is guesswork, and a disaster recovery design without RPO and RTO is not a design.

Requirements engineering is therefore rarely the project somebody rings about, and often the one the project should have started with.