In the previous article in this series, I described several conditions in which writing less detailed requirements is appropriate. However, there are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article (adapted from my book More about Software Requirements), expect to spend more time than average developing detailed requirements specifications.

[Read the rest of this article...]

In the first article in this series, I pointed out that there’s no easy answer to the question of how detailed the requirements need to be. Instead, I can present a thought process the business analyst can use to assess the appropriate level of detail for each case.

[Read the rest of this article...]

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?” It’s an insightful question, one that even experienced business analysts often ask me.

[Read the rest of this article...]

So you want to be a better requirements analyst. Or maybe you’re completely new to business analysis and you just want to learn what requirements analysis involves, period.

Requirements are basic to business analysis, and so requirements education is basic to business analysts. “All team members who will function as analysts should receive basic training in requirements engineering,”[1] notes Wiegers in his modern analysis classic Software Requirements. Honing your craft is both admirable and achievable, and you have numerous, helpful outlets at your disposal. The method that you choose is contingent on several things, including how much requirements experience you already have and whether your background is in software development, technical writing, or something else. (A former developer might want to learn more of the techniques through something such as BABOK [2], while a former technical writer might want more technical training through something such as a technical requirements workshop.) This article will highlight the some of the more popular methods of growing your requirements education, enabling you to better choose what’s most helpful at this point in your career.

[Read the rest of this article...]

 Requirements traceability ensures that each business need is tied to an actual requirement, and that each requirement is tied to a deliverable. This is a valuable practice for the business analyst. According to A Guide to the Business Analyst’s Body of Knowledge, (BABOK 2.0), all requirements are “related to other requirements, to solution components, and to other artifacts such as test cases. . . . The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective.”

[Read the rest of this article...]

It’s no secret in the IT sector that bad requirements are at the heart of high failure rates for software development projects. Unfortunately, the logical – and unfair – conclusion is that those who are responsible for defining and communicating those requirements should shoulder the blame for their shortcomings. The unacknowledged fact is that the fault does not lie with the people involved, but rather with methods and processes that fail to confront the reality of our limited human capacity to communicate complex ideas with only text and abstract models.

[Read the rest of this article...]

Requirements Planning adds incredible value to the requirements process. More than simply creating another “work breakdown structure” document, this is an opportunity to address risks proactively and gain better stakeholder participation.  This session demonstrates how every component of a requirements plan adds value.

[Read the rest of this article...]

The optimal path to mature requirements practices is often obscured by misinformation. Register now to see how to make significant operational improvement in requirements maturity and select a path based on a strong foundation of research and quantified success.

[Read the rest of this article...]

This session provides attendees with hands on techniques for determining the outcome of their projects before the project really gets rolling. This session is about facts, and presents extensive research from IAG’s new Business Analysis Benchmark Study to help business analysts and project managers build a predictive risk assessment model. This session puts the intake and requirements gathering process of the project lifecycle under the microscope to determine what actions Business Analysts and Project Managers can take to more consistently achieve a successful outcome on their projects.

[Read the rest of this article...]

This session is a deep dive into requirements documentation issues showing examples of good documentation practices and samples of materials that only look good on the surface, but have significant buried problems. Find out the 3 most common documentation mistakes, and learn about 5 critical success factors for effective requirements documentation.

[Read the rest of this article...]