TL;DR: You and I can apply principles of requirements engineering to most, if not all everyday problems. I use requirements engineering as a starting point to get me going on topics that are overwhelming. Singling out and focusing on the key points that I need to reach my goal does a lot of the heavy lifting. Once I’m done specifying my requirements, I am already deep in the topic. Plus, I have a checklist against which I can validate my solution.
In this blog post, I dissect my approach to the daunting task of writing a blog post. This one.
I kind of suck at writing blog posts. It’s the “getting started”-part where I have most of my troubles. There are already boundless resources available, and I tend to think that my writing another blog post just adds noise. It reminds me of this XKCD about standards.
But I have yet to find anything that looks at a blog post as a requirement engineering problem.
Why not give it a try? This is what I am familiar with. This is what I am good at. This is my happy place.
I want to have something that I can work towards. I need a goal. One possible goal would be: I want to show people that requirements engineering can be applied to everything.
But this will not do for me. I must put a significant constraint on the goal: I’ll already define part of the solution. Something ideally I would want to postpone — usually, you want to keep your options open.
I want to write a blog post about applying requirements engineering to anything. If I didn’t specify the tool that I’m using, the blog post you are reading might not exist. I might have ended up doing a presentation about it!
Now that I have my goal, my next step in the requirements analysis is to understand the problem. In my scenario this is: How do I get my point across to many people?
My approach is to establish what’s actually important to me, the author. What do I think is relevant in a blog post?
I map things down that define a blog post. I know that I can get lost in detail, so I stick to high-level topics. Let’s say four of them. They don’t need to be perfect. They don’t need to be complete. This is the first draft of an iterative process — things might change. If you prefer to make a list — that’s fine! Use whatever tool best enables you to get stuff done.
The four bubbles that I have put down give me a rough structure that helps me organise my thoughts about writing a blog post. Already I can see that the outcome (my post) will be vastly different depending on the decisions I make about my rough topics. I should spend a little time considering the decisions I have to make about the topics before starting to write.
A quick note: I could have also started from the viewpoint of the reader (yes, you!), my other main stakeholder. You have different priorities than I have. But I know myself better than I know you — so I stick to me. I want to keep the entry barrier for getting started low.
Now it’s brainstorming time. What do I want to focus on to reach my goal? What do I want to pay attention to when writing this blog post? Still, I try to stick to my role as an author (I’ll get to the “why” in the next chapter). I want to make this blog post reflect my own experiences. I want to keep the attention of the reader. I want someone to read this blog post — otherwise, why would I write it?
I’m still not done specifying my problem, and I am still looking at the big picture, but I get a little more specific. I look at my map and populate my topics with decisions that I have to make. They will directly effect my solution to my problem: In which language do I want to write my sentences? Do I prefer long, nested, and complex sentences, or are simple and short sentences more fitting? …
My map is very loosely associated: eg. My target audience affects the reach of my blog article. But it also dictates how I should formulate my sentences. So it could fit both “Reach” and “Sentences”. I pick what makes more sense to me.
Since I am still looking for very high-level inspiration it pays off to do research: What are the qualifiers for a good blog post? Are there best practices? What do blog posts that are well-received look like? Is there anything that stands out in blog posts that I enjoy?
I am wary that, at some point in my preparations, I have to stop. I still want to be efficient in the way I work. Doing a week of requirements engineering for a blog post that takes a day to write doesn’t pay off. So already, I prioritise what I write down. I skip things that I can take for granted, or that would blow things out of proportion. Examples of something that has not made it onto my map are resource planning and using a template.
Most of the ideas that I assigned to my rough topics are also relevant to the reader. The concept that the producer’s goals overlap the customer’s needs holds true for most products [citation needed]. If I want to create a product, I better make sure my customers actually want it. And while the producer often has considerations that are of no interest to the customer, the opposite is also true. A producer may care about production cost, time to write a blog post, or reach. A customer may care about less tangible things.
So I take off my “producer”-hat and put on my “customer”-hat. All of a sudden, the world looks different! As a reader I like images. I want to see the reading time before I dive into an article. I really care about writing style.
There’s different ways to estimate customer wants. There are two main approaches: data driven or by imagination. To keep it simple, I am sticking to my imagination. In my map, I’ve only added the topic of images. I want to keep my example manageable!
The framework that I have established in my map is universal to writing all blogs. Now comes the time to make decisions to make it my own! This could be done by someone else — a product manager, for instance — or myself.
I take the decisions that I’ve made to draft requirements. There is already a lot of information available about best practices for writing requirements, so I will leave out the details.
Keep in mind that requirements are a means to reach a goal. The requirements are not my goal! Half the fun is that I can and will explore new perspectives during their specification. Do I cover all cases? Is there a way to misinterpret the requirement? I already want to think about how I can verify my requirements. If this blog was about product development, I’d think about breaking stuff (the “unhappy path”). But breaking text in a blog is really
hą̷̫̺̱̟͚͎̘̖̯͉̝̏͒͛̃̿̈̀r̸̨̢̡̼̟̜̥̣̬̮̝͚͇̜̪̝̈́̎͒̈̑̓̃̄̄̊͆͆̈̓̃̽d̶̢̗̦̮̜̩̹͖̣̲͈͙̹̈͒́̏̇̓̾́
These are my requirements:
An often overlooked part of requirements engineering is the peer review. Get yourself another set of eyes. I prefer to select people familiar with requirements engineering but not the specific topic of the problem. I am familiar with the topic of the project. Therefore, I am bad at judging if my writing is easily understood. This is where outside help comes into play.
I also want someone who can challenge my requirements. Someone who knows the best practices of writing requirements. Both of these preconditions are true for my colleague Elias. So, since he will be reading this: Hi Elias!
Elias, being very diligent, had remarks on most of my requirements. Most of them are not easily verifiable. After leaving his comments, Elias also saw that most of his observations had already been addressed in the next chapter. I could have written my requirements to be verifiable from the get-go. But we’re here to learn! Still, he gave me some valuable pointers — not only regarding requirements but also to the structure of the blog post. Thanks Elias!
I now have a list of requirements. Thanks to the review I know most of them are not easily verifiable. If I want to correct them, I need to do research on attainable goals. Luckily, for blogs, this is EASY! There are plenty of blog posts around on how to write a blog post.
If you have a sparring partner for your requirements, involve them! Make sure that they challenge your requirements before you finalise them. Depending on the project, changing requirements can be a very involved process that incurs a lot of overhead. In general — the earlier an error in a process is found, the less time it takes to correct it.
My requirements are finalised and reviewed. They can now be used for the product’s implementation and testing.
Implementation done! This usually takes a little bit longer, but mostly, products are not as self-referential as this blog post. Now comes the time to verify that the requirements have been fulfilled. When the required data is provided, the verification can be done by anyone. In this case, it’s done by me.
There are a lot of ways to approach requirements engineering. None of them is perfect [once again, citation needed]. When approaching problems, I always try to keep my mind open. I might try making lists. I might try making diagrams. I may dive into a case study.
Regardless of my tools and approach, looking at a problem’s requirements always helps me break it into manageable chunks. Needless to say (I hope), this is not a guide. Your mind almost certainly works differently from mine. This blog post is just a perspective on problem-solving. If it can help you in tackling a single complex problem, it’s a win for both of us!
Still, I can give you a couple pointers on what helps you get requirements right:
Do you have a better approach? Do you wildly disagree with my methods? Has this blog post actually helped you approach a problem? I’d love to hear about your thoughts and questions! You can mail me at florian.heinisch@andamp.io
We at & are always eager to learn about new ways to approach complex problems. We don’t believe that there is a singular right way to do things and always try to get a fresh, new angle on a problem. If you need assistance from our requirements experts or want to tackle a problem with us, get in touch!