Business requirements done right. Tips for Product Owners

24 Jul 2018 | 5 min read
Business Requirements for Software Development Projects

The time has come. Your great idea is about to begin to materialise 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 behaviour 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 behaviours.

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 behaviours 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 behaviours 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 the above we can rig up some improvements to software development and its quality.  You need to verbose and write down each thing and behaviour 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 behaviours 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 behaviours 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 scrolling 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. A 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!

We will develop a successful digital product for your business!

The controller of your personal data is Miquido sp. z ograniczoną odpowiedzialnością sp.k. with its registered office in Krakow, ul. Zabłocie 43a, 30-701 Kraków. We process the above information in order to answer your questions, contact you and conduct business communication, and if you tick the checkbox, to send you messages containing commercial, business and marketing materials.
The basis for the processing of your data is Miquido's legitimate interest - informing customers about news and changes to our offer as well as providing information about products that may be useful in their business. You can unsubscribe from the marketing communications at any time. You also have the right to access data, the right to request rectification, deletion or limitation of their processing, data transfer, the right to object, as well as the right to lodge a complaint to the supervisory body. Full information about processing of personal data can be found in the Privacy Policy.

Show more