Dig for the Information You Need
Architecturally significant requirements are hidden all around us. You’ll find ASRs in user stories, implied by a manager’s request, and hinted by stakeholders who know what they want but don’t quite know how to explain it.
The product backlog contains a treasure trove of ASRs. Quality attributes are implied or assumed in nearly every functional requirement. Sometimes a user story will plainly describe response times, scalability needs, or how to handle failures. Highlight these details as quality attribute scenarios lest they get lost in the feature backlog.
Talk to stakeholders. Find out what worries them. Ask stakeholders what excites them. Share the risks and open questions you see. Here are some additional methods you can use to dig out interesting ASRs:
-
Use Activity 3, Goal-Question-Metric (GQM) Workshop to connect business goals and quality attribute response measures with concrete data requirements.
-
Use Activity 4, Interview Stakeholders to uncover quality attribute scenarios and constraints. Interviews work especially well with technical stakeholders.
-
Use Activity 5, List Assumptions to flush hidden requirements into the open.
-
Use Activity 7, Mini-Quality Attribute Workshop to quickly and effectively define high-priority quality attribute scenarios. This workshop works for nearly any kind of project and with stakeholders of different skills and backgrounds.
-
Use Activity 24, Inception Deck as a checklist for kicking off a new project. Architecture is the main topic for several slides in the inception deck.
by Thijmen de Gooijer, IT Architect
Understanding your stakeholders and their goals is the first step to successfully delivering value with software. Taking someone else’s perspective and showing empathy will help you understand their expectations of your software. Technical training and experience then turn requirements into implementable ideas. However, you will need excellent communication skills to get developers and management to share your vision and turn ideas into code.
One of the most useful communication skills I had to learn is active listening. Hearing what someone says is only the first step. You also have to understand it. Here is a surprisingly challenging exercise that I learned during a course on communication. You can try this exercise with a partner.
Person A tells a story to person B, for example about an achievement or describing a problem they solved. The trick is that person B is not allowed to say a word until person A indicates they are finished. Only then is person B allowed to ask questions to increase understanding of what person A said. The questions cannot be covert feedback or critique. Person B’s goal is to reach an understanding. Now reverse roles to experience the other side of the relationship.
Imagine how hard this exercise can be! You probably know a colleague who talks a little bit too much or a shy and quiet intern. How would you ensure that you understand their requirements?
Writing down directly what a stakeholder tells you probably won’t lead to an implementable requirement. Human language is messy, complicated, and full of culturally loaded messages—nothing like COBOL, Java, PHP, or Python. Culture does not only differ between countries or religions. Cities, companies, schools, and sports clubs have cultures, which influence how people communicate.
As an active listener, you need empathy to put words into their cultural context and understand them. Remain quiet, don’t judge, and ask questions to help you understand.
Communication skills are hard to learn from books, yet I recommend two to assist you on your way to becoming an amazing software architect. How to Win Friends and Influence People [Car09] by Dale Carnegie is a classic book that gives actionable guidance on how to build better relationships with people. In Culture Clash 2: Managing the Global High Performance Team [Zwe13] Thomas D. Zweifel provides an easy-to-understand framework for identifying and overcoming cultural differences.