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

Good requirements lead to:

  • Good communication

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?

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 result
Scenarios (Acceptence criteria)Scenario #1
Given the user enter a number
When the user enters a number divisible by 3
Then the system should display Fizz
Scenario #2
Given the user enter a number
When the user enters a number divisible by 5
Then the system should display Buzz
Scenario #3
Given the user enter a number
When the user enters a number divisible by 3 and 5
Then the system should display FizzBuzz
Scenario #4
Given the user enter a number
When the user enters the number 2
Then the system should display an error message
Narrative #2:
As a user
I want to know if my string is a FizzBuzz
So I can verify the result
Scenarios (Acceptence criteria)Scenario #1
Given the user enter a string
When the user enters "Hello world"
Then the system should display an error message
Narrative #3:
As a user
I want to know if my calculation is a FizzBuzz
So I can verify the result
Scenarios (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 value
Primary course (happy path)
1. User enters a number
2. System validate number
3. System delivers result
Value not a number - error course (sad path):
1. System delivers not number error
User enters empty value - error course (sad path):
1. System delivers empty value error
User 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):

https://www.youtube.com/watch?v=BkLzo_oNVho

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christophe Bugnon

As a passionate iOS software developer, I love to share my knowledge and learn new ones. Also, I like to talk about software development in general.