A missing ingredient in most current approaches to IT requirements and business rules is developing a standard business vocabulary, a concept model. Every business analyst should be familiar with the technique – it’s simply about clear thinking and unambiguous communication. What are basic constructs in developing a concept model? This article discusses four prefabricated elements of structure, ones that will enable you to build a complete and robust business vocabulary.

Every now and then I encounter a programmer who adamantly contends you cannot have an information system without some form of computer support. Actually, we've had such systems well before the advent of the computer.

At long last, Business Analysts are stepping into the spotlight...  Most BAs, however, still rely on documents and spreadsheets to manually stitch together their requirements. For those BAs, this article points out five ways that documents and spreadsheets are hurting your career and preventing you from joining the growing number of BAs who are fully equipped for the future of the profession…
 

The most common way to represent the links between requirements and other system elements is in a requirements traceability matrix, also called a requirements trace matrix or a traceability table. When I’ve set up such matrices in the past, I made a copy of the baselined SRS and deleted everything except the labels for the functional requirements.

Since its inception, the CPRE Foundation Level certification has evolved to become the most achieved certificate in Requirements Engineering (RE) worldwide. Right now, over 10,000 people have been certified worldwide in more than 35 countries. So what is it all about, how is it set up, what are the contents of the CPRE syllabi and how does the CPRE compare to other certifications?

Multiple stages of a project can benefit from brainstorming, from identifying your stakeholders, to eliciting requirements, to enterprise analysis. In UML for the IT Business Analyst, Howard Podeswa describes brainstorming as useful “during the Initiation phase and whenever the project is ‘stuck’”.

The purpose of this article is to assist business analysts in writing business requirements. This article provides six guidelines on technical writing. The six I cite here are the major ones I consider when writing a business requirements document (BRD).There are, of course,other technical writing guidelines; for comprehensive texts, see Further Reading (1). 

Managers should do some soul-searching; do they really need that information or are they interfering with the responsibilities of others? My advice to managers is simple: Delegate responsibility, hold people accountable, and get out of their way.

Simple requirements changes often have far-reaching impacts, necessitating that many parts of the product be modified. It’s hard to find all the system components that might be affected by a requirement modification. Assessing the impact of a proposed change is easier if you have a road map that shows where each requirement or business rule was implemented in the software.

Business process management (BPM) is evolving rapidly in the face of ongoing advancements in technology, an increasingly multigenerational workforce, and an evolving and complex regulatory landscape. Underpinning every BPM initiative is a focus on creating and sharing professional process diagrams.

All paths to organizational decision modeling encounter a common question: How do you introduce The Decision Model into an organization? More specifically, how do you gain management attention for delivering decision models as a standard practice? This month’s column addresses that question.
 

Successful business analysts have a mixture of many talents -- some more tangible than others – making Business Analysis both an art and a science. This article explores each area (art and science) and the types of skills necessary to be successful.

Has “Agile” killed “Use Cases”? Let us answer this question in this short article. As you may know, “Use Cases” have been a great way to document the detailed “Functional Requirements” of a system.
 

This article describes the Entity Relationship Diagram that allows you to document the structure of a database in terms of persistent entities and the relationships between them.  The Entity-Relationship Diagram (ERD) provides a way of graphically representing the logical relationships between entities in order to create a database schema to persist those entities.

Three questions regarding breaches of business rules should be addressed by Business Analysts: enforcement level, guidance message, and breach response. The goal is context-dependent, pinpoint reaction to breaches in real-time. Addressing breaches intelligently is key to creating friendly, agile, secure business solutions, ones that can evolve rapidly in day-to-day operation.