I am not a requirement engineer and do not write software requirements on daily basis. This story is written in software developers perspective.
Software requirements are the basis of all proper development work. You need them if you want to succeed. Unfortunately most of the requirements out there are incomplete or written, if at all, very badly leaving too many open questions for the developer actually doing the design and implementation. That is why every project should have good requirements that tell exactly what needs to implemented not forgetting error situations.
Software requirements are written text describing capabilities, functions and constraints of the software project. Requirements should contain information how the software will work and interact with the user and especially what problems does the software solve. Writing good software requirements is not an easy task and requires huge amount of training to master.
User stories are used to define the software on very coarse level. Mostly I’ve seen them written in format: As a [type of user], I want [some goal] so that [some reason]. This is, in my opinion, a good way to write user stories. Still one should not mix this with software requirements. Requirements are products that are based on user stories. Most likely a single user story will, and should be, split into multiple requirements.
The requirements should always be written in language that everyone, already in the project, or joining later on, can understand. Even your company is located in, let’s say Norway, you cannot be sure if the next hire will be a foreigner or the whole development is outsourced to some other country. Having your specifications, requirements and other information in Norwegian at that point will either require the new hire to learn a new language or all the documents needs to be translated in another language. Anyways it will mean a lot of work for someone.
I’ve seen this happen in many projects. Most of the time the documents were just translated to English. This might work but there can be hiccups there as all languages do not work the same and cannot be translated from word to word. Think about using a translated requirements document as source for your implementation. What if the translation is wrong? Who will get the blame of implementing things against the requirements — is it you, the translator or someone else? That is why in general you should use English in all specification and requirements work.
Software requirements should be self-explanatory and easily understandable. In my opinion a good way to start creating requirements is to think what it MUST do, what it SHOULD do and what it CAN do. Using just one of these words in your requirement can make a lot of difference in the final outcome. The MUST requirements are defining behavior, functionality or expected outcome that has to be implemented such as “The server must respond in less than 50ms”. The SHOULD requirements are describing the same thing except that there can be preconditions for the fulfillment of the requirement such as “The server should respond in no less than 50ms if all the server nodes are up”. The CAN requirements are optional requirements that can be fulfilled if they are not blocked by any other functionality or requirement.
There are multiple types of software requirements. While most of the requirements are so called “functional requirements” that define specific behavior or functionality, you should never forget to also write down “non-functional requirements” for the software. These requirements define criterion that can be used to judge the operation of a system. Example of non-functional requirement for web application could be “The login page must respond in no less than 50ms”.
Readability is also one important thing in the software requirements and you should pay close attention to the formatting of the requirements document. Bad formatting is off-putting and makes it hard to concentrate on the content. You should always test the readability of the document before publishing it.
You should also think about the target audience of your requirements. They are not only used by the software architects and engineers but also test engineers and project management. With good requirements it’s easier to plan and execute tests as well as plan the whole project’s timeline.
Let’s imagine you are working for ACME Ltd. as a only developer for a new project to create a babysitter robot. The company’s robotics team has put up a demonstrator robot which can be used for testing the software. At this point you don’t have to think how the robot will be configured (how many kids, where do they sleep, if they use diaper etc.) or how the robot can understand what the kids say. As a developer you get the following requirements:
As you can see, these requirements are not self-explanatory. What if the startup fails? What button should the parent press? When does the robot know when a kid is hungry or diaper is full? Are there any prioritization between the tasks? How does the robot know if parents are home? Can the robot stop an ongoing task to go recharge itself? These are only few questions that arise from these requirements.
Now let’s think again how we could improve and extend these requirements:
These requirements are still not complete and are missing information but at least I would have some idea how to start working with the software design based on these.
Requirements hardly ever hit the goal with their first version. It’s very important to also spend time to refine and fine down the requirements while the development is ongoing. Development might find some deviations which might cause a change to the original requirement. Deviation can be for example if the robot in the previous chapter fails the self-test it only peeps twice because programming language used only allows calling same function twice. This kind of, while absurd, limitation should be either documented to the customer or the original requirement needs to be changed depending who is requesting this feature.
If the original requirements leave too many open questions, the refinement process can be very exhausting and time consuming. When writing software requirements try to come up as good first version as possible — in the long run it will save time from you and from the whole development team.
Here are some good books that you might want to read if you are working with software requirements:
I am Heikki Hellgren, Software Expert and technology enthusiast working at Elektrobit Automotive. My interests are in software construction, tools, automatic testing and all the new and cool stuff like AI and autonomous driving. You can follow me on Medium and Twitter. Also you can check out my website for more information.
Create your free account to unlock your custom reading experience.