In this article, we will use an example from SoftwareHouse that started a relationship with a new client. If you don’t have your own methodology for collaboration with clients, this article could be of worth to you. I enclosed a lot of materials as processes that you could deploy to your daily basis tasks.
This is Part 3 of the Series of articles about collaboration with clients in the Software product LifeCycle. It’s a continuation, so if you haven’t already, check out first Part 1 or Part 2
Now, we are at the next step of our process, we have a relationship with the client and equally important an agreement with him. We can start with an entire contract and take care of this project and product according to our methodology.
If you didn’t see the last episode, I recommend just going and doing that. Check the link below. This episode is a continuation, so it is better if you start from the beginning.
During the workshop, we were devising a solution with a report after one hour. This is important as we will base the application on this functionality.
We can’t publish the workshop with the client but maybe at some point, we will create a video of how this analysis would be conducted. Subscribe to this channel or our Newsletter. Link below.
In this tutorial, we will take a look at the results of this workshop. The structure of requirements as a model will explain the whole concept of the application.
The main activities of that kind of workshop are eliciting almost all requirements. You have to remember you have limited time so you need to focus on concretization.
I can’t recall how we went step by step with this model but I will explain to you everything in detail.
So let’s start:
After all that, we will make some other model without “noises” to show our application from another perspective. That was possible after the clarification of requirements and an idea of how we could solve everything. The game changer in the analysis was the idea of a cyclic summary after some period of time. We assume that after one hour we will send to the user a summary of what he does within this time.
We have needs and business requirements. The functional requirement will be defined on an upper abstraction.
First, we have to write data to the system, next we can report them.
We divide this application into 3 main functionalities. The first two would be “Save data” and “report data”. Third would be any setting that we have to set so that the App will work strictly with a dedication to the processes and environment of the Client. Those are not innovations in the IT systems but in this model, we can present the Client and the Team members with a solution in the Big Picture. To describe and categorize the above actions, we use Use Cases. You can also use User Story to do that. I like Use Cases, so we will create a Use Case model.
We use it (the Use Case model) but it’s very similar to the Conceptual Model (from the Computer-Science Perspective). The most important is that this model explains applications in a similar way to some HighLevel Design HLD (https://en.wikipedia.org/wiki/High-level_design).
On the above Requirements model, we created some entities with the type “User Case”.
If you create some Models in Product Core Lab, you can use the same elements from Repository. Check how simple it is.
In the Analysis, we discovered a new Requirement and noted it as the Use case “Configure work environment”. We put it at the top of the structure and added a description that on the first use of the application – The user should configure his environment
It’s a great moment to create a new “risks model”
Adding the descriptions with mitigation ideas – In ITGP, we always propose to our client some ideas to mitigate the risk. This is the part of the analysis that we perform on our client
Let’s go back to our User Cases to add Descriptions. In this phase of the project, the most important is to add main scenarios and main alternative paths. This will help analyze everything with the client and our technical part of the team.
In the further step, we need an Internal Business Analyst session. Here, we will have a creative session and take the time to devise a better solution.
We have to take some time to check everything again after the workshop. We have to make sure everything is correct and consistent. Think about fulfilling business requirements twice and send them to the Client for approval.
Now we can send to the client our software documentation and prototype application as a model.
The next step after all that would be real prototyping and estimation.
Sign up for our Newsletter, we let you know about the next episodes how you can do everything in the Product Lifecycle Management, and of course how you can estimate projects in Product Core Lab,
I’m Karol Kordziński from Poland . I’m an analyst with a couple of years of experience. I’m the owner of ITGrowPartner where we help small- and medium-sized companies analyze projects. But mainly I’m the owner of Product Core Lab. Saas tool to manage a product in the whole Product Lifecycle. With this tool, you can explain your product and processes in a structural method. We introduce you to how to model software products step by step
Leave a Reply