Requirements Analysis (BABOK KA)

Aug 04, 2019
1797 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
4052 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
3723 Views
6 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
3416 Views
5 Likes
0 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
5894 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
5687 Views
2 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
8841 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
6512 Views
20 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
3923 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
8171 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
6987 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
6278 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.

Jul 08, 2018
10903 Views
12 Likes
2 Comments

Chaos! Stress! Everyday mess! Isn’t this an everyday situation for a business analyst? If not, either you’ve job satisfaction or you’re not being introduced to the real world of business analysis.

A person might possess great skills, however, (s)he might not be able to utilize skills without the right mix of tools and environment. A toolbox enables a person to implement the skills in the most efficient way. Possessing necessary tools is just the one part of it. Another is the knowledge to utilize the right tools at the right time to cater the solution and ensure timely committed delivery.

What are these tools? How do we map the usage of tools to the given circumstance? How can we efficiently utilize the tool? Does it depend on the solution or the approach?

6712 Views
8 Likes
1 Comments
A replacement project replaces an existing software system with a new custom-built system, a commercial off-the-shelf (COTS) system, or a hybrid of those. There are some challenges that most replacement projects share, including stuffing in unnecessary functionality, degrading the organization’s operational performance, users refusing to adopt the new system, and having such a large project that it never deploys. Focusing requirements practices on addressing these issues directly can increase the likelihood of a system replacement that delivers the desired value and is accepted by the users.
Jun 23, 2018
11467 Views
13 Likes
2 Comments

Non-functional Requirements capture conditions that do not directly relate to the behaviour or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.

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




Latest Articles

What happens when the BA and UX worlds collide?
Aug 18, 2019
1 Comments
Are you a Business Analyst (BA) wondering what User Experience (UX) Design is all about and how your involvement in a design project is likely to impa...

Copyright 2006-2019 by Modern Analyst Media LLC