For several decades, software reuse has been a recognized solution to improving efficiency of software development. However, implementing reuse in practice remains challenging and the IT community has little visibility into the state of the practice specifically as it pertains to reusing software requirements. This paper presents the results of a survey conducted in the global IT industry in 2010 and discusses the state of the practice for software requirements reuse.

We have always been fascinated by the exceptional business analysts who can create order out of total chaos. The ones who can ask those great questions, who can figure out what’s important and what’s less so, who can synthesize lots of information, put it all into their magic hat and come out with requirements that make sense to all the stakeholders.

Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?”

Your new system just went live and the project, that replaced a critical legacy system, is coming to a close. Business analysts gathered requirements and worked closely with users and developers, but did you capture all of the requirements?

Many IT managers have chosen to execute long-term projects in an iterative approach rather than a single linear fashion. This approach is not necessarily agile as the methodology is still “waterfall”-based but rather a series of waterfall executions (or terraced). This approach introduces new challenges for business analysts.

By taking a closer look at how your company is developing software, and what is working for projects with different profiles, it’s possible to leverage winning strategies and hybrid approaches to make your software initiatives equally or more successful in the future.

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.