How could information system specification be done better and faster? This question has emerged as AI-assisted coding has brought pressure on both the quantity and quality of specification.

We delved into the best practices of specification and service design in February when we gathered with our clients for a morning at EMMA, the Espoo Museum of Modern Art.

During the morning event, we discussed, based on keynote presentations, what successful requirements specification requires today. A central theme that emerged was the idea that requirements specification is multifaceted: a successful outcome is only achieved when the technical, business, and user-centric perspectives are in balance. If even one perspective is missing, the specification will inevitably be incomplete.

Below, you can navigate directly to the theme that interests you most:

Why three perspectives?
Best practices from each perspective
The interplay between service design and specification is crucial
Balance comes from diverse expertise, not the number of role titles
In the future, the specifier’s role will expand, not narrow

Why three perspectives?

Requirements specification has three roots that stem from different scientific disciplines and ways of thinking. These approaches originate from different eras, but despite their age, all are highly relevant in today’s specification work.

• The technical perspective emerged in the 1970s when software development became professionalized. Its question was simple: how is this built? The task of specification was to translate vague wishes into precise instructions for the machine. This school draws on information systems science and software development methodologies.
  
  The clarity of specifications has become even more important with the rise of AI-assisted coding. AI cannot produce quality code if the requirements are not unambiguous.

• The business perspective emerged in the 1990s. The question changed: what does it cost and what does it deliver? The task of specification was to ensure that the end product supports strategy and that the investment pays for itself. This is underpinned by business economics, strategic management, and lean thinking.
  
  The business perspective is obviously extremely important in the age of AI as well. Although code production is fast and easy, costs must still be evaluated in terms of business benefit versus the total lifecycle costs of the system.

• The user-centric perspective gained strength in the 2000s. Its question is: what problem does this solve? The goal is for the end product to genuinely meet the user’s need. This school draws from design, sociology, cognitive psychology, and design thinking methodologies.
  
  The user-centric perspective has a very significant role in the specification of consumer products. In the development of internal enterprise systems, the user experience has traditionally not been considered as important. Our thinking at Reflector, however, is that the tools and mindset of the user-centric perspective bring clear benefits to internal enterprise systems as well, for example by reducing user errors.

Best practices from each perspective

Each perspective brings its own best practices to specification. The practices of all three perspectives are relevant in the AI era as well. Bypassing the best practices of even one perspective makes the specification incomplete.

Tips from the technical perspective

• Write the requirement so that it can only be interpreted in one way.

• Formulate each requirement to be testable. If it cannot be verified, it cannot be accepted either.

• Do not forget non-functional requirements. For example, performance, security, and maintainability determine the lifecycle of the end product.

• Remember to define behavior in exceptional situations as well.

• Keep traceability in order. Each requirement must link to the original need and implementation.

Tips from the business perspective

• For each requirement, ask why this is important. If the answer cannot be found in the strategy or business objectives, the requirement should be challenged.

• Prioritize openly. Not everything can or should be done, and the decision about what to leave out is as important as the decision about what to do.

• Make the cost-benefit analysis visible. The decision is easier to make when the justification for the investment is clear.

• Ensure that the requirements serve the entire organization, not just the view of a single team or unit.

Tips from the user-centric perspective

• Derive the requirement from a real usage situation, not from an assumption. Go on-site, observe, and ask.

• Listen to the user’s own language. A stated wish is rarely the same as the actual need, and finding that need is the specifier’s most important task.

• Test requirements along the way. Iteration is cheaper than fixing things afterwards.

• Remember that usability is part of the requirement, not a coating added afterwards.

The interplay between service design and requirements specification is crucial

The rise of the user-centric perspective in the 2000s has somewhat blurred the roles of the technical perspective (i.e., specification or requirements specification) and the user-centric perspective (i.e., service design) in successful information system projects.

In consumer product design, service design has established its place. On the other hand, in the development of internal enterprise systems, service design has not been able to displace specification and requirements specification in the same way as in consumer products. It is natural that in the development of internal, often complex systems, the technical and business perspectives are emphasized.

Our thesis is that the user-centric perspective absolutely has its place in the development of internal enterprise systems as well. The user-centric perspective easily finds its place alongside other perspectives.

In practice, the best outcome is achieved when service design and specification are done sequentially and in an overlapping manner.

➜ Service design brings customer understanding and the concept.
➜ Requirements specification refines the concept into precise requirements from which a functional system can be implemented.

Without service design, the outcome can be technically perfect but difficult for the user. Without requirements specification, the outcome can be emotionally profound but technically impossible.

Balance comes from diverse expertise, not the number of role titles

When projects are pursued more efficiently and with smaller teams, the question of the number of required roles easily arises. Could the diverse roles required in specification be combined, or could one person handle all roles in some cases?

Our view is this:

• In small teams the roles can easily be combined (e.g. service designer + business analyst)

• In large projects, it is more beneficial to keep roles separate but work closely together. For example, joint workshops, shared backlog, describing processes together.

Even one person can bring all perspectives to specification, but it requires the individual to be able to examine their own work from different perspectives. Which perspective comes naturally, and which requires more concentration? Is there a risk that one perspective will be overshadowed and cause problems for the quality of the end product?

In the future, the specifier’s role will expand, not narrow

Finally, we discussed the future of requirements specification. What will the 2030s look like? AI and automation will further accelerate the pace of change. Requirements will become dynamic and increasingly emerge from data and processes. They must be interpreted continuously.

These changes do not mean that the requirements specifier’s role will disappear—quite the opposite. The role will become more demanding and more strategic. The requirements specifier will become a kind of architect who combines business objectives, technological possibilities, and ethical constraints. They will master systems thinking, interpret AI-generated requirement proposals, and facilitate change within the organization.

What is interesting is that in the age of AI, all three perspectives are emphasized simultaneously. Technical understanding is essential to properly define the role of AI. A business approach is essential to maintain strategic traceability. The user-centric perspective is essential to ensure that dynamically generated requirements genuinely serve people.

Investing in the diverse expertise of specification and service design and in the three perspectives is worthwhile right now, and it will bear fruit in the 2030s as well.