This is the second post in my Socio-Technical Engineering series. As I concluded in the first part, socio-technical systems, such as software projects, are actual systems. And systems are subject to engineering, which usually begins with eliciting requirements. The first post provided insights into the sources of complexity in socio-technical systems. These insights are not only necessary for a better understanding of the system dynamics but also for better navigating the possible requirements domains. This second post is about requirements engineering for socio-technical systems.
Requirements for Socio-Technical Systems
When engineers build or extend a system, they strive to understand the functional and non-functional requirements that the system is expected to fulfill. They don't have to gather all requirements before designing a solution, but they need a rough understanding of what needs to be created and under which conditions. Functional requirements answer the question of what the system should do, while non-functional requirements specify how and under which conditions the system should function.
Functional requirements
In the case of socio-technical systems, functional requirements are relatively straightforward. For example: "Our organization should create product X by project Y." The scope of product X will be refined over time. Nevertheless, this requirement already reveals a lot of information for the future design phase:
Project Y is supposed to build product X, not another product, not two products simultaneously, and not a common platform for building similar products unless specified otherwise.
Whatever product X is, it will come with a set of numerous artifacts to be created: project documentation, software, a list of system requirements, test cases, user manuals, risk management documentation, and dozens of other artifacts. The list of artifacts is unique to every single project. Knowing this list is as essential as knowing the list of ingredients for a cooking recipe.
Project Y owns the development of product X. It is not another department or a third-party organization. The accountability for the results lies within the project, not outside of it.
Here are other examples of functional requirements for socio-technical systems:
"We want our organization to undergo agile/digital/climate-awareness transformation."
"We want our team to create a shared software platform that enables the development of a product portfolio by other teams."
"We want our organization to cut operational/infrastructure/personnel costs by 40%."
"We want to create a business model allowing our organization to expand and scale in global markets."
Note: Business models, customer value propositions, business strategies, etc., are artifacts. Any system where people and artifacts are interconnected and intertwined is an example of a socio-technical system. Creating and implementing a business model qualify as (re-)engineering of a socio-technical system.
Non-functional requirements
Non-functional requirements specify how and under which conditions the system should function. Every non-functional requirement refers to a functional one. Often undervalued, non-functional requirements usually play a greater role in system architecture than functional requirements. In technical systems, neglecting non-functional requirements like performance, security, or safety can lead to significant troubles for the project team, as they may require extensive system redesign in later stages. Understanding the non-functional requirements is crucial for a project's success. Fortunately, one can borrow typical categories of non-functional requirements from software engineering and reinterpret them for socio-technical systems. Here are some examples:
Development Reliability: "We want to be able to make any project decision without depending on a single person."
For instance, the statement "We can't make that decision until our project lead or lead architect returns from vacation." is a perfect example of this reliability requirement not being met. As you will see also in the following examples, requirements don't come for free. While this requirement may sound appealing and make intuitive sense, satisfying this non-functional requirement will certainly impact the structure of the project organization, roles, and responsibilities. It is important to be aware of this. I will elaborate more on this problem in the next post on Design for socio-technical systems.
Development Scalability: "We want to increase the productivity of the development organization by hiring more staff."
This requirement may seem obvious, but in reality, the opposite often occurs. When new people join a team, productivity may decline due to communication overhead and lack of communication at the same time. Both of these issues stem from a technical architecture that is unprepared for such organizational decisions. It's important to note that no architecture is inherently good or bad. If a small co-located team begins developing a system, they choose an architecture that suits their needs. However, if the team is expected to grow threefold, the existing architecture may no longer be the best choice. Preparation is needed not only in the technical architecture but also in the social architecture, including the structure of the development organization and project roles. These aspects will be covered in the next post on Design. The main point here is that discussions about technical and social architecture should be guided by requirements, just as a car navigator is guided by the target address.
Book hint: The book “Team Topologies” provides an excellent body of knowledge on how to carve teams in harmony with technical artifacts.
Development Distributability: "We want to be able to develop the product through distributed teams."
Similar to development scalability, distributability requires preparedness in both technical and social architecture. It's better to address these considerations early on rather than later.
Developers' Satisfaction: "We want our engineers to be motivated and fulfilled while working on the product."
Ensuring satisfaction is important to avoid accumulating People Debt. Dissatisfied individuals can disrupt organizational culture, underperform, or leave, and the costs associated with these outcomes outweigh any potential benefits. Psychology, neurophysiology, anthropology, and organizational science provide valuable insights in creating satisfying socio-technical environments, such as software projects. I will explore the application of their recommendations in future articles. For now, let's consider these recommendations as "implementation details."
Financial/Time Constraints: "Our budget is €2,000,000, and the time to market is 3 years."
This type of requirement is present in almost every project. Project uncertainties are usually high. In the best-case scenario, the project management would create a plan that allocates half the time and money and keeps the other half as a buffer. The plan would likely include the necessary staff and an approximate implementation roadmap. However, such plans often lack guidance for technical decisions. Short timelines might require lean solutions that are not easily maintainable in the long run, while longer timelines suggest the need for solid system decomposition and a development infrastructure that supports extensibility. Achieving the latter scenario is extremely challenging due to operational and political complexities, as mentioned in the previous post. Usually, there is significant pressure to deliver tangible results early in the project, which can lead the team to focus on getting something functional quickly while neglecting investments in long-term capabilities. Requirements like this one are crucial for enabling Product Owners to make transparent prioritization decisions and convey their opinions to project stakeholders.
Organizational Constraints: "We must cooperate with an internal team from another department that provides a shared platform. However, the team is known for being unreliable, and their Product Owner demands additional funds for every minor change we request."
Despite having organizational origins, this requirement has technical consequences. First, it requires upfront analysis to avoid costly communication and change requests to the other department. Upfront analysis may slow down agility in certain areas, and it's important to understand where and how. Second, any deliverables from the other team should be abstracted as much as possible, using techniques like mocking, simulation, and code generation. Incorporating this into the technical architecture requires planning and effort.
Portability: "We want to be able to switch service providers quickly to avoid lock-in."
In technical systems, portability refers to the ability to migrate the system from one platform (e.g., Windows, AWS) to another (e.g., Linux, MS Azure). Tailoring a system to a specific platform has its benefits but can also introduce inflexibility. Avoiding dependency on a particular service provider requires support from both social and technical architectures. However, discussing the treatment of this topic goes beyond the scope of this article. If you're interested in learning more about avoiding socio-technical dependencies on external providers or internal "superstars," feel free to contact me.
Regulatory Constraints: "Our development process must comply with ISO 62304 and have specific design, development, and verification/validation phases."
Regulatory constraints kill the fun. Instead of developing fantastic products with modern technologies, engineers must deal with aspects of compliance with safety and security requirements. The social aspect of regulatory compliance is that engineers need not only the right experience but also the right mindset. From a technical perspective, upfront architecture work, especially focusing on safety, becomes crucial. Paying attention to regulatory implications when making social and technical decisions helps avoid friction and surprises during the project.
Conclusion
Socio-technical systems are, indeed, systems, and their (re-)engineering begins with requirements elicitation. Like other systems, socio-technical systems are subject to functional and non-functional requirements. This post provided several examples from different requirement categories for real-life software projects. The specific list of requirements will vary for each socio-technical system, depending on the project or organization. However, requirements are crucial for facilitating transparent decision-making and evaluating solutions through verification. The next post in the series will delve into the next step of systems engineering: design. Stay tuned for more.
P.S. Interested in a workshop on requirements elicitation and design for your organization or project? Just contact me and unleash the full power of socio-technical engineering.
Comments