In business analysis, transition requirements define any and all temporary capabilities, conditions, or activities that are necessary for moving solutions out of development and into real-world business use. They do the following:
Describe what has to be done with people, process, and technology before you can get from the as-is into the to-be.
Cover awareness-building, education, and training for the new way employees must work, accounting for, and outlining the differences from before to now.
Define any shifting, movement, enhancement, or change to data and information out of their original structures or locations into their new data homes.
After the solution requirements are understood, a team has enough information to propose the best way for solving a problem, which frequently includes technology. Enter technology requirements.
Technology requirements facilitate communications between the analyst and the technology engineers (system architects, programmers, and designers). In fact, sometimes technology architects or engineers are the analysts for technology requirements.
Whoever writes the technology requirements has to make sure that they describe the specific characteristics of all the data and processes that will be implemented in the solution, including what the data should look like, how the processes should be done, and how the screens should behave.
All the solution requirements previously specified get translated at this level from what the business decides it wants into how the solution will work and be built.
Like stakeholder requirements, technology requirements have two perspectives or contexts: the business context and the solution context.
Technology (technical) requirements for the business analysis solution
From the solution context, technology requirements are also known as technical requirements, and they specify the design and architecture of the specific technical components needed for the solution to be developed, implemented, and operated. They address how the solution will deliver the capabilities, be programmed or coded, and store and display the data.
You shouldn’t create technical requirements until after the stakeholder and solution requirements are understood because which solution option is appropriate fully depends on what capabilities the stakeholders need from the solution.
Not every technical “how” option will provide the same capabilities, so selecting the one that provides the capabilities that are just right for solving the business problem(s) is the key. Those designing technical requirements must balance cool, slick technology against stakeholder and business requirements.
That said, you don’t have to do all the requirements for a solution prior to doing any technical work.
Although teams can choose to define all stakeholder and solution requirements first and then do the functional/nonfunctional and technical requirements (a methodology known as waterfall), they can alternatively work in a more agile or iterative fashion where they take one or a few abstract requirements quickly down to technical detail and then go back and do some more.
Technology requirements for the business analysis solution
Sometimes, technology needs, problems/opportunities, standards, constraints, and requirements begin to take on a level of importance or significance above that of the technical requirements for any one specific solution; at that point, they grow into serving solutions broadly as a category or layer of requirements on their own.
No matter what method you use for development and delivery, technical requirements get defined and implemented in support of many solutions over time in a business, enabling sets of stakeholders and serving many business requirements. As a company implements and grows its technology stack (collection of technology-enabled solutions), technology and even the technology industry begin to have needs as a stakeholder on their own.