The time has come. Your great idea is about to begin to materialize in a software project. You aim high, so you have experienced team of developers, designers and testers. On the road to success, you will work with them, define your requirements, your vision. I have made a setup of top tips for Product Owners.
How requirements change the code. The insight
Before continuing let’s dive into what programming actually is. It is not any kind of magic or secret knowledge. It is telling a computer what to do. The machine interprets everything and does exactly what the developer tell it to do. It may not sound special but there is an important thing to consider. “Developer tells it to do” means that person who writes code must be very precise and write down every single behavior that is desirable.
Programmers are translating requirements and business needs to code, it is their job. There is a strong connection between business requirements and code in your application. When programmers understand your needs, they can translate that into computer language. Mind that computers do not do things that are not told them, yet sometimes used technology or system may promote some default behaviors.
Expectations vs reality
POs often describe the application by telling some things what they expect it to do, but it’s not enough! What happens when a user misuse application intentionally and unintentionally? Describing both paths (expectations and misusing) is a very important factor before the coding. Another omitted behaviors are related to error handling, since an error is not a thing that we like to present to users, and gets less attention. When describing a new feature think: what if not? What happens when data is unavailable or someone does not provide valid input. It might save you a lot of time, money and improve your application end user experience. Developers tend to resolve unspecified behaviors to the simplest solution. But those may not be obvious from an end user perspective. It is not (always) their fault if there is no requirement you accept any solution, right?
Require a lot, be generic
Considering above we can rig up some improvements to software development and its quality. You need to verbose and write down each thing and behavior you like to have in your application. Mind that requirement is not the exact same thing as a feature. Application features consist of a lot of small behaviors describing every detail of that feature. The more things you require explicitly the better for your project. Do not misunderstand it as requiring more features, it is not the same thing. You need to specify your needs with granularity comfortable for a team to work.
Writing a long list of expected and unwanted behaviors for each feature may be unnecessary too. Think about commonly occurring things and reuse that. Building global requirements valid in most cases and specifying only different ones helps. In a mobile app, you may need all screens to be scrollable if the content is larger than display and be still otherwise. This simple global rule is powerful. You don’t need to think about scroll anymore in each screen description. It will help developers to make things faster. Reusing global requirements have another good effect. They improve application UX by making it more predictable and consistent. Have a list of common solutions for ubiquitous problems. Use that later to speed up writing requirements by selecting from ready solutions. Checklist with common questions you need to ask or answer to is also a good idea.
Talk with developers, often
Making software is a complex topic and doing it right require a lot of time and knowledge. The key solution to that problem is a collaboration between business and developers. When creating a demand you need to consult that with your developers’ team, even if you know technical stuff. Listen to your team and ask them for an opinion. Their job is to help you build a great application, so you should rely on them and talk with them. They will help you to plan and verify requirements to be precise. Please note that recipients of requirements are almost exclusively developers and testers. They need to understand and be comfortable with its contents to be productive. Sharing next plans about a project evolution (if your contract allows you) tell developers what they can expect in future. It will help them design and write application parts to be faster and easier to change.
The summary
Requirements are an important part of a software project. Its quality and completeness impacts quality of software built on top of it. Hard task to get it right, but you have other people in a project that will help you. Business – developers symbiosis and mutual understanding is a key to your application success!
Top AI innovations delivered monthly!
The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest. You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.
