How to casually do the required Software Engineering and designing?

I am an inexperienced developer and face the following problem:

  1. My company is a start up and has no fix Software engineering systems.
  2. I am assigned tasks with not very clear and conflicting requirements.
  3. I don't have to follow any designs or verify requirements officially.


  1. I code all day and finally get stuck where requirement conflicts and I have to start over again.
  2. I can-not spend a lot of time doing proper SRS or SDD.

How should I:

  1. List out Requirements for myself. (Not an official document)
  2. How to verify and validate the requirements?
  3. How to visualize them?
  4. 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?


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.

| improve this answer | |
  • 1
    Please suggest some tools for requirement verification. Suggest article on walk-through on how to start designing, I don't have any experience of UML or something similar. – Yugal Jindle Nov 17 '11 at 7:47
  • I don't mind spending time on design till the time they are helpful and not just a document. – Yugal Jindle Nov 17 '11 at 7:48
  • I am looking for tools that could ask me things that I am not able to aggregate otherwise. – Yugal Jindle Nov 17 '11 at 7:49

There is always a typical conflict to be balanced when it comes to effort an approaches to documentation. And i would quote your words to say where it is -

I can-not spend a lot of time doing proper SRS or SDD.


I don't want to waste my time coding something that's gonna collapse according to requirement conflict or something !!

This is a common pattern that almost all people face. And when you remove the criteria that there are no other people to share this with, it becomes even more inevitable that we dont go towards documentation. But you have put a light of the question in good spirit - "how to do documentation" than "whether to do documentation"

The point i wanted to make is essentially of balance -between effort and clarity. The simpler approaches might just help.

  1. avoid needless formalism - that makes many people go faster. It's not that typing makes it slow, but search for a formal sentence to put, bothers many.

  2. put things more as bullet points and notes - occasionally, you can do more essay like stuff outside and link it.

  3. Keep dumping all your reading material, thoughts, questions in place, and rapidly evolve into notes and then into topics. Keep organizing. for example initially you may have some idea of what elements should be there in protocol and some other in the classes. over time, grouping and putting all elements related to protocol in a section by itself. Such a way you will keep evolving a formal document.

  4. Keep noting down why. Most important reason why you are documenting (for yourself) is to go back and check why some decisions were made. What alternatives you have when you need this. So that makes it very important when you need to question them.

  5. Last but most important, keep going to same place. most often we don't worry about notes when we get to some speed with. Try to be yourself, than formal but be discipline.

| improve this answer | |

If you don't take the time for proper development, you will spend 10 times that time fixing the software in production. Worse, you could loose the job and cost your company.

Most of the trouble developers face can be attributed to commitments made about delivery time of a project. Be clear with your management about the need for time.

If the company has no resources, maybe they could:

1-Give priority to the most required parts of the system and ask you to do the top ones in the given time 2-Hire more people to help 3-Buy a ready-made software that works, even if it does not do all the work required

Your questions cover the entire litrature of software engineering and requirements management as well other parts of the software spectrum, so it is impossible to give you a complete answer but here is a quick one.

How should I :

1- List out Requirements for myself. (Not an official document) 2- How to verify and validate the requirements ? 3- How to visualize them ? 4- How to design them with minimum effort ? (As its going to be with me only)

Answer 1: You have to break the business area into smaller ones (if it is big) - document input data and business rules clearly for each in clear and concise language and present it as a readable list. Try to build some use cases for critical activities.

Answer 2: The deliverables of answer 1 above together with the questions you will come up with during finishing the above task will help you ask the customer to work with you on verifying the requirements.

Answer 3: Convert results from 1 and 2 into a class diagram and/or ERD, Use Cases and Sequence Diagrams or BPM diagrams.

Answer 4: Use tools such as ORM, 3rd party GUI components and Code Generators if you could.

You must clearly understand:

  • System objectives

  • Different types of users of your system and security implications

  • What is the best platform for the solution

  • Documentation is not a waste of time

  • User communication is a must - Involve them early

  • Management involvement and communication is a must - Involve them early

  • Realistic goals and estimations are a must

Good luck

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.