DE · EN
Call us
+41 44 508 80 00 Ueberlandstrasse 1, 8600 Dübendorf
build 7bbbddf7 | content blog-content@c8490fa · 338 posts | profiles 20 · corpus 267 | ● 0 skipped | | format
apiVersion: soultec.ch/v1kind: Servicemetadata: name: requirements-engineering locale: en labels: group: consulting capability/strategy: 3.54 capability/architecture: 2.93 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 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. - 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: 267 solutions: - {ref: solutions/hpe/hpe-server, 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.53}
{ "apiVersion": "soultec.ch/v1", "kind": "Service", "metadata": { "name": "requirements-engineering", "locale": "en", "labels": { "group": "consulting", "capability/strategy": "3.54", "capability/architecture": "2.93" }, "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", "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." }, { "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": 267, "solutions": [ { "ref": "solutions/hpe/hpe-server", "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.53" } ] }}
apiVersion = "soultec.ch/v1"kind = "Service"[metadata]name = "requirements-engineering"locale = "en"[metadata.labels]group = "consulting""capability/strategy" = "3.54""capability/architecture" = "2.93"[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"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[[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.'''[[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.'''[[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 = 267[[status.solutions]]ref = "solutions/hpe/hpe-server"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.53"
<?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">3.54</entry> <entry key="capability/architecture">2.93</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> <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> </spec> <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. </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> <status> <corpus>267</corpus> <solutions> <item> <ref>solutions/hpe/hpe-server</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.53</score> </item> </alsoLike> </status></manifest>
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 3.54 Architecture 2.93
03Solutions
02Capabilities
267Corpus

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.

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.

Experts for this

Focus areas are not yet confirmed, so nobody is suggested here automatically.

Maybe you? Take a look at our open roles.

You might also like

service 1.00

Enterprise Architecture

service 1.00

IT Strategy

post 0.53

VMware by Broadcom – License Changes