Website Specifications: Template, Completed Example, and Differences from the Requirements Specification

What should actually be included in a requirements specification when a company simply wants a new website? Most of the templates available online come from the fields of mechanical engineering, ERP implementation, or accounting software. For a website relaunch, these templates are missing precisely the details that cause projects to fail later on: who will provide the content, what will happen to the old URLs, how acceptance will be verified, and what a realistic budget is.

We therefore analyzed six genuine, publicly available requirements specifications and service descriptions from government agencies, libraries, and associations for website projects; reviewed the relevant laws; evaluated the standards found in professional literature; and used this information to create a template specifically for corporate websites. You’ll receive it as a blank template to fill out and as a completed example for a fictional sample company, each available as a Word file and a PDF.

In a nutshell (as of October 2026)

A requirements specification describes what the new website must do, while the scope of work describes how the agency will implement it. You, as the client, write the requirements specification, and the agency writes the scope of work. The most important step: Assign each requirement a priority and a criterion against which you’ll evaluate it during acceptance testing. Our template (as a Word file ) and the completed example (as a PDF ) have dedicated columns for this purpose.

Specifications and Requirements Specifications: The Difference in One Sentence

The requirements specification comes from the client and outlines what is needed; the scope of work comes from the contractor and outlines how it will be implemented. This is the distinction made by the project management standard DIN 69901-5. Essentially, the requirements specification is the set of requirements for the contractor’s services as defined by the client. The scope of work consists of the implementation specifications that the contractor develops based on these requirements.

Without a requirements specification, there can be no meaningful functional specification. The functional specification builds on the requirements and supplements them with the technical solution. In international requirements engineering, the requirements specification is called the “customer requirements specification”; according to the IREB glossary, this is a general description of the capabilities needed from the customer’s perspective. The functional specification corresponds to the “system requirements specification.”

Requirements Specification and Functional Specification using a corporate website as an example: the requirements on the left, the solution on the right. Terms according to DIN 69901-5 and the IREB Glossary; examples from our template.

Please note when reading court rulings or contracts: Lawyers often use the term “Pflichtenheft” when they actually mean “Lastenheft.” A lecture on legal IT project management at LMU Munich explicitly points this out. In court rulings and contracts, “Pflichtenheft” therefore often refers to the client’s technical specifications. Be sure to clarify in the contract which document is being referred to by which name.

A set of specifications from Mecklenburg-Western Pomerania illustrates how this works in a real-world project. In 2019, three protected area management agencies issued a request for proposals for the relaunch of the websites for five national parks and biosphere reserves. The request for proposals explicitly states that the future contractor must develop a concept in the form of a requirements specification within ten weeks of being awarded the contract, which the client must then approve.

Specifications for “Website Relaunch for National Natural Landscapes in Mecklenburg-Western Pomerania” (2019), p. 13: The agency drafts the specifications; this is followed by a 12-week stabilization phase and formal acceptance after the comprehensive functional testing. Emphasis added by us.

Why a Specification Document Pays Off for Businesses

Without a statement of requirements, you’ll be comparing proposals that don’t offer the same things. For example, one agency might quote 20 templates, another 8, and a third might not even include the transfer of product data in its quote. The German government’s V-Modell XT therefore describes the statement of requirements as “the basis for the request for proposals and contract drafting, and thus the most important guideline for preparing a proposal.”

In the event of a dispute, what has been agreed upon takes precedence. According to the case law of the Federal Court of Justice, a website is generally considered a work within the meaning of the law governing contracts for work (BGH, judgment of March 4, 2010, III ZR 79/09). Whether a work is free of defects is determined, pursuant to § 633 of the German Civil Code (BGB), first and foremost by the agreed-upon quality. Only if nothing has been agreed upon does the purpose of the contract and customary practice come into play.

The audit sequence under Section 633(2) of the German Civil Code (BGB), simplified. The more precisely Step 1 is defined in the contract and in the accompanying specifications, the less depends on the auditor. This is not legal advice.

In the event of a dispute, the court determines what is “customary,” with the assistance of an expert if necessary. With regard to software, the Federal Court of Justice (BGH) has held that if the parties have not specifically agreed on what the program is intended to do, the contractor is obligated to provide a program that “corresponds to the state of the art at an average standard of execution” (judgment of December 16, 2003, X ZR 129/01). This concerned custom software. Since the BGH compares web design to custom software, it stands to reason that this principle applies to websites as well; however, we have not found a specific ruling on websites.

Otherwise, acceptance can quickly become a trap for businesses. According to Section 640(2) of the German Civil Code (BGB), a work is deemed accepted if, after completion, the contractor sets a reasonable deadline for acceptance and the customer does not refuse acceptance within that deadline by citing at least one defect. The contractor is only required to provide this protective notice regarding this consequence to consumers. Anyone who has specified acceptance criteria in the specifications can state specifically what is missing within the deadline.

A well-known case from the U.S. illustrates just how costly misunderstandings can be. In 2019, the car rental company Hertz sued the consulting firm Accenture for more than $32 million over a failed website relaunch. According to the lawsuit, one of the missing features was a tablet version of the site, which Hertz believed had been agreed upon. Accenture called the lawsuit unfounded; we have not been able to find reliable information on the outcome of the case.

The Process: From the Current Status to Acceptance

Write the requirements specification before you send your first inquiry to agencies, not after. If you first request proposals and then gather requirements, you’ll receive proposals based on assumptions. This nine-step process clearly distinguishes between what you provide and what the agency provides.

From the current status through the requirements specification, bids, and functional specifications to acceptance and operation. Terms are used in accordance with DIN 69901-5; the process is based on the requirements specification from Mecklenburg-Western Pomerania.

Set aside paid time for the requirements specification. A good requirements specification is developed in workshops with your subject matter experts—that is, with sales, IT, and editorial staff. The requirements specification from Mecklenburg-Western Pomerania calls for eight workshop days, two of which are dedicated to defining the requirements and finalizing the specification. If this phase is not included in the proposal, you should ask where the solution will be addressed instead.

Our Template: Nine Chapters for a Corporate Website

Use the template as a framework and delete anything that doesn't apply to your project. The nine chapters are based on what appears in real requirements documents—and what’s missing from them: Project Overview, Current Status, Goals, Target Audiences, Structure and Content, Features, Quality and Legal Considerations, Relaunch with Redirects, and Budget and Timeline. Each chapter begins with a gray note indicating what should be included.

Excerpt from our blank template: Chapters 3 and 4, with instructions and tables to fill out.

Download both versions—the blank one and the completed one. The blank template is available as a Word file and as a PDF. The completed example is also available as a Word file and as a PDF. The example describes a fictional company called Muster Antriebstechnik GmbH with 240 employees; all names and figures in it are made up.

Expect a handful of pages rather than fifty. In the six documents we analyzed, the actual scope of work section ranges from a little over two to a little over ten pages; a guide from the agency netzreich cites five to fifteen pages for typical projects. There is no study on the ideal length. What matters is that every requirement is verifiable, not that the document is thick.

Chapters 1 and 2: Project Overview and Current Status with Figures

Describe the current status in numbers, because an agency can only calculate what it can count. This includes the domains, the current system, the number of pages and files, the languages, the monthly visits, and the inquiries received through the website. For example, the City of Mayen’s specifications mention “approximately 525 published pages” and include the statistics as an attachment.

Export the pages with the most clicks from Google Search and attach them as a file. In Google Search Console, you’ll find them under “Performance” in the “Pages” tab; click the export button in the top-right corner to get the list as a spreadsheet. Your analytics tool provides the total number of visits. We show you how to read the report in our guide to Search Console. This list will later serve as the basis for determining which pages absolutely must not be lost during the relaunch.

marschfahrt.de Search Console: Under "Performance" (1), select the time period (2); the "Pages" tab (3) lists the pages with the most clicks; click "Export" (4) to get the list as a table. Our own property, added on October 27, 2026.

Mention roles instead of names and specify who makes the final decision: the project manager, the subject-matter experts, and whoever approves the budget and the final deliverables. Agency guides, such as the one from netzreich, cite a lack of designated points of contact as a common mistake, and the agency can only estimate the coordination effort involved if it knows the decision-making process.

Chapter 3: Goals You Can Evaluate

Write down each goal with a metric, a baseline, and a target. “More inquiries” is just a hope. “Increase form inquiries per month from 12 to 25 after six months” is a goal against which the concept and the agency can be evaluated. In our template, the goals table has exactly these four columns.

Strike out “modern” and “innovative” unless it’s specified how these qualities can be identified. This is also found in actual specifications. In 2019, the Saxon State Library wanted a website that was “significantly more modern and innovative” than the previous one. That’s understandable, but it’s neither quantifiable nor verifiable upon acceptance.

Statement of Work “Relaunch of the SLUB Dresden Website” (2019), p. 2: Adjectives without criteria. Emphasis added by us.

Translate every adjective into a test. “Fast” becomes a fixed metric in a lab test before approval and “Good” in the Core Web Vitals after going live; “clear” becomes “a data sheet accessible with no more than two clicks from the homepage”; “accessible” becomes a standardized testing procedure. The city of Mayen addressed this in 2020 with regard to loading time by requiring that the page achieve a score of at least 90 on PageSpeed Insights. You can find out how to properly interpret this score in our article on PageSpeed Insights.

You can use these rephrasings as is. On the left is what you’ll find in many specifications; on the right is how to make it verifiable. The numbers are examples—substitute your own.

Before: The website should have amodern look.
After: The design implements the corporate design from Appendix C ; two drafts, two rounds of revisions.

Before: The site must loadquickly .
After: Before final approval , mobile LCP must not exceed 2.5 seconds and CLS must not exceed 0.1in lab testing ; after going live , Core Web Vitals inSearch Console  must berated “Good” as soon as sufficient data is available.

Before: The website should generatemore inquiries .
After:Form inquiries per month increased from 12 to 25within six months of going live.

Before: The navigation should beintuitive .
After: Every data sheet is accessiblefrom the homepage with no more than two clicks .

Before: The website must beaccessible .
After: Complies with WCAG 2.1 Level AA, as required by EN 301 549; verification provided by a test report prior to acceptance.

Before: The website should have amodern look.
After: The design implements the corporate design from Appendix C ; two drafts, two rounds of revisions.

Before: The site must loadquickly .
After: Before final approval , mobile LCP must not exceed 2.5 seconds and CLS must not exceed 0.1in lab testing ; after going live , Core Web Vitals inSearch Console  must berated “Good” as soon as sufficient data is available.

Before: The website should generatemore inquiries .
After:Form inquiries per month increased from 12 to 25within six months of going live.

Before: The navigation should beintuitive .
After: Every data sheet is accessiblefrom the homepage with no more than two clicks .

Before: The website must beaccessible .
After: Complies with WCAG 2.1 Level AA, as required by EN 301 549; verification provided by a test report prior to acceptance.

Before: The website should have amodern look.
After: The design implements the corporate design from Appendix C ; two drafts, two rounds of revisions.

Before: The site must loadquickly .
After: Before final approval , mobile LCP must not exceed 2.5 seconds and CLS must not exceed 0.1in lab testing ; after going live , Core Web Vitals inSearch Console  must berated “Good” as soon as sufficient data is available.

Before: The website should generatemore inquiries .
After:Form inquiries per month increased from 12 to 25within six months of going live.

Before: The navigation should beintuitive .
After: Every data sheet is accessiblefrom the homepage with no more than two clicks .

Before: The website must beaccessible .
After: Complies with WCAG 2.1 Level AA, as required by EN 301 549; verification provided by a test report prior to acceptance.

Chapters 4 and 5: Target Audiences, Page Types, and Who Provides the Content

Describe target audiences based on their tasks, not their demographics. A design engineer looking for a suitable gearmotor needs filters and CAD data. A job applicant needs a list of job openings and a brief application. The structure and functions almost naturally follow from these tasks.

List the page types and specify who will provide the content and by when. None of the templates we reviewed on October 26, 2026, among the top results on Google included a separate section for this. Without this information, it remains unclear who will provide the text, images, and translations—and that’s exactly what future deadlines depend on. In our example, Product Management provides the product data as an export, Marketing provides the industry-specific texts by a specific calendar week, and Sales provides photos and approvals for customer testimonials.

Specify the languages on a per-page-type basis, not across the board. Often, not every piece of content requires every language. The SLUB Dresden explicitly states that not all German texts need to be translated, and the specifications from Mecklenburg-Western Pomerania require that approximately 50 percent of the content be in easy-to-read language. Such specifications significantly affect the amount of work involved.

Chapter 6: Functions with Priority and Acceptance Criteria

Describe what the website needs to be able to do, not how it does it technically. The German government’s V-Model XT states this clearly: The requirements specification “should generally not prescribe technical solutions” so as not to limit the search for the best solution. In addition, public contracting authorities are generally required to maintain product neutrality for contracts above the EU thresholds pursuant to Section 31(6) of the Public Procurement Regulation, and below those thresholds, usually pursuant to Section 23 of the Sub-Threshold Procurement Regulation.

A real set of specifications shows just how easily one can get sidetracked by solutions. The specifications from Mecklenburg-Western Pomerania require, among other things, a hamburger menu and an animated transformation of a design element for the homepage. Behind these requirements lie legitimate concerns, such as good navigation on mobile devices, which would be better addressed as separate requirements.

Mecklenburg-Vorpommern Specifications (2019), p. 5: Guidelines for solutions rather than requirements. A better phrasing would be, for example, “All sections can be accessed on a cell phone with no more than two taps.” Emphasis added.

Prioritize using four levels: Must, Should, Could, Not This Time. The method is called MoSCoW and originates from agile project management. The DSDM Framework handbook recommends, as a rule of thumb, that “Must” requirements account for no more than 60 percent of the effort and “Could” requirements for about 20 percent. The “Could” requirements serve as a buffer when time or budget is tight.

MoSCoW, using the guidelines from the DSDM handbook and the examples from our template. The “Not this time” level specifies what is explicitly not part of the project.

Also make a note of what’s not included this time. The DSDM handbook explains it this way: By documenting what isn’t being delivered, you prevent it from quietly slipping back into the scope later on. In our example, the customer portal with login is explicitly marked as “Not included this time.”

Assign a criterion to each requirement that you will use to verify it during acceptance testing. You can verify “Inquiries are logged in the CRM along with the product and page” with a test inquiry, and “Data sheet with one click” with a sample of 20 products. The IREB defines acceptance criteria as the criteria that a work product must meet in order to be accepted.

Chapter 6 from our completed example: each requirement, including its number, priority, and acceptance testing. The sample company is fictional.

Chapter 7: Quality, Legal Matters, and Operations

Be sure to also list the requirements that aren’t immediately visible but are still noticeable. These include loading time, accessibility, data protection, security, maintenance by your own team, and operations after the site goes live. The ISO/IEC 25010 quality standard lists, among other things, performance efficiency, security, and maintainability—which serve as a good outline for this chapter.

Establish a standard and a testing procedure for accessibility. The specifications from Mecklenburg-Western Pomerania set an exemplary standard: Pages should score at least 90 points—preferably 95—on the BITV test. This way, the agency knows how it will be evaluated, and you know what to check during the acceptance process.

Mecklenburg-Western Pomerania Specifications (2019), p. 11: Accessibility with a measurable acceptance criterion. Markings added by us.

Check whether the Accessibility Enhancement Act applies to your website. As of June 28, 2025, the BFSG applies to e-commerce services directed at consumers and intended to lead to the conclusion of a consumer contract. A purely B2B website with no consumer-facing business is generally not covered by the Act’s wording; however, the exact boundaries have not been conclusively clarified. Federal government agencies must take accessibility into account as early as the bidding process, in accordance with Section 12a of the Federal Government Act (BGG). You can find more information in our article on accessible websites under the BFSG.

Define data protection as a verifiable function, not as “GDPR-compliant.” According to Section 25 of the TDDDG, storing or reading information on the device requires consent unless it is absolutely necessary. The specifications must therefore include a list of all integrated services, indicating whether they require consent. In addition, there must be data processing agreements under Article 28 of the GDPR with hosting providers and service providers, as well as a legal notice that is easily recognizable and directly accessible in accordance with Section 5 of the German Data Protection Act (DDG).

Clarify access rights, usage rights, and source code before you sign. The Federal Court of Justice (BGH) has ruled regarding software that, in the absence of an express agreement, the specific circumstances determine whether the client receives the source code (X ZR 129/01). Therefore, specify in the requirements specification that access and documentation are part of the handover, and outline the usage rights you require for the components created specifically for you—for example, exclusive rights, unlimited in terms of time and geographic scope, and including the right to modify the software. For open-source systems, their own licenses apply.

Describe the service in terms of numbers: uptime, backups, response times. Mayen requires a minimum uptime of 99.5 percent and daily backups, while Mecklenburg-Vorpommern requires a response time of no more than eight hours for error reports. Whether you need these features yourself depends on your website, but without these numbers, no one can provide you with a quote.

Chapter 8: Relaunch, SEO, and Redirects

Makes redirects a mandatory requirement for the contractor, including a list, type, and duration. This is the chapter that will determine whether you maintain your Google rankings after the relaunch. Only one of the six documents sets this out as a binding requirement: The city of Mayen requires the contractor to redirect old URLs to the corresponding new ones using 301 redirects if the URL structure changes.

City of Mayen’s “2020 Relaunch of the City Website” Specifications, p. 5: Redirects are mandatory; status code 410 for deleted pages. Emphasis added by us.

Follow the guidelines that Google itself provides for a website migration. In its documentation on website migration, Google recommends preparing a mapping of all old URLs to their new counterparts, using permanent redirects such as 301 or 308, and maintaining these “generally for at least one year.” Pages without a successor should return a 404 or 410 error. Our guide to website relaunches outlines the entire process, including a checklist for going live. According to Google, chains of multiple redirects should be avoided; ideally, there should be no more than three, and under no circumstances more than four redirects.

What happens to each old address, according to Google Search Central, “Website Migration with URL Changes.” We recommend that deleted pages should not automatically redirect to the homepage.

Don’t change everything at once if you can help it. Google explicitly advises implementing a domain change, a new system, and a new layout one after the other. To find out when a relaunch is actually worth it, check out our article “Website Relaunch: When It’s Worth It.” If you do decide to change everything at once, document that decision in the requirements specification and set aside more time for monitoring after the site goes live.

Be sure to include the test system and the time after going live in the specifications. The development environment must not appear in Google; Mayen explicitly requires this. After going live, error reports in Search Console should be checked regularly for several weeks. According to Google, it can take several weeks or longer for the new URLs to replace the old ones on medium-sized websites.

Chapter 9: Budget, Timeline, and How to Choose

Specify a budget range, even if it feels unusual. None of the six documents we reviewed mention a specific amount. Companies can do this, and we recommend it: A range tells the agency whether you’re expecting an off-the-shelf solution or a custom platform, and makes it easier to compare proposals.

Our analysis of six publicly available requirements specifications and service descriptions for website projects. Not a single one specifies a budget, and only one sets binding rules for redirects. In the case of the rowing association, only the public portion was available for viewing; the requirements catalog was sent upon request.

Specify firm deadlines and what the proposal should include. If the website needs to be online before a trade show, that should be included in the requirements specification. In the proposal, ask for the estimated effort per section, the team, comparable references, and the annual operating costs. This is the only way to tell if a low-cost proposal simply offers fewer features.

Be transparent about the criteria you use to make your selection. In 2026, the German Center for Aging Issues published an exemplary evaluation grid: Price (40 points), Implementation Plan (25), Service and Support (20), and Timeline (15). This way, agencies can see what matters most to you and prepare more tailored proposals.

Call for Proposals from the German Center for Aging Research (2026), p. 38: Evaluation grid with weighting of price and quality. Emphasis added by us.

Chapters 8 and 9 from our completed example: Referrals, budget, timeline, and selection criteria. The sample company and all amounts are fictitious.

Agile or Fixed-Price: Do You Still Need a Statement of Requirements?

Yes, but a more streamlined one: goals, target audiences, scope, boundaries, and the mandatory requirements. The Scrum Guide does not include a requirements specification. In the Scrum Guide, the Product Backlog is “the sole source of work,” and a product goal describes the desired state. The goals from the requirements specification fit well as product goals, and the requirements as the first items in the backlog.

If you want a fixed price, you need a fixed scope. In 2015, the German Rowing Association put out a request for proposals for a relaunch as a fixed-price contract. The requirements were listed in a separate catalog, but the requirements for the CMS were to be determined only through discussions with the contractor. It is precisely this open-ended aspect that poses a risk with a fixed-price contract. Models such as the “agile fixed price” address this by first defining goals and requirements in a binding manner and then determining the details collaboratively.

Write it yourself or have someone else write it?

Those who lack the time or experience can commission the requirements specification as a separate project. The SLUB Dresden did exactly that: The first phase consisted of a conceptual design phase with workshops, the outcome of which was to include, among other things, “a comprehensive set of requirements and specifications.” The implementation phase came only in the second phase.

In any case, you should provide the goals and the current status yourselves. No one knows your customers, your processes, and your numbers better than you do. An agency can structure requirements, formulate them in a way that allows for verification, and align them with the technology, but it cannot decide what your company needs.

Checklist before you send the specifications

Go through these twelve questions before sending the document to agencies. Any question you hesitate on will later lead to a follow-up inquiry, an addendum, or quotes that can't be compared.

[ ] Is the current statuspresented in numbers  (pages, PDFs, languages, visits, inquiries)?
[ ] Does each objective  have a metric, a baseline , and a target value?
[ ] Are the target audiences describedin terms of their tasks ?
 [ ]For each page type, is it specified  who will deliverthe content and by when ?
 [ ] Does each feature  describe an outcome rather than a technical detail?
 [ ] Does each requirement  have a priority (Must, Should, Can, Not this time )?
[ ] Does each requirement  have an acceptancecriterion ?
[ ] Are accessibility, data protection , and load time definedin measurable terms ?
[ ] Is  itspecified who will set up the redirects from the old to the new pages and how long they will remain in place?
[ ] Is there a budget and afixed timeline?
[ ]Does it specify what the proposal should include and how you will select a vendor?
[ ]Does it specify what isexplicitly not included?

[ ] Is the current statuspresented in numbers  (pages, PDFs, languages, visits, inquiries)?
[ ] Does each objective  have a metric, a baseline , and a target value?
[ ] Are the target audiences describedin terms of their tasks ?
 [ ]For each page type, is it specified  who will deliverthe content and by when ?
 [ ] Does each feature  describe an outcome rather than a technical detail?
 [ ] Does each requirement  have a priority (Must, Should, Can, Not this time )?
[ ] Does each requirement  have an acceptancecriterion ?
[ ] Are accessibility, data protection , and load time definedin measurable terms ?
[ ] Is  itspecified who will set up the redirects from the old to the new pages and how long they will remain in place?
[ ] Is there a budget and afixed timeline?
[ ]Does it specify what the proposal should include and how you will select a vendor?
[ ]Does it specify what isexplicitly not included?

[ ] Is the current statuspresented in numbers  (pages, PDFs, languages, visits, inquiries)?
[ ] Does each objective  have a metric, a baseline , and a target value?
[ ] Are the target audiences describedin terms of their tasks ?
 [ ]For each page type, is it specified  who will deliverthe content and by when ?
 [ ] Does each feature  describe an outcome rather than a technical detail?
 [ ] Does each requirement  have a priority (Must, Should, Can, Not this time )?
[ ] Does each requirement  have an acceptancecriterion ?
[ ] Are accessibility, data protection , and load time definedin measurable terms ?
[ ] Is  itspecified who will set up the redirects from the old to the new pages and how long they will remain in place?
[ ] Is there a budget and afixed timeline?
[ ]Does it specify what the proposal should include and how you will select a vendor?
[ ]Does it specify what isexplicitly not included?

Frequently Asked Questions

How long should a website requirements document be?

As long as necessary to ensure that every requirement can be verified. In the six documents included in our evaluation, the performance section ranges from a little over two to a little over ten pages. There is no reliable study on the ideal length.

Who writes the requirements specification?

The contractor—that is, the agency—describes in the proposal how it will implement the requirements outlined in the specifications. You review and approve the proposal.

Do the specifications automatically become part of the contract?

Not automatically. Whether it becomes part of the contract depends on what you agree upon—for example, whether the offer refers to it. Therefore, make sure to explicitly reference the requirements specification and functional specifications in the contract, including the date and version number. This is not legal advice.

Should a statement of requirements include a budget?

For companies, we recommend setting a range. This prevents bids that fall far short of your expectations and makes the bids comparable. None of the six tenders we evaluated specified an amount.

What is the difference between a specification and a requirements document?

Usually none. "Requirements catalog," "requirements specification," and "customer specification" are other terms used for the requirements document.

Can a set of specifications require the use of a specific CMS?

Companies are permitted to do so, but should provide a justification, such as the fact that their own team is already using it. Public contracting authorities must, as a general rule, issue product-neutral requests for proposals. A specific brand is permissible only if the subject matter of the contract justifies it, usually with the addition of “or equivalent” (Section 31(6) VgV; below the EU thresholds, Section 23 UVgO). This is not legal advice.

Conclusion

Start today by assessing the current situation and setting goals; everything else builds on that. A good website requirements specification is concise, verifiable, and honest: It specifies what is needed, who will provide what, what will happen to the old URLs, and what budget is available. Actual requirements specifications from public agencies show that these are precisely the points that are most often missing.

Download the template, fill out sections 1 through 3 yourself, and only then request quotes. If you’re planning a relaunch and want to work with us to refine the requirements, you can find our approach on the page about web design for businesses.