Recently I've been assigned to a new project to start with designing and visualizing business processes. Unfortunately I just can't wrap my head around this one, I understand what the client wants but I don't understand how to translate it to a proper design what technically spoken makes sense.
The planning I came up with thus far is:
Extract the use cases from the briefing.
Design a use case diagram for those use cases.
Write all use case specifications.
Map the domain of the system in a Domain model.
Translate the Domain model to an Entity Relation diagram.
Design a Sequence and/or Component diagrams for all complex use cases.
Design a Class Diagram.
Design a Deployment and/or Package diagram when necessary.
Design the Wire frames.
Of course I will start off with sketching all documents before finalizing a particular one. But before I start designing this project I've to make sure that there is some kind of check what shows that I'm on the right path. I know there are stakeholders and developers who can help me verify the designs when I realized them or can ask questions to but there is actually no one I know who can help me starting of right.
Let me explain some of the context I'm challenged with, to help you understand and to perhaps clarify the scenario I'm talking about:
The project is actually already in development, although I'm not in favor of that decision.
The project should be separated in multiple systems. Which are partly accessible through the gateway pattern. Currently there is one of those systems in development. What I understand is that there are multiple Enterprise Applications (Billing software, CMS, API.. with maybe even more later on).
The target audience is huge and thus the software must be capable to perform smoothly when 1000 or more users are using it at the same time. To ease the development of that part the decision already has been made to host our software with Amazon their web services, to outsource processes what have to perform smooth under certain circumstances.
The application what is being developed right now had to be build already because of strict deadlines and the short amount of time. I spoke with the lead developer who told me that there are a lot of "micro services" which have certain jobs or fulfill the requirements of a particular feature. However because there is no software design and also no clear view of what is going to be added or changed in the future, the developer decided to maintain a rather flat and simple structure.
The documentation what has been written right now I would rather call a giant list of features/requirements or a briefing.
Also I think it's quiet important to note that the system should be capable of analyzing a wide variety of data generated by the system and perhaps also external systems what eventually will be used for marketing purposes. Therefor I have to map the data processing processes to enhance e.g. data warehousing.
Well a conclusion would be nice now :) don't you think?
Almost everything I know about this project is explained above except the domain and business process (because of a NDA). But how do I know/validate or am I on the right track? Did I inquire enough information or do you have any tips or feedback? Please let me know.
I can give you a little advice based on the general situation you are in.
The project is actually already in development, although I'm not in favor of that decision
Whether you are in favor or not, it's a fact. I'm going to wager you can't stop it and even if you could, it's not going to end well (for you.)
So basically, development is underway and you are trying to do a big-upfront design. This is going be a major waste of your time. What you produce in that effort (if anything) will have no impact on the system. I happen to think that, aside perhaps from certain types of high development cost projects, most big-upfront design is a waste no matter what, but in this case, the horse has left the barn. So what do you do instead at a high-level:
Prioritize the high-level requirements. There are certain features that you need to support: i.e. display a foo diagram for a bar.
Talk to domain experts about this. Get what you can from them. Don't obsess over the getting every last detail because that will never happen at this point anyway.
Build a basic prototype for a single user. Show the domain owners. Let them tell you what is missing or wrong. Fix those issues.
Repeat #3 until they are satisfied. If there seems to be no end in sight, talk to leadership about what 'good enough' is and have them give direction on where to stop.
Build automation to test the living crap out of it. This includes but in not limited to unit tests. NOTE: this just needs to be done at this point, you should start much earlier.
Start building in the non-function requirements like performance and multi-user cases running your tests and adding to and enhancing them as needed.
Repeat from #1 until you've created something that can be used.
It should go without saying that you need to adapt and tweak this to fit the needs and processes of your client.