Intranet requirement specification – 10 tips for good results

Please note that this article is over 9 years old, so the content and links may not necessarily be up to date. For more recent reading, you might be interested in one of these articles:

As a result of the intranet concept design phase, a specifications document is created. This document is attached as a part of the request for proposals (RFP) for possible vendors. Carefully prepared requirement specifications function as a general guideline throughout the whole intranet implementation.These tips will lead you to even better results when drawing up your own specifications

North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.

26 January 2015

Hanna P. Korhonen

1. A specifications document is neither a bulleted list of individual technical requirements nor a pile of stylishly playful layout suggestions

Instead, it is a document which mostly contains text, which gives an overview of the service that you want to purchase, and what the result should be like. It contains a comprehensive description of the goals, users, structure, functionality, and the UI principles for the intranet.

Typically, a visual concept created by a graphic designer is not included as a part of the requirement specifications. Instead, the visuals will be purchased from the vendor as a part of the implementation project. A well-made specifications document can be used as the basis for lists of individual parts of the implementation (e.g. product backlog).

2. Be precise enough

Requirement specification must be done at a level of detail which allows the vendor to estimate the workload for the implementation, and provide their quotation based on it.

3. Don’t go into too much detail

In the end, you should be able to rely on the vendor’s professional ability to choose the best technical solution. Define clearly what you want. However, especially in situations that are unclear to you, do not restrict the vendor with too many details, such as stipulating the building blocks for the implementation.

Think of the vendor as the chef at a catering service: they will – according to your wishes – prepare the courses from appetizers to dessert for the event where you have invited the guests and set the goals, the nature of the get-together, limitations for the menu, as well as the budget. If the implementation relies on the basic functionality of a certain product, it is not necessary to list all these functions. Focus on the most important deviations and particularities.

4. Don’t be ambiguous

Keep ambiguity out of the requirement specifications. Either a functionality is included within the scope, or it is not. Do not write down anything vague in the specifications, since it will probably raise the cost (in case the vendor prepares themselves for the worst) and/or create unjust differences between vendors (in case the vendors have differing interpretations of the terms).

Blurred visions may be entered in a separate section as suggestions for future development.

5. Draw the big picture

Illustrate the key aspects of the intranet with a drawing. You may include other, closely related systems and the links between them in the illustration.

6. Present the structure

Make sure you introduce the plans for the intranet navigation and/or content structure. This brings the concept to life and helps to piece together the whole entity. However, you must remember that the vendor responsible for the technical implementation is not particularly interested in the contents of the basic content pages or the order between them – even if you hold these things very dear yourself. A requirements specification document maintains its focus on issues that must be taken into account in the technical implementation.

7. Illustrate the UI with wireframe models

You can use wireframe models to firm up your message. Create wireframe images for the page templates, especially if they deviate greatly from what is commonly seen, or from the default page templates of a product candidate. Wireframe models can also be used to illustrate some of the most important views of the intranet, such as the home page.

8. Use terms consistently

Use a single term for a single entity, and do it carefully and coherently. For instance: do you call a certain thing “an element”, “a component”, “a section”, “a part”, “a site” – maybe “an entity” as well?

9. Give a roadmap for the future

Even though the intranet to be implemented is a clearly defined package, you may very well dedicate a separate chapter for possible future development plans for the intranet. Make it clear that these plans are not part of the entity that is implemented in the first stage (and for which RFPs are requested). Plans for future development may be very approximate in their nature, and they are not binding for any of the parties involved. However, they may motivate the partner to provide their tender with the thought of possible future work in mind.

10. Seek professional help

Just like intranet implementation, specifying the requirements can also be outsourced. You can have people from the partner that is going to build the intranet help you specify the requirements, or you can enlist an independent consultant like North Patrol.

Requirement specification professionals know what kind of content should be included in the specifications document, and which level of detail yields the best results. They also know, what the partners responsible for technical implementation expect of a requirement specification. Often they are also able to bring other types of expertise, experiences from other organizations, and new ideas into the process. If the requirement specification professionals do not work for the future implementation partner, it is more likely that they can suggest easier and more reasonably priced alternatives for given functionalities.

Consultants often work closely with the client, and facilitate workshops, where the consultants together with the client’s project team refine the goals for the implementation, service concept and the key functionalities. The consultant’s role is to bring forth good practices, to offer their expertise on technical platforms and to create a specifications document based on the concept created by the team.

Digital workplace

Looking for advice on improving digital workplace tools or intranet? North Patrol's team helps you design a new intranet concept and select the right tools and technologies for your implementation.

Read about our services

Request a quote

About North Patrol

We are a team of ten consultants, all of whom are experienced designers and technology experts. Every year we design and prepare over 50 different online services and information systems. Our customer satisfaction is very high (9.5 out of 10), and we have helped many customers transform their digital services.

Read more about us

How we differ from our competitors?

  • We specialize in digital service design

    We specialize in high-quality design and requirements specification of digital services. Our mission is to help customers succeed in their software project by creating the best possible foundation for implementation – whether it is an agile implementation done inhouse, a project done with a partner, or a publicly tendered project.

  • We don't sell coding or licenses

    Many software companies recommend software solutions that they also implement themselves. We don’t do that. We don’t do software implementation projects or have partnerships with technology providers. Our perspective on the software market is broad, as it should be for our customers. Our goal is always to find the best possible software solution for our customer, whether it’s a custom-built solution, a SaaS service, an open-source platform, or a combination of these.

  • We are realistic and forward-thinking

    We design digital service concepts, implementation methods and architectures that are sustainable and can be further developed. We place great importance on the feasibility of software solutions, the availability of good partners and the predictability of costs.

Back to top