Entries for 'speeditonline'

There is no single correct way to document specific requirements information. Every BA needs a rich tool kit of techniques at her disposal so that she can choose the most effective requirements view in each situation. In this article I offer some ideas about how to make that choice.

Enterprise analysis (also known as strategic enterprise analysis or company analysis) is defined as focusing “on understanding the needs of the business as a whole, its strategic direction, and identifying initiatives that will allow a business to meet those strategic goals.” 

An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable.

If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.”

There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant.

A data flow diagram (commonly abbreviated to DFD) shows what information is needed within a process, where it is stored, and how it moves through a system to accomplish an objective. As its name implies, a data flow diagram depicts the flow of data within a system.

Before harvesting business rules, you should be aware of some basic principles and absorb them into your practices. First, all business rules are subject to change, including (and perhaps especially) business rules derived directly from business policies. The ability to change and redeploy business rules is essential to business agility.

This article proposes a V-Model for agile development testing and invites feedback from the reader. The agile method used in this article is Scrum; the author assumes the reader is familiar with this solution development life cycle.

RuleGuide is a tool that accelerates and improves the quality of business decision and rule capture, analysis and management. By providing an enterprise repository for business decisions, rules, and associated metadata, RuleGuide fosters ongoing collaboration and alignment ofthe business and IT teams.

In this article we focus, not so much on the similarities among decision models, but on their differences. More than that, we explore the idea of classifying decision model structures based on differences in their logic. The decision model diagram is the first place to look for visible differences among decision models.
 

I was very intrigued with this concept when I read it in the Business Analysis Body of Knowledge (BABOK). This concept is so powerful and if used more in organizations can produce remarkable events; however, I have found that Systems Thinking can only be utilized to its fullest potential if the culture of the organization allows for that. However, as business analysts this is a concept that we should have in our arsenal of tools...

 The Data Flow Diagram (DFD) provides a graphical representation of the flow of data through a system. It shows logically what information is exchanged by our system processes and external interfaces or data stores, but it does not explicitly show when or in what sequence the information is exchanged.

Continuous change is a central fact of life for business these days. The techniques you use for business analysis must be based on the assumption that business rules will change, often quite rapidly. The best business solution is one that caters to such change, always doing so in the manner friendliest to business people and Business Analysts.

My understanding is that, in practice, successful agilists tend to bring together a number of activities, tasks, and deliverables that are from beyond the boundaries of what may be called “pure agile.” This mixing and matching of software process elements from agile and non-agile (more formal) approaches is a much more practical way of using these methods.

This article is all about putting your systems analysis into context; literally and metaphorically. It’s all about drawing and interpreting the not-quite-UML Context Diagram that is sometimes referred to as the System Context Diagram.