Software projects: everything you need to know about the expression of requirements

How do you go about properly defining your expression of requirements in the context of an IT development project? What should your expression of need contain, and how to structure it? An expression of requirements describes only what is expected – it doesn’t give indications on how to achieve or actually realize the software tool.

A good expression of requirements will play a big role in the success of a project. Many contractors fail – due to a lack of experience, support, knowledge or even ambition – to properly define an expression of requirements. This usually results in a production team developing an IT product that is not in line with the real expectations of end users. And for good reason: the requirements were poorly expressed and therefore poorly conveyed to the team tasked with actually building the tool. In this article, we will reveal to you, step by step, both in substance and in form, how to properly construct an expression of requirements in IT: whether it is for software, a web or a mobile app.

Why create an expression of requirements?

Let’s start from the beginning. What is the point of an expression of requirements? It’s simple: the expression of requirements (ER) is the first document produced for a project, before it even begins. The document will essentially form the basis of all to follow. The ER determines whether the project will be launched (or not), the details of the requirements, and the return on investment. The ER is first sent to decision makers and then to the project management team.

Who writes the ER?

In general, it’s the Project Owner whose requirements need to be expressed – and it is therefore their responsibility to produce the document. The person who is ultimately tasked with writing the ER can be accompanied and advised by an IT service provider, or by any internal team member with the experience and insight required for the task.

After the ER, it’s time to draft the project’s specifications. We’ve already written an article on how to write robust product specifications that you can browse for reference.

What are some of the challenges faced when writing an ER?

The main difficulty encountered in expressing requirements is the ability to make your requirements understood in a clear and intelligible way.

These are some of the stumbling blocks that can often be encountered along the way:

• When the person drafting the ER doesn’t have enough perspective or experience with the professional requirements or context that need to be integrated in the ER.
• When the problem the software is intended to solve is complex or difficult to communicate.
• When the demands or requirements for the project are misplaced or unrealistic.
• When the writer restricts themselves to addressing only the functional or the technical component of the project.

Do formatting constraints need to be respected?

In short – Yes! It’s very important to respect formatting rules in order to create an ER that is easy to understand, distribute and modify. As a usual practice, consider including the following information in your document:

• The name of the author
• The function of the author
• The date the document was created
• The modification dates of the document
• The document version history
• The nature of the modifications implemented by each corresponding author.
• The distribution list: the names and functions of the people that the document has been distributed to.
• A glossary at the beginning of the document to explain the terms and acronyms used, which may not be known by all.

What should the ER contain?

In order to provide a holistic view to stakeholders who need to understand a project’s requirements, be sure to include the following in your document:

• The positioning / strategic importance of the Product Owner and the product that will be developed.
• The expected deadline schedule
• The type of user(s) targeted by the product
• The use cases that the product will seek to fulfill: for example, ordering a pizza online, subscribing to a magazine, paying in bitcoin, etc. This can also be called “the description of the functional needs of end users”. This part is crucial: if it is poorly understood and expressed, there is no point in wasting resources trying to take the project further.
• The technical context
• Constraints of all kinds: technical, operational, contextual, etc.

How to discuss the strategic positioning of your product?

Your product has strategic importance – that’s why you have decided to embark on it in the first place. Exploring “the why” of your software can reveal its strategic importance describe how it will be used by end users. Detail the benefits of the software to your business and end users.

Finally, another point often overlooked by those who write the ER is: what would happen if the product is not developed and the project doesn’t go forward? Taking time to outline and detail all these points will really help the team involved in the project understand it in depth and take ownership of it.

How to build your deadline schedule?

Announcing a realistic and consistent deadline schedule provides legitimacy and professionalism to your ER. The software project schedule should indicate:

• The date the project can start.
• Is there a deadline for finalization? Is this finalization date an incentive/goal or a non-negotiable one?
• The availability of the people involved in the project.

How to properly describe the end users of the planned software?

The more precisely you describe the end users of the development project, the more material and input you give to the design and development teams for understanding the essence of the use cases they will have to create and serve. Another major lever for success is the acceptance of the tool by end users.

Characteristics of end users that need to be explored and addressed are:

• Who are they, and what is their profile? High-tech consumers, doctors, students, single women, financiers, etc.
• How many users are expected, in total and simultaneously? How many users will share the same network at the same time?
• Are they used to using IT tools similar to your planned product? Evaluate their level of competency with IT solutions.
• Divide:
  • Who will be the administrators of the software?
  • Who will be the simple users of the software?

And for each of the above, what will their tasks and uses of the software be?

How to describe the functional needs and the technical context of the software?

In the functional needs section, you describe – in as neutral a way as possible – each functional need of each end user. In other words, describe the use cases of the application one-by-one.

Example:

• A01 – The user creates a personal space.
• A02 – The user views the product catalogue.
• A03 – The user pays by Paypal.
• A04 – The user unsubscribes.
• A05 – The user contacts customer service by chatbot.

Break each use case down in detail – taking care to not be either too brief and simple, or too complex.

These cases should be named and numbered as needed for better access and reference later.

By doing this, you can then prioritize the needs and group them by categories.

Finally, obviously remember to describe the technical aspects:

• What types of physical media will the software be used with?
• What operating systems will it need to be compatible with?

If you need close support to write a professional ER, get in touch.

Copyright images: unsplash.com