Nov 12, 2021
Good architecture depends on good requirements.
Today we'll talk about requirements. Many developers, especially Junior, don't understand the task's criteria and are afraid to ask questions. They think they don't yet have the experience of impacting a feature. They believe their questions will be stupid, so they avoid being active in the preparation of criteria. It's a wrong assumption. Keep in mind that if you get troubled by the requirements, the user/business could be too. And you could be Junior, Medior, Senior, or Lead. It will change anything. Communication is the key in requirements, and status would not change anything to it. Questions lead to good requirements.
Bad requirements lead to:
- Bad communication
- Vision uncommon for everyone
- Wrong design/architecture
- Hard to develop
- Not understanding the needs of the business
- Not understanding the impact on the user
- Lack of discipline
- Developing the wrong feature
Good requirements lead to:
- Good communication
- Vision common for everyone
- Good design/architecture
- Easy to develop
Who's to blame?
No one is to blame. It's a lack of communication. By being afraid to ask questions or develop the feature quickly, we can miss important things, whether for the user (forget to display a loader during an API request) or for the business (forget to add an important event). By asking questions, we improve requirements. As a developer, it's our job to help the business to understand the technical challenges.
As a developer, we all face this kind of requirements (FizzBuzz example):
# Story
As a user
I want to enter a number
So I know if my number is Fizz, Buzz or FizzBuzz- What happens if the user enters a string?
- What happens if the user enters nothing and tries to display a result?
- What happens if the user enters a calculation?
As we can see, it looks easy at first, but without questions, we can miss many paths the user can create and not manage by our system.
Behavior Driven Development (BDD)
# Feature FizzBuzzNarrative #1:
As a user
I want to know if my number is a FizzBuzz
So I can verify the resultScenarios (Acceptence criteria)Scenario #1
Given the user enter a number
When the user enters a number divisible by 3
Then the system should display FizzScenario #2
Given the user enter a number
When the user enters a number divisible by 5
Then the system should display BuzzScenario #3
Given the user enter a number
When the user enters a number divisible by 3 and 5
Then the system should display FizzBuzzScenario #4
Given the user enter a number
When the user enters the number 2
Then the system should display an error messageNarrative #2:
As a user
I want to know if my string is a FizzBuzz
So I can verify the resultScenarios (Acceptence criteria)Scenario #1
Given the user enter a string
When the user enters "Hello world"
Then the system should display an error messageNarrative #3:
As a user
I want to know if my calculation is a FizzBuzz
So I can verify the resultScenarios (Acceptence criteria) | Not supported yetScenario #1
Given the user enter a calculation
When the user enters 123*456
Then the system should display an error message
Use Cases (Ivar Jacobson)
FizzBuzzData:
- User valuePrimary course (happy path)
1. User enters a number
2. System validate number
3. System delivers resultValue not a number - error course (sad path):
1. System delivers not number errorUser enters empty value - error course (sad path):
1. System delivers empty value errorUser enters calculation - error course (sad path):
1. System delivers not supported error
Here, we have improved the requirements with questions, and the feature makes sense for the business and developers.
Behavior Driven Development and Use Cases can help to create requirements. Furthermore, it will enable developers to develop features, and they have a better known of it and have a better vision of the system. With these steps, we can create a diagram easily and start developing the features. One colleague can work on the FizzBuzz system when another can design and develop the UI.
Here is a small diagram to start developing the feature. It looks simple, but as we develop the system, the diagram will become more complex. We have to start with small steps and improve and iterate on it. Like adding a Presenter for presenting the result to the user without damage or touching our VC or Use Case (Open/Close principles). As developers, we have to choose our system/architecture and which components we have to create to iterate and improve our system quickly without pain.
The reality is, I’m an idiot. I don’t understand very complicated things and so I ask a lot of questions so the person whose telling something complacted whose talking in term I don’t understand them. Finance or neurosicence I don’t know what you’re talking about. And I ask enough questions just to understand it.
Simon Sinek
Resources:
Essential Developer
Martin Fowler (BDD)
Use Cases (Ivar Jacobson)
https://www.researchgate.net/publication/301704896_Use-case_20
Simon Sinek (Be the idiot):
