If you intresting in sport buy steroids only here it true you find place where you can find information about steroids

From the category archives:

Requirements Specifications

Requirements specifications or documentation communicate the requirements in written form. Writing software requirements specifications requires clear language and attention to detail.

Politics is a tricky business. When I think of a politician I am reminded of a cowboy trying to herd cattle – they know where they want to take everyone, it’s just rather hard to get everyone to go in their chosen direction. Blood, sweat and tears are involved in the dusty world of influencing [...]

{ 10 comments }

Is there value in keeping system documentation up-do-date? Keeping system documentation up-to-date is a challenge faced by many business analysts. In discussion forums, it is common for this concern to be raised in questions such as, “How do you avoid the problem of having only one or two BAs with full understanding and latest information [...]

{ 12 comments }

In my previous article I described my first ever agile project as a Java developer. I highlighted some of the challenges that we faced in terms of the requirements gathering and analysis work. In this article I’m going to talk about my first agile project as a business analyst, and how I took on some [...]

{ 27 comments }

Reader question: There is an ongoing debate over elements in a requirements document that could also be considered design. For example, screen mock-ups, file layouts and content. Which belong in a requirement document and which don’t? Doug’s answer: The reader is correct in stating that this is in an ongoing debate and I’m going to [...]

{ 8 comments }

Hi there. My name is Tony. I live in Leeds, England and I’m an Agile Business Analyst. Oh dear, that sounds more like a confession at an Alcoholics Anonymous meeting than my first ever online article. It’s also not true and, so some people say, an oxymoron. Actually, what I really am is a regular [...]

{ 10 comments }

Whether you report to the business or to IT, BA’s all over are expected to deliver the same thing, documentation that is clear, testable, and has lasting value (when properly maintained) once complete.  Whether the project utilizes a waterfall or agile approach, the documentation should be clear, understandable and complete (“complete” can be defined differently [...]

{ 15 comments }

A few weeks back I posted an article on ModernAnalyst about the important of being results-oriented in business analysis. An interesting follow-up conversation ensued over on the BAForum of LinkedIn that focused on the relationship between being results-oriented and communicating requirements. In essence, the vibrant dialog centered around whether it’s enough to create a high [...]

{ 6 comments }

On May 4th at 6pm EST, Alex Papworth will be hosting a free webinar on the Six Essential Steps to Deliver Your First Use Case Model. A great entry-point for new and senior business analysts alike, Alex will take you through the following activities: Identify stakeholders Identify source materials Define actors Define high level use [...]

{ 1 comment }

Some recent posts across the blatherverse have highlighted some considerations that we as good business analysts must employ when developing and delivering our documentation and deliverables. These got me to thinking about my own very strong feelings in the past about what I should be doing as an analyst and how my audiences should be [...]

{ 14 comments }

Ask not what your developers can do for you, ask what you can do for your developers. These past few weeks I’ve been practically overtaken by a waterfall of humbling experiences. To be perfectly blunt, the developers did not like my requirements specifications. It was hard to realize that I had failed to communicate requirements [...]

{ 20 comments }