This subject is so vast that nobody on this site knows finally what you need to deliver to your purchaser. But I would like to share some thoughts.
Try to find out what your purchaser's intention is, this is also what Ben recommends in his comment. Why? Because different expectations will force you to behave completely differently. Here is what your customer could say:
- "We want to understand what you are doing. We want to learn with you, while you develop."
- "We want to see the project is developing in a formally proper way."
- "Once the project is finished, somebody else will continue to develop and therefore needs the documentation."
- "We have heard it is important to have a documentation."
- "We are now a ISO XY company and in paper 8763874.8734 there is written that projects of type A77 must be documented."
These are totally different situations. Be prepared to have a strategy for such intentions.
If you have formal requirements (like ISO), then you must be given the final documents that instruct you how to proceed. If somebody else continues after you, try to know this person as early as possible, and to adjust the process and the outcomes.
Find out what is also important to your customer. Is it important what tools you use? What if the people simply know the Office suite and expect you to draw UML diagrams with Word? Do you have to recommend a software design product? If you talk to your employer in UML, will they understand or do they need a simplified presentation with Powerpoint?
Are people aware that the Agile Manifesto says, "A constantly working software is more important then a comprehensible documentation", look here: http://www.agilemanifesto.org/
It is written there for a reason. Documentation is expensive. It binds resources. It tends do get outdated. It makes you sit there for hours, maintaining lists and diagrams while the bugs are not getting fixed. Do they pay you for that? As you say you have not much experience, who will pay the learning curve?
"Stick to the standards". Ok. Standard is something very different for a big company than for a small company. But maybe they mean "well established tools and methods in Software Engineering".
So here is what I would do in that situation (all documents as short as possible and as long as needed):
A document with user stories. This can be free text. It is important that the users see their daily work reflected in there.
From user stories, you derive UML use case diagrams.
From use case diagrams, you derive listed and numbered requirements and suitable, matching test cases. You will need them later.
From use case diagrams, you derive analysis diagrams. There, you show by symbolic and strong formal diagrams how the customer's world is running. Not how the software is built, this is the subject of design.
Transfer the analysis diagrams to software design diagrams. Could be: ERDs, class diagrams, component diagrams, call graphs, state diagrams with swim lanes... Here you go: http://www.uml-diagrams.org/uml-24-diagrams.html
From the software design diagrams, start implementing test cases and and productive code, continuing tested by the test cases.
Grab a Doclet tool, write good headers in the code and create an HTML documentation from the headers.
Well, that should do it. Try to work out crucial mechanisms and focus on them. If the company was bigger, more documents were added - concerning security, safety, risk analysis considerations, performance and availability considerations. Would your customer like to see a physical component diagram with balanced nodes? Don't forget that every artifact (document, piece of code) should have a clear number, to avoid misunderstandings due to version cluttering. Where does your customer draw the line? Is it important what code repository you use?
You have mentioned "Wireframes". They are a part of the user interface design, or prototyping. Have a look at these: https://balsamiq.com/products/mockups/, https://uxpin.com/, https://moqups.com/ Working with prototypes are a good thing. It drastically reduces costs of late corrections. The prototype is adding to the user stories, saying "this is how the customer would like to handle the software visually, physically". -
If everything goes well, you will end up with a tested software, a UX façade and a handy collection of sheets. If you are to handle issues after, you can start the chain: The issue alters the user stories, which alters the use case, which alters the ... ...
But I must not make you false hope. If you never learnt to handle for instance Astah or something similar, you will need a lot of time just to understand what those tools can do for you. Also, you have to get used to many details of UML specific notations. Maybe it is a good thing to inform the customer clearly that you are learning, and you do appreciate the opportunity to learn, but both parties must be patient.
