Problem: System gets data either from user input or when user or other system uploads data. The article discusses the problem of how the system should identify what kind of data you are uploading. How should the system know that from column “price” of you .csv file the data should go to the column “price” in the DB.
Solution:
Provide a visual tool where the user will be able to wire the data from your file to the fields in your system.
Read more…
Ivar Jacobson has made deep re-thinking of the use-cases idea. I want to re-post his presentation of Use-cases 2.0. He is also saying the in the near future a book on use-case 2.0 will be released.
The presentation was originally published on http://www.ivarjacobson.com/.
To continue the topic of depenend enties, I would like to say a few words about the case when one of the enetities wired together can be deleted (no matter if it’s soft deletion or hard). If you think that deleting, say, a suborditate entity used in a primary entity can change it’s business behaviour of the latter, you need to explicity notify the user about that and have her confirm that. So that your system is not blamed afterwards for someone failure.
Similar cautious approach should be considered when you edit the an entity that is used by some other entity.
If it’s not used, system just show the standard confirmation dialog and allows to delete it.
Entities in an application might depend on one anther. When a user creates an entity she might need another one to accomplish the flow. The idea I want to share pertains more to usability rather than business analysis, but anyway it would be a good tip for the person who is working on creating a new app. The idea is very basic – if a user needs the entity A while creating the entity B, let him create the entity A right in the context of creating B. It sounds pretty complex and needs an example.
If you take a look at OO programming language like Java ( and even PHP) you will see that it has some built-in tools to clone an object and modify the cloned object preserving the initial object unchanged.
While working on the requirements for some entity, say a complex newsletter, that will require the end user to perform lots of tedious operation to fill the entity with data, you need to question yourself: “Will the user ever want to re-use” a existing entity? If the answer to the question is positive, you might consider implementing the “cloning” requirement pattern.
Visio and other editing applications like Photoshop have the simplest implementation of this pattern – to make a copy of any object you can just click CTRL+D.
Let’s consider a more complex example – a newsletter creating tool.
If you stick to agile methodology in software development, you are likely to know what a demo is. It’s a part of business analyst’s job to show the piece of functionality the team has worked during the sprint (iteration).
I should say demo is a serious thing and you should treat it very seriously as you are showing the efforts of the whole team and they want to get the feedback of their work; the customer has certain expectations – this is something he is paying for. Business analyst who is the primary communicator in the agile team should consider a demo as a very important communication process.
Getting prepared for a demo takes time, I plan about 4 hours to get ready for the demo. I usually do an internal demo with the team to make sure I will not mess up when I will be showing the implemented stories within the sprint to the customer. Since I work in the company that provides offshore programming service, on the demos I host I share my desktop using gotomeeting or some other similar tool.
Some practical tips to host a more successful demo:
Couple months ago I was asked to make a brief scrum training and to tell some colleges what users stories are, how to write them, who should write them etc.
These are the slides I made for that presentation.
Working in IT you can always hear programmers talking about GOF patterns and now it’s a must for a programmer to know them (at least on the job interview). When I started working as a business analyst I always wondered if there are business analysis patterns.
This post will discuss the ratio of communication and documentation in the relationship with the customer. The ratio might seem quite obvious to an experience business analyst, but this is not always what is crystal clear to a customer. A customer might be “scared” by heavy loaded processes which imply lots of documents, where their main concern that they might miss something important in the documents and the development team will create something different, something that they did not expect to see at all. With that in mind the customer will be willing to have less documentation.