Requirements Analysis (BABOK KA)

Sep 29, 2019
1391 Views
2 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
1135 Views
1 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
1923 Views
6 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
3806 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
6154 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
6266 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
5391 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
7763 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
7572 Views
3 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
9889 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
7019 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
4226 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?

Oct 21, 2018
8886 Views
16 Likes
0 Comments
In a classic business analyst universe, requirements are the soul of all the work a business analyst does. If a business analyst fails to identify and translate the right requirements, they’re out of a job. This is the reason why a successful business analyst is always good at requirements handling/management process. What makes requirements...
Oct 01, 2018
7846 Views
19 Likes
0 Comments

 

What do you put down in non-functional requirements when you are documenting requirements in your project? When we say non-functional we typically mean those requirements that are not related to functionality of the system, then what exactly are these and why do we need them.

Jul 29, 2018
6699 Views
4 Likes
1 Comments

In order for any project or initiative to be successful, an agreed upon business need must be determined. This need may present itself as a problem or an opportunity. Business Analysts must be able to guide the business in articulating which of these is the catalyst for the initiative prior to starting any BA work. Projects without a clearly defined business need get drawn out due to issues such as increased stakeholder conflict, poorly defined requirements, and excessive rework. So, to save you some pain and effort, below are some reasons why defining the business need is a critical starting point for any organizational change.

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




Latest Articles

Six Estimation Safety Tips
Oct 13, 2019
0 Comments
Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry w...

Copyright 2006-2019 by Modern Analyst Media LLC