How to casually do the required Software Engineering and designing?I am an inexperienced developer and face the following problem:My company is a start up and has no fix Software engineering systems.I am assigned tasks with not very clear and conflicting requirements.I don't have to follow any designs or verify requirements officially.Problem:I code all day and finally get stuck where requirement conflicts and I have to start over again.I can-not spend a lot of time doing proper SRS or SDD.How should I:List out Requirements for myself. (Not an official document)How to verify and validate the requirements?How to visualize them? How to design them with minimum effort? (As its going to be with me only)I don't want to waste my time coding something that's gonna collapse according to requirement conflict or something!I don't want to compromise with quality but don't want to re-write everything on some change that I didn't expected.I imagine making a diagram for my thought process that will show me conflict in the diagram itself, then finally correcting the diagram - I decide my design and structure my code in terms of interfaces or something.And then finally start implementing my design.I am able to sense the lack of systematic approach, but don't know how to proceed!How can I have diagram that I talked about for requirement verification?
Quick and Good: ( Requirement -> Validation -> Design ) for self use?
design;requirements;sdlc
Just because you are working alone doesn't mean you may neglect proper engineering techniques, as you seem to have already experienced for yourself.There is absolutely no way that you can avoid thinking and documenting a proper architecture and design for your components (considering anything but a trivial component). You will have to face changes, your design will have to evolve and you will fail to do so at some point if it only exists somewhere in-between your brain and your code.What I would suggest in your case is a sort of agile approach. You are not required to create documentation of something for the sake of having it document because some process demands it. So instead, concentrate on what is really important to you. Document only, if you think it will make problems later if left undocumented. You also cannot avoid managing your requirements. For this several tools exists and you should use one that allows you to spend the least amount of time to get up and running. Tools will also help you in visualization and verification (test coverage, interdependecies, etc..), but they won't help you in validation. Validation is only possible if you have some kind of customer (who may just be your boss in your case).Finally, the most important point. Your statement I can-not spend a lot of time doing proper SRS or SDD. is a major flaw in your thought process. Think about the time you waste by re-implementing your work. Think about all the problems you encountered that eventually lead to you posting here. Then think again, if you really are unable to spend time on proper engineering techniques. If your boss tells you to not waste time on that, then it's high-time you sit down for a lengthy discussion, because then you are both on a road to nowhere.