I wanted to highlight in this post how important the prerequisites are before a developer can start writing code.
Recently I lived an experience with a module that I developed, where I suffered from the changes in the requirements that came across the development process and also after the release. The requirements are not yet clear and that module is a becoming a real nightmare especially for me. It is very stressful.
I can now do a flashback and I can say that from the beginning we didn’t pay lot of attention to the complexity and the importance of that module. And from here I felt the importance of prerequisites in building softwares.
I am sure that all that stress could be avoided from the beginning if I would have proceeded differently.
I would not hurry to write code until I have the necessary ingredients to build my code. Usually developers cannot resist the desire to write code as soon as possible, once they have a nice looking user story. And they’re not aware that this user story can easily transform to a horrible nightmare if they don’t do elementary steps before writing their code (Or probably some consultants are aware and want to bill more!). Developers have to resist that temptation and focus on preparation. Good preparation before jumping into coding is a skill that professional programmers should have, but unfortunately it is not always the case! Even some team leaders do not have that skill and fall in this trap. We probably they have the skill, but they do not use it !
If the developer do not do a good preparation then he will reply on intuitive requirements while developing, and probably would not do the best choice.
In some companies, we do not accept to spend much time on preparing prerequisites. And sometimes the developer feels embarrassed that he didn’t start programming right away. You should try to change this mentality. Try to write your prerequisites documents and make it approved by the managers or the team lead. Share it with the functional analysts or business analysts. Share your architectural analysis with architects! Try to contact the client directly to make it more formal and take the lead over your functional analyst 🙂
First of all to do prerequisites, we should have a business case. Having the overview picture of the user story, clear description about the problem we’re going to solve. We usually call that “Problem definition”. So try to apply the rule of problem definition for each user story !
A tip is to read all the specification even if it is too long! You’ll avoid then lot of issues, you would tell yourself I will start coding and then I will tackle the rest afterwards. This is a very bad habit.
Requirements for requirements:
There are 3 kind of requirements that you should handle before getting started in writing your code
- Functional requirements, including wireframes and screen flow.
- Non functional requirements (quality requirements) which is most of the time neglected!
- Architectural requirements, technical requirements.
I will detail the first 2 kind of requirements, and let the architectural requirements to another post, since I will go more in details about it.
We can use a checklist to make sure those requirements are good enough to start. Using this checklist is absolutely worth at this stage and we can get back to it even on the way and with change requests!
- All the inputs of the system are specified in details.
- All the outputs as well.
- All the external communications are specified in details like the handshake, protocols, exceptions and errors, security. We can rely on SOA guidelines for that for instance.
- All the tasks the user want to do are specified.
- All kind data used to produce output are specified in addition to the input mentioned in the first place.
Non functional requirements
- The expected response time specified.
- The level of security specified.
- The level of reliability specified, we should specify the consequences of an exception and how to protect sensitive or important data and transactional operations and specify the strategy of error detection and recovery.
- Hardware requirement if applicable.
- Maintainability requirements, and if the system has to adapt for likely future changes.
- The requirements should not conflict with other requirements.
- The requirements should have a fairly level of completeness. Probably we should add details, probably we should detail less.
- The requirements shoould be testable, and the test procedure should be specified. This is tricky especially if you’re using backend services! Means that the control of the situation is not easily in your hands.
- The requirements should specify if the requirements items are likely to be changed.
- The requirements should specify where are the areas of incompleteness!
Don’t neglect the estimation
Some companies do not pay attention to the importance of requirements, either with new development or with change requests.
As a professional developer, when you receive a request from business or management, you should insist on 2 words which are “planning” and “costs”. And you should point that giving value to the requirements would be much cheaper if considered before starting construction.
Formal change request
It is ok if your client change his mind. But if it he will keep like that and you will accept easily his requests, and the requests of your functional analyst, it will never end up.
So try to make a formal change request. Review it together with stakeholders. So it won’t change often, and at the end the client will be happy because he will know more about what he want and also his need will be handled on time.
Look for something else
If the subject is complex, and the requirements are far from clear, then you can think about dumping it. Think about it loudly ! It can help. Or probably give it to someone else who can be more enthusiastic about it !
You can also have a different attitude: You are aware that the requirements are volatile and bad. But you’re willing to do the functional analysis job on behalf of the functional analyst. So then you have a challenge. Carry on!
Developers try to use the intuitive requirements technique. We can add the business case and then it will be a wonderful combination. Many requirements issues will disappear when we go back to the business case, and when we think why we needed this development at the first place and what was the problem. And that would save a lot of time, and lot of energy.— July 14, 2016