In this article, Geri Schneider Winters discusses the question of whether use cases can be used to document requirements for reports.

Author: Geri Schneider Winters

When it comes to providing reliable, flexible and efficient object persistence for software systems, today's designers and architects are faced with many choices. From the technological perspective, the choice is usually between pure Object-Oriented, Object-Relational hybrids, pure Relational and custom solutions based on open or proprietary file f...

"Business Analysis is about thinking what your solution should do, while Design is about how to make it happen using the technology available. Don't ever combine the two - you save nothing."

This paper by Brian Cooney, principal instructor at IRM, describes the need for clear separation between the two phases and the benefits this provides for a successful project outcome.

Author: Brian Cooney

In this issue of the IIBA Newsletter: BABOK v2 Outlined by Kevin Brennan Requirements Simulation - Analyst's Perspective by Joel Benayon Update on Annual General Meeting 2007 by Indy Mitra Baltimore IIBA Chapter Note by Rick Straub New Brunswick Chapter Note by Mary Ann Johnson

The talents, competencies and heroics of project managers and technologists alone cannot drive value into the organization. For business needs and goals to be converted into innovative solutions that truly bring wealth to the enterprise, a stronger bridge must be built between the business and the technical communities. Enter the business analyst. ...

This article provides a high level description of the job of the Business Analyst as well as summary answers on questions such as "Why you need a business analyst?", "What are the desired skills for a business analyst?", "How to find business analysts?", etc. Author: Katherine Walsh

Many organizations are scratching their collective heads over how to build and mature a business analysis center of excellence (COE). Where do we start? What does a business analysis center of excellence look like? Who owns it? How does it evolve? This white paper outlines the standard operating practices necessary for a business analysis center o...

Be it explicitly or not, someone always performs the role of requirements analyst on a software project. The official title may be requirements engineer, business analyst, system analyst, product manager, or simply analyst , but someone needs to translate multiple perspectives into a requirements specification and communicate with other stakeholder...

Given a specific project with a reasonably defined charter and clear business goals you, the business analyst, set out to elicit and document the detailed business requirements. So when do you stop? How do you know when you are done gathering the requirements?

Traditional software development has always required a long requirements-gathering phase at the beginning of a project that, if not handled correctly, can often result in schedule delays and costly budget overruns that have a significant impact on the project itself.  Software simulation can streamline that process and prevent many of the erro...

In this issue of the IIBA Newsletter: Base Consulting and Management Inc. Provides Financial Guidance by Shannon Bott BABOK Update by Kevin Brenan Experiencing the CBAP—Pre- and Post-Exam by Shirley Sartin

Many of the characteristics of properly specified requirements have been well known for many years, at least among professional requirements engineers. Yet most requirements specifications seen today in industry still include many poor-quality requirements. Far too many requirements are ambiguous, incomplete, inconsistent, incorrect, infeasible, un...

Maybe it was that southern drawl. Or maybe it was because I got mad. I'm not sure why I still remember this moment so clearly, but I do.  It happened when I was at Spyglass, over ten years ago.  Several of us developers were in a meeting with Steve Stone, then recently-hired as director of the Champaign office.  We were talking abo...

In this article, the focus shifts to a particular view in the 4+1 Architecture Views, defined by the Rational Unified Process. We will examine how to use Activity Diagrams as "roadmaps" for the Process View, to capture processing flows as a series of steps. We will also discuss several techniques for creating these diagrams and ensuring their effec...

The core purpose of software development is to provide solutions to customers' real problems. Use cases are a vital aspect of a technique that has been used successfully to ensure that development projects actually focus on these problems. They are used to discover, capture, and present customer requirements in a form that is accessible to develope...