|
In Part 4 we drew both high level and low level versions of the To Be model of our customer’s change control process, based on the information we noted in Part 3. We are now ready to drive out and document high level system requirements (HLSRs). It is […] I recently asked the following question of fellow members of the International Institute of Business Analysis:“Should the analysts who produce the requirements specifications also write the testing specifications?” By “testing” here I mean system testing and user acceptance testing. My own opinion is that ideally they should not. My reasoning is […] Once again I have heard from a colleague from the development discipline that a requirements analyst is proving to be an obstacle to success because once the customer signs off on the requirements specification, the analyst considers his work to be done and disappears over the horizon.
Very […] In the previous posts on this topic, I have suggested a definition of “workflow” and I built on some high level statements of requirement to draw a visual model of a leave request workflow. I have broken down the drawing into several steps for the convenience of demonstrating the technique. However, […] I was between two minds about writing this post. After all, everyone knows that change control is important, don’t they? Then I remembered a couple of interesting cases where people did not seem to know that. In one case, a junior programmer had developed a very good rapport with one of […] In Step 3 we continued our workflow by exploring the path where the leave request also requires the approval of the HR Department. Now we shall investigate the exception paths when the leave request is rejected. In this case, when the Requestor reviews the rejected leave request, he can choose to […] In Step 2 we continued our workflow by using connector shapes to show the flow between the different stages of the work. In this step we are going to model any alternate flows that still lead to an approved leave request (in this case, just one alternate flow). The business rule […] In Step 1 we started drawing our workflow based on what we knew from the high level statements of requirement in the project scope. The next step is to start connecting the dots, the dots being the functionality available to the users. As I said in another post, we […] In the world of systems development, “assumption” is kind of a dirty word, but sometimes it can be a good thing. Assumptions are only bad when they are not confirmed with the customer. However, as a business analyst, your job is to put your thinking cap on between interviews/workshops and you […] In the foreword, I suggested a definition of “workflow” and provided some high level statements of requirement which provided the scope of our leave request workflow. I also said that four of those statements could be investigated in the form of sub-processes, use cases or user stories. I have tried to comply to […] |