_Requirements.com

Capturing of Business Requirements - Technical Guideline

Adrian Marchis — Sun, 08 Jul 2012 00:03:00 GMT

The purpose of this document is to provide a technical guidance on how to capture and document business requirements in order to produce BII profiles.

How Detailed Should Requirements Be? Part 3 - When More Requirements Detail Is Advisable

Adrian Marchis — Thu, 12 Jan 2012 09:18:00 GMT

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.

How Detailed Should Requirements Be? Part 2 - When Less Requirements Detail Is Appropriate

Adrian Marchis — Wed, 04 Jan 2012 09:16:00 GMT

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.

How Detailed Should Requirements Be? - Part 1

Adrian Marchis — Mon, 19 Dec 2011 09:14:00 GMT

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.

Starting Your Requirements Education

Adrian Marchis — Wed, 31 Aug 2011 05:29:00 GMT

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.

An Introduction to Requirements Traceability

Adrian Marchis — Mon, 16 May 2011 07:00:00 GMT

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.”

Webinar: Leveraging Software Visualization to Elicit, Validate and Communicate Requirements

Adrian Marchis — Tue, 11 Jan 2011 07:32:00 GMT

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.

Webinar: 5 Things You Must Know About Requirements Planning

Adrian Marchis — Tue, 11 Jan 2011 07:29:00 GMT

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.

Myth-busting: The Path to Requirements Success

Adrian Marchis — Thu, 09 Dec 2010 14:00:00 GMT

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.

Webinar: Requirements Gathering under the Microscope

Adrian Marchis — Thu, 18 Nov 2010 19:17:00 GMT

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.

Webinar: Inside Effective Business Requirements Documentation

Adrian Marchis — Thu, 21 Oct 2010 02:18:00 GMT

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.

Webinar: BA Best Practices: Reporting Requirements, Design, Creation and Distribution

Adrian Marchis — Mon, 11 Oct 2010 21:46:00 GMT

In this Webcast, Amit Parikh, manager of systems consulting for Quest Software will show you some best practices to simplify the process of defining reporting requirements, finding the data you need, and designing and distributing reports. Featuring examples from organizations who have implemented Toad for Data Analysts’ technology, Parikh will demonstrate how to utilize a simple workflow to perform the following tasks...

Webinar: Optimizing Requirements Discovery

Adrian Marchis — Tue, 21 Sep 2010 13:11:00 GMT

Why should it take months to determine project scope and gather requirements? Register now to look at the underlying problems that impede the collection of business requirements and make projects less successful.

Webinar: Managing Requirements Operational Excellence

Adrian Marchis — Tue, 21 Sep 2010 13:00:00 GMT

Managing Requirements Operational Excellence is about making significant change in requirements discovery and management performance. This session is for the business analyst leadership and development executive looking to make long term, systematic improvement to their business analyst organization.

An Overview of Requirements Elicitation

Morgan Masters — Wed, 07 Jul 2010 05:21:00 GMT

A thorough discovery of business requirements is almost never readily available at an analyst’s fingertips—rarely can requirements be quickly looked up as one would gather information for a term paper or study for a test. Much of business or technical requirements is not documented anywhere—it resides in the minds of stakeholders, in feedback that has yet to be obtained from end users, and from a study of flowcharts and surveys that have yet to be created. And so requirements must be elicited, or drawn out, and the methodology in doing so must be logical and meticulous. The importance of elicitation cannot be overstated, for it is the linchpin to any requirements project.

Brûlé’s Rules of Playing Telephone with Requirements

Morgan Masters — Mon, 10 May 2010 05:23:00 GMT

You remember the game of telephone, right? The test of communication skills where one person whispers a message to his neighbor, and that message is translated multiple times from person to person until eventually, the last contestant repeats her interpreted message aloud. The goal is for the final person in the chain to correctly hear the original message, but invariably, there is laughter all around as the message is misconstrued. When this happens in business however, it’s no laughing matter... There is a tendency to interpret information in very individualized ways, but as business analysts (BAs), we don’t want to allow for that. Rather, BAs strive for clear, concise and coherent articulation of requirements because it influences the outcome of solutions.

An Overview of Organizing Requirements

Morgan Masters — Sun, 09 May 2010 07:24:00 GMT

The voluminous amounts of information that an analyst collects during the discovery and elicitation phases warrant a good deal of planning and organization in order to make business or user requirements into a usable, cohesive whole. As with any other organization process, the key element to requirements’ organization success is thorough preparation and planning. According to BABOK 2.0, an analyst has two main objectives when organizing requirements: (1) to understand which models are appropriate to include based on the business need, and (2) to understand and clearly communicate the interdependencies and relationships between the various requirements.

An Overview of Requirements Prioritization

Morgan Masters — Tue, 04 May 2010 08:47:00 GMT

Excellent requirements prioritization is essential to any well-run project. It ensures that the project focuses on the most important elements first, and that everyone understands and agrees regarding what the project’s most important elements are. Good prioritization of requirements will also ensure that engineers, programmers and database analysts develop a project’s most critical elements in sync with the business needs.

Business Requirements

Morgan Masters — Fri, 30 Apr 2010 07:08:00 GMT

The purpose of business requirements is to define a project’s business need, as well as the criteria of its success. Business requirements describe why a project is needed, whom it will benefit, when and where it will take place, and what standards will be used to evaluate it. Business requirement generally do not define how a project is to be implemented; the requirements of the business need do not encompass a project’s implementation details.

Availability Requirements

Morgan Masters — Thu, 22 Apr 2010 08:49:00 GMT

There is no one standard definition of an Availability Non-Functional Requirement. It will be defined for each project where it needs to be specified. This principle is true of all non-functional requirements. For the purposes of this article an Availability Requirement is any requirement that is not a functional, data or process requirement concerned with defining the periods when the solution can be used.

Accuracy Requirements

Morgan Masters — Thu, 22 Apr 2010 07:59:00 GMT

There is no one standard definition of an accuracy non-functional requirement. It will be defined for each project where it needs to be specified. This principle is true of all non-functional requirements. For the purposes of this article an accuracy non-functional requirement is any requirement that is not a functional, data or process requirement concerned with defining the precision which the solution will record or produce data.

An Overview of Business Requirements

Morgan Masters — Sun, 13 Dec 2009 07:00:00 GMT

Before you can chart how you are going to implement a solution, everyone involved in the development effort must agree on why you need it to start with and that it is the very best solution available. Business requirements are fundamental to any development effort because they define where you are going by articulating the business problem and its solution—why it is needed and how to measure its success.

Requirements Gathering and Documentation

Requirements.com Editor — Wed, 07 Oct 2009 09:09:00 GMT

Very few people doubt it nowadays: The gathering of requirements and its appropriate documentation is a fundamental step in the success of any project. Yet, many people still disregard it.

Requirements Gathering - Scheduling Activities

Requirements.com Editor — Mon, 28 Sep 2009 09:06:00 GMT

Requirements gathering activities should be scheduled by your project plan like any other project related activities. If these activities don't track to the schedule, whether because the schedule isn't feasible or some other reason, it will cause all the dependant activities to slip. Once you've chosen your requirements gathering approach and the stakeholders you'll meet with to gather the requirements, you can schedule the meetings, or interviews, or other methods for soliciting the requirements.

Documenting Requirements For Software Development Projects

Requirements.com Editor — Mon, 21 Sep 2009 08:59:00 GMT

There are various ways and means by which requirements for software development projects can be gathered and documented. Before you start documenting the requirements you might want to be sure if you have captured all the required information.