Requirements Analysis (BABOK KA)

Dec 08, 2019
34 Views
0 Likes
0 Comments
The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, the Future-How, which looks at the solution to the business problem. It does this by assessing alternatives, and then choosing the best solution to that real business problem.
Dec 01, 2019
1150 Views
2 Likes
0 Comments

For business analysts working in an environment where there is a gap between SMEs and the delivery of an IT-based solution for business needs, requirements are documented to bridge that gap. You are reading this because you are a business analyst responsible for documenting detailed requirements and, in the case of this article, business needs involving one or more user interfaces (UIs) or reports.

The objective of this article is to answer the question, “How much detail is necessary?” Spoiler alert – quite a bit. This is to avoid, as much as possible, a BA having to go back to a SME when designers or developers have business-level questions about a UI or report. Or worse – designers or developers not asking questions. Instead, making assumptions about what the business needs and proceeding to deliver the solution based on those assumptions.

Oct 22, 2019
4285 Views
10 Likes
0 Comments

Requirements documents are used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page.  When we talk about a requirements document we are often referring to a Business Requirements Document - or a BRD.  But as well as a BRD, there are 9 other types of requirements documents that a business may want to use while pushing a project through its stages of completion. The type of format to be used depends on the result of the project itself, whether it’s a product, service or system, and the particular requirements it has.

Sep 29, 2019
4513 Views
10 Likes
0 Comments

The previous article in this series discussed ensuring that high-level requirements (HLRs), within the context of an IT-based project, were properly high level. The remainder of articles in the series will look at detail requirements and the need for them to be sufficiently detailed. The objective of this article is to demonstrate how a data dictionary (DD) can be used as a tool for capturing the appropriate level of detail representing data-specific business needs.

Sep 29, 2019
3689 Views
3 Likes
0 Comments
The purpose of the Trips-R-You Flight Booking Case Study is to provide an integrated, end-to-end set of requirement examples. In IIBA® BABOK® V3 terminology, end-to-end means from Business Requirements to Stakeholder Requirements to Solution and Transition Requirements. This case study, and associated artefacts, use the more traditional business terms Goals, High-level Requirements (HLRs), and Detail Requirements. Only functional requirements are addressed, and only within the context of a project chartered to deliver an IT-based solution.
Sep 22, 2019
4295 Views
10 Likes
0 Comments

Let us look at it from a different angle now and derive the requirements out of the customer journeys.  It is impossible to introduce a change... if the change is big and you try to implement it in one go.  This is the reason we tend to break any solution into smaller components. Each solution component should be small and independent enough to be changed individually in a controlled manner. So that eventually we will compose a new experience out of them. Pretty much like using a set of Lego blocks.

Aug 04, 2019
5730 Views
6 Likes
0 Comments

If someone said you could only perform a single quality practice on a software project, what would you choose? I’d pick peer reviews of requirements, which I believe are the highest-leverage quality practice we have available today.  In a peer review, someone other than the author of a work product examines the product for quality problems and improvement opportunities. Reviewing requirements is a powerful technique. Use them to identify ambiguous or unverifiable requirements, find requirements that aren’t sufficiently detailed yet, spot conflicts between requirements, and reveal numerous other problems.

Jul 07, 2019
8118 Views
13 Likes
0 Comments

Reuse is an eternal grail for those who seek increased software productivity. Reusing requirements can increase productivity, improve quality, and lead to greater consistency between related systems.

Reuse is not free, though. It presents its own risks, both with regard to reusing existing items and to creating items with good reuse potential. It might take more effort to create high-quality reusable requirements than to write requirements you intend to use only on the current project. In this article we describe some approaches an organization could take to maximize the reuse potential of its requirements.

Jun 30, 2019
9102 Views
9 Likes
0 Comments
The objective of this article is to provide business analysts with guidelines for distinguishing between high-level requirements (HLRs) and detail requirements (in IIBA® BABOK® V3 terms – Stakeholder requirements and Solution requirements respectively).
Jun 23, 2019
6930 Views
7 Likes
2 Comments
Unfortunately, business rules often are a mystery in business. Most of time they are undocumented and worst they are a figment of someone’s imagination - no basis. However, mystery or not, we need them in eliciting stakeholder requirements in order to understand how the business obligations are kept, constraints are enforced and how decisions are made. And just like news reporters, we need to confirm the business rules with a second (hopefully authoritative and documented) source. Furthermore we need business rules to ensure a quality product and/or process through testing.
May 27, 2019
8826 Views
11 Likes
0 Comments

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

May 05, 2019
8379 Views
4 Likes
2 Comments

Project Scope. We will see how scope statements, when making reference to business functionality, lead directly to High-Level requirements.  Gathering requirements for a business information system is most often done within the context of a project. Approval of a project includes its sponsors signing off on its scope. The scope for a business information system project is typically defined in functional terms. Items in scope make reference to (or should make reference to) business functions, processes and/or activities that are to be delivered.

Mar 17, 2019
10421 Views
22 Likes
1 Comments

One of the three activities encompassed under Requirements Analysis is the process of ‘ Requirements elicitation’. IIBA’s definition of ‘elicitation’ is “An activity within requirements development that identifies sources for requirements and then uses elicitation techniques to gather requirements from those sources.

However, this definition appears incomplete from an analyst’s point of view as it relies solely on the assumption that one can come up with requirements only by running elicitation techniques; however, the process of elicitation is not as simple and straightforward as it seems. Let’s see why.

Jan 01, 2019
7479 Views
21 Likes
0 Comments

This article provides high-level steps for eliciting requirements when interviewing or holding a facilitated meeting with stakeholders; it was motivated by an attendee question at a recent Modern Analyst webinar: “Functional vs. Nonfunctional requirements.”  The question was, “Can a Business Analyst elicit functional and nonfunctional requirements in the same iteration?” 

Oct 28, 2018
4567 Views
22 Likes
0 Comments

One of the Sidebars to the Business Agility Manifesto unabashedly indicts the software industry for its long-standing failure to provide direct support for obligations, an obvious and fundamental aspect of real-life business activity.

Where can you find obligations in business? Virtually everywhere you look: acts, laws, statutes, regulations, contracts, MOUs, agreements, terms & conditions, deals, bids, deeds of sale, warranties, guarantees, prospectuses, licenses, citations, certifications, notices – and of course, business policies.

Direct support for obligations is a fundamental capability your organization needs in the Knowledge Age. What’s it about?

Page 1 of 12First   Previous   [1]  2  3  4  5  6  7  8  9  10  Next   Last   




Latest Articles

How Will It Work? The Future How Viewpoint...
Dec 08, 2019
0 Comments
The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, ...





Copyright 2006-2019 by Modern Analyst Media LLC