As CTO, my experience taught me that project success boils down to this single element done right: expressing requirements as the essential “foundational brick” of every digital initiative.
Therefore, I will walk you through practical “ins” and “outs” of requirement engineering ( all based directly from lessons learned during my career); by showing concrete and actionable solutions that will work directly when using proper process. And you’ll find that it’s far more dynamic and engaging than you might have been led to imagine.
The Starting Point of Clarity: Shifting Perspectives
The very first stage of any project aimed at establishing or changing a system inevitably involves stakeholders that bring varied perspectives. These stakeholders might arrive equipped with well-defined lists of requirements, or they may simply have a broad notion of what they need.
As seasoned business analyst, enterprise architect, or engineer in requirement engineering, it’s our charge to transform these somewhat misty ideas into concrete operational expectations.
A successful project rests on laying clear, solid building blocks from the start – but what happens when those very building blocks change mid-construction?
Deconstructing the Requirement
A requirement is nothing less than a unit describing the behavior of the system we’re about the construct, or upgrade. And by system, I’m obviously referring to every moving part of the machine here. I mean that is a blend of human input, machine outputs via technology, like the hardware itself, software systems, and sometimes specialized machinery. These factors all will work together to ultimately deliver goods or services to the end user, or consumer.
To describe requirement engineering as a step-by-step activity first we start at an “intake workshop” or initial “intake discussion” which we conduct. I always see that as an interactive interview that requires that stakeholders need be ready. They should be ready in bringing elements on the products or services to be offered. It as all interactions the diverse group who will consume the interaction . In addition to how different process are offered and interface used.
Having stakeholders ready at the door is not by chance; clear expectations early define strong and lasting project success further on.
The Two Pillars of Need
From these interactive and in-depth interviews, we usually collect an initial set of business requirements. These encompass high-level organizational objectives — the global perspective from corporate leaders, what that single entity, at a macro level, expects to achieve.
As a concrete example that can also guide your thinking process. A business objective could be in reducing a specific pain by aiming that customer inquiries drop sharply YoY or perhaps aim. It could be also focused at improving service levels by making more efficient exchanges between front line agent and positive 4-star average ratings during 3 consecutive business months.
I am trying to tell you here what the entire business objectives expressed at the corporate level intend to accomplish when significant system refactors go live and are fully online. Remember that very often these type of grand and bold expressions does not precisely detail how results will emerge, I mean, these statements define “the what”— not exactly “the how.”
And naturally as part of our overall journey we also investigate other pillars. We also cover in deep dives, all needs from all of our direct individual stakeholders. Those, when using this framework, will vary as they reflect individual viewpoints of different stakeholders within that entire new process. These are obviously the real system’s daily participants, and they start directly with the very consumer but also encompass a diverse group of customer representatives. To list even further members, those usually also include product managers/owners, compliance officials at back- office positions, salespeople, system’s experts and also administrators of key areas.
So in synthesis, this captures requirements at hand when seen from an enterprise, internal, system users. This gives much clarity as how the system will need to behave from any angle possible to move further efficiently. Those stakeholders, these key needs or statements must absolutely initiate with a dedicated role’s identifier. And always, this unique role should clearly specify who performs which objective. Although a specific name, which does not change, could also fulfil the same need, it is recommend practice when using roles: the user might change over specific time and it also provides the benefit of being universal and interchangeable. We typically associate roles to a purpose describing specific mission with the very scope over our proposed enterprise solution.
For example, it reflects how an consumer should really be welcomed, or given needed support. Or exactly how the user receive help to fulfil exactly their goals and this translates practically in action. To describe it, or express in real business use case – or user stories -, we should use keywords of the quality or standard of must or should; or in an easier more customer oriented or “human readable” tone, the typical statements of want or could according to established principles of practice like the MoSCoW method; with an object that need specific measurable levels of activity, and these could refer typically as timed elements, or even similar dimensions.
These business requirements and user needs represent the yin and yang needed for a robust requirement engineering exercise… that said, how can a single vision encompass different realities without generating chaos.
Going Deeper
Lets get into more details on requirements. You absolutely should be taking specific points, that must always come to your considerations
Requirements fall into multiple forms and shapes with their nuances. There always will be a business requirements. By that I mean statements encompassing the entire purpose and outcome that must result when viewing it at the top- level. Think big picture; This can refer simply to revenue objectives, but also the general and overall improvement measures from new standards of service or level quality. Maybe even, why would need to change your very organization itself in by adding or reducing key employee functions. In short there should aim any time that new risks diminish across the processes with an even greater growth on specific business categories or customer bases.
Then, always, the stakeholder or even more simply stated user needs should always be on the list and it is just stating things from a concrete daily actions and tasks being required from a normal system’s everyday use and daily journey perspective. That means we include the very customer, any internal team like engineers working in service desk, an administrative expert plus relationship executives, a product lead and their team the real IT team covering areas such an compliance or network infrastructure departments. These all have diverse usage patterns with sometimes vastly diverse daily requirements. Now is that time to take advantage from these unique opportunities being offered in a timely process improvement initiative?
Then come the more refined aspects: all the expressions to define in concrete terms how “the system must work”, taking into consideration every angle. Functional statements, as requirement, does not only cover the idealistic perfect “happy situation but it must consider less likely scenarios and “exceptions cases”. All of this done in order of improving the very solution.
Every statement when dealing with functional requirement must systematically bring other additional questions too: functional, but mainly based on current user’s activities. A proper inquiry must target on how needs achieving business results, when looked through different perspectives that translates into real day-to-day steps to complete a goal being stated as core objectives. For instance. If part of a overall user journey, you must translate even complex workflows with concrete statement which translate as practical system behaviors along various user operations.
We need also to dig into another very specific requirement’s families: the less visible aspect, typically associated a system’s framework such compliance standards for performance that express real world hard, strict constraints. Or what we often coin as simply rules defining parameters, including regulatory statements, corporate norms, industry compliance benchmarks, or specific or established operating frameworks.
For example, if specific or even highly strict certification is paramount, for instance ISO norm 2022 or PCI-DSS norm of the international card processing businesses. As one example among many. Those frameworks brings their mandatory strict operating guide. And these will form that bedrock for all further development at all levels— whether a new or evolving application , an improvement to existing processes or system or even novel products, and new ventures, ensuring there exists no discrepancy when considering what must be done. And more, many businesses already have an internal guiding principles whether or not these are formally integrated for instance in a internal enterprise architecture manual. It means we must always check that aspect first- always. This can impact by default and most usually is defined from the outset but in rare events it also will emerge at a late, more mature phase, during one that intake deep dive, during session of brainstorming when the proper inquiry has commenced.
A business or process specialist and also an Architect usually must collect initial set of systemic assumptions and the single best and efficient practical means of doing that properly, starts asking good and pointed specific pertinent questions.
This layered approach to discovering and mapping the technical requirements ensures no stone will be left unturned. Do you wonder how you can reconcile these vastly different perspectives in practical project execution terms?
Let’s address this important question in next episode.