Oct
18

FRD Functional Requirements Specification Format

I have found a very convenient format of writing requirements documents.  The format is mostly suitable for writing functional requirements documents. Yet, the format give a very good framework to specify  requirements for  UI elements and controls.

  • Reqt – is a unique (within a  document) requirement id.
  • Label – normally the controls are labled so you can reference it by label, otherwise you can make a call out on the wireframe.
  • Type – control or UI element type: field, button, list etc.
  • Length – length of the data in characters.
  • Required – specify if the element is required or not.
  • Values – this column contains the value for drop-downs and other list views.
  • Rule – any rule associated with the rule, including business rules.
  • Pre-populated – any default value that should prepopulate the field, or be set in drop-down etc.
  • Error Message – one or multiple error messages that should be shown if a rule is violated.

Read more…

Jun
09

4 pillars of business analysis

I am now reading “Business Analysis Techniques”  which I got as present from the author a BAdays in Minsk. The book is just awesome and inspired me, along with identifications of various requirements patter, give some extra thought to the technique I usually use for requirements gathering and analysis.

I believe it is the technique I always use to described any software piece – I call it “The 4 pillars of analysis”.  The concept is quite simple, as all great things should be, gathering and analysing requirements you need to keep in mind:

  • Entities – what, where, by whom the entities are created.
  • Attributes – what attributes each entity has, and what are the default values, what attributes are required, which are optional.
  • Entity relations – how entities interact with one another.
  • Lifecycle – what is the lifecycle of an entity.When is it created, when does it die.

Read more…

Apr
21

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…

Dec
23

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…

Dec
15

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.

Use case+2-0
View more presentations from MikeSorokin

The presentation was originally published on http://www.ivarjacobson.com/.

Dec
09

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…

Nov
26

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…

Nov
04

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…

Oct
28

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…

Oct
16

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…

Go back to top