Requirements pattern: data mapper

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…

User story + Use Case template

It looks to me that there is an ongoing tendency to modify the user story approach to managing requirements: make user story more specific and to make it look more like real requirement. The template below is a very good example of such attempt.

The template was initially downloaded from http://practicalanalyst.com/ba-resources/downloads/

[Use Case (UC)/User Story (US) Name]

UC/US ID: Unique identifier for the UC/US
Objective: List the objective to be accomplished as part of this use case or user story.
Narrative: In the case of a user story, use the “As a [user/actor/role] I want to [task/activity] so that [desired outcome].”
Actor(s)/Role(s): In addition to the primary role or actor, list other actors involved in fulfillment of the UC/US goal.
Pre-Conditions: Conditions which must be satisfied prior to the occurrence of the UC/US.
Post Conditions:
Owner/Stakeholder: Primary point of contact or responsible party for responding to questions around the UC/US.

Read more…

Use-cases 2.0

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/.

Dependent Entities: Deleting and Editing

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.

  • Deleting. Soft solution: Check if entity is used in other entities. If it’s used somewhere system needs to display a message like “The <entity name> in used in <list of entities where it’s used >. Are you sure you want to delete it? <Ok><Cancel>”. In this case, when you list the entities where the other entity is used, if it’s possible, you should make them as links.  So that the user can navigate to the entities where initial one is used and unbind them.
  • Deleting. Strict solution: Never allow deleting an etity that is already used with other entity. If it’s used somewhere system needs to display a warning message like “The <entity name> in used in <list of entities where it’s used >. To delete the <entity name> you must unbind the <entity name> from all entities where it’s used”.

If it’s not used, system just show the standard confirmation dialog and allows to delete it.

Read more…

Creating Dependent Entity in Context

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.

Read more…

Requirement pattern: clone

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.

Read more…

Hosting a Demo

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:

  1. Create a detailed plan of what you will be showing.  The user stories in the spring backlog should surely help you. Try to think, how you will walk the customer thru the implemented features. Make your step logical – you should execute the use cases the end user will do.
  2. Make notes such as credentials to log in, sample input data  that will be need to demonstrate some expected result.
  3. Read more…

Yet another presentation on User Stories

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.

Read more…

Requirement Patterns

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.

Read more…

Communication vs. Documentation

Documentation vs Communication in business analysisThis 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.

Read more…

Go back to top