The software engineer’s job is to code only, isn’t it? Well, no. At least not now, when we are working on complex enterprise solutions and have to tackle many aspects. Without going into details, software requirements can be divided into:
- Product and process requirements
- Functional and non-functional requirements
- System requirements and software requirements
- Emergent properties
- Quantifiable requirements
All in all, there are many requirements even for the simplest app. Needless to mention enterprise-level solutions. The reason is that every solution, every product is used by a number of users, a business, and on many devices. So, it is used in a plethora of different ways. Do you see the point? The requirements to a specific software are dictated by different people within the business, end-users, and the environment in which the solution will be used. So, we perform real research to collect the requirements for every project.
How do we collect software requirements
How do we at Mad Devs collect the software requirements? We do it for every project. The process starts with the project initiation and goes through the entire software development cycle. Requirements are determined by:
Business/Stakeholders - they are responsible for accepting and executing the software. It can be an individual, a company, a group of companies, or even a government.
Users - they will operate or use the software. Usually, users comprise a heterogenous group that consists of people of different ages, of different backgrounds, etc.
Customers - they represent the target market of the software. They might be responsible for the software commissioning, too.
Market analysts - people who might not use the product later but need to find out what the market needs. So, they will have to act at some time as users.
Regulators - many domains are regulated. Those are banking specifically and finances in general, medicine, public transportation, and many more. Compliance with regulatory requirements is a must for any software product that will be applied in these domains.
Software engineers - these people find the right balance between all the above-mentioned groups to develop and develop a product that complies with the needed requirements without damaging the product’s functionality.
It is impossible to satisfy the needs and requirements of every participant in the process. So, software engineers need to negotiate tradeoffs and still keep the process within the technical, budgetary, regulatory, and whatever else constraints. Here, their communication skills come in handy.
While we don’t under-assess the roles of all stakeholders, we would like to mention that the role of a software engineer is the most complicated and demanding one. Software engineers build a bridge between the requirements provided by different stakeholders. And they are responsible for the proper operation of the bridge they have built.
Is there a system to manage software requirements?
You might be wondering what management system can help you to handle the software requirements efficiently. It must be something incredibly complex. Or well-structured. Or whatever…
Well, there is no efficient management system that would work for this purpose. We at Mad Devs collect software requirements for every project, based on its requirements and constraints that might be imposed by, say, legal requirements and norms, or whatever.
Projects are too different. Requirements to them differ immensely depending on the target audience, application field, and… well, above, there are all the project participants listed and explained. While we can reuse already available information for, say, similar projects, we do not have a specific management system to handle this process. Every time, the process is too unique and requires different approaches.
Some companies hire requirements engineers to manage the process of requirements collection. In our company though, every software engineer knows how to handle the matter of software requirements in a way to meet customer expectations and deliver safe and reliable solutions that operate absolutely legally.
We collect requirements in multiple ways
It looks like the process of requirements collection is very complex. And it is, indeed! Requirements are collected from many sources. So, what about having a look at them?
Project goals
It is an overall objective of the product. It replies to the question “what is the product developed for?” Software engineers need to assess the value and cost of each goal. If we see that some goals don’t have a real value but increase the product cost significantly, we talk to the customer to explain the situation and find the most optimal solution.
Domain knowledge
A software engineer has to acquire the needed knowledge about the domain for which the product is going to be developed. Domain requirements are the background against which other requirements shall be set.
Stakeholders
There are so many cases when a product failed because the interests of one stakeholders’ group were prioritized while other stakeholders’ interests were neglected. Such an approach results in difficulties with the software use, or it can even go against some cultural or political structures of the customer organization. It is difficult to tell what is worse because both factors lead to product failure. So, all stakeholders’ requirements and views shall be considered.
Business rules
These are rules based on which a business functions. Some business constraints connected with the way the business can operate might impose some restrictions on its software, too. So, we need to be aware of such constraints. And it is better when a software engineer doesn’t rely merely on the words of business owners but researches independently to make sure all requirements are met.
The operational environment
Requirements depend heavily on the environment in which the software will operate. Examples of such requirements might be, for example, timing-related for products that work in real-time mode, performance for products operating in a business environment, and similar.
These requirements shall be researched very carefully. They can influence product functionality and development costs.
The organizational environment
Software is developed to support business processes. Their selection is determined by the company’s structure, culture, and internal politics. Software engineers shall understand it clearly so that the new software product doesn’t impact the business processes and doesn’t cause their unplanned changes.
Requirements analysis
Once the requirements are collected, we analyze them. As you could see, there are too many participants and circumstances to consider. Therefore, all the collected information requires a detailed analysis.
We determine whether there are conflicting requirements. If there are, we check the options to solve the conflicts and prioritize the requirements in a correct way. So, legal requirements will be prioritized if we need to select between them and the requirements provided by a business owner, for example. We do our best to explain why some features or functionalities cannot be implemented and look for the optimal solutions together with our customers.
We check how software shall interact with the organizational and operational environment and discover bonds between different requirements. Finally, we develop a set of requirements the software shall comply with. Once the requirements are determined, we confirm them with stakeholders and build software based on them.
Improve Team Productivity: 4 Steps to Avoid Micro...
Improve Team Productivity: 4 Steps to...
Improve Team Productivity: 4 Steps to Avoid Micro Context
Initially, I learned the "micro context" term from one excellent scrum master. I thought I understood what the word meant, but when I googled it, I...
