Requirements Management and Communication (BABOK KA)

Sep 07, 2020
3553 Views
4 Likes
0 Comments

Business people call remote meetings virtual or on-line sessions, or simply conference calls. For many years we have been utilizing this form of communications to save time and money. Due to the global virus pandemic, remote meetings are now not just convenient, but a necessity for maintaining social distancing. Fortunately we have technology that assists us in managing these remote sessions to not only hear the stakeholders, but see them as well. However, remote stakeholder interviewing and meetings have their additional challenges beyond face-to-face encounters. Regardless of the technology used, we need to be keenly aware of these additional negative risks and pursue mitigations.

Jul 05, 2020
4302 Views
9 Likes
0 Comments

Requirements management is a critical function for business analysis. Requirements management is focused on ensuring that the business users and stakeholders have the following information available...  But the more important question to have answer to and where the real business value is delivered in requirements life cycle management is answering the following questions:

  1. Are the requirements impacting critical business processes?
  2. Which processes have recurring change?
  3. Are the requirements priorities aligned to key business processes?
  4. Which process will be impacted by which requirements?
Apr 13, 2020
4531 Views
25 Likes
0 Comments

This final article in the Requirements in Context series discusses detailed requirements for a fully automated business activity. ‘Fully automated’ means that the business information system (BIS) is expected to perform the activity from start to finish without user involvement. A simple example is the system automatically posting a monthly fee against customer accounts. A more complex example is the system utilizing customer-specific pricing details to determine the amount charged for a purchase made by a customer.

Mar 08, 2020
5852 Views
29 Likes
1 Comments

 

First of all, any operating system or solution contains two types of requirements: functional and non-functional. The solution works as a clock, which requires each gear within the solution to be properly functioning. Based on the theory of constraints, any process throughput can only be improved when the constraint or bottleneck is resolved.

Therefore, no matter how fast the train can run and how many passengers it can carry in one trip (the functional requirements), as long as the NFRs are not met, the performance of the solution (subway system) can only be as good as the non-functional requirements.

Second, if NFRs are not considered during the business analysis process, it is very likely they were not part of the criteria for solution evaluation. Without consideration of NFRs, the proposed solution may not be evaluated accurately. What was thought to be the best solution may not be a suitable solution at all.

Feb 09, 2020
7959 Views
25 Likes
0 Comments
It’s important for business analysts to recognize that there is a significant amount of non-technical (i.e. business) detail associated with a system interface capability. The interface is either importing data that’s needed and available in electronic format from another system, or exporting data in electronic format when it’s needed by some other system or organization. The data is either needed in real time or can be processed as a batch job.
Dec 01, 2019
16661 Views
41 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.

Nov 24, 2019
8288 Views
27 Likes
0 Comments

Business rules cover a very broad space. Across the entire space, however, you can be sure about one central idea – business logic should not be buried in procedural programming languages. Call it rule independence.  Why is rule independence important to you? Because rules entangled in procedural code won’t ever be agile. Rules change all the time – and in a digital world the pace of change is always accelerating. How you can stay on top of it is the central question in business agility.

Oct 22, 2019
48124 Views
39 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.

Aug 04, 2019
8682 Views
19 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
11759 Views
30 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
22761 Views
40 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).
16313 Views
31 Likes
0 Comments

In this article, I want to share my knowledge on how to manage product backlog using Jira. The article will be useful not only to business analysts or product owners but also to scrum masters, project managers. Basically, anyone who works with backlog and requirements on a project will benefit from reading it. There are certain rules and approaches that you have to follow to achieve good results.

Before we take a look at it I want to point out that this approach is not a market standard yet. However, over the last 3 years, I’ve completed a good number of projects using the approach I’ll be describing here

On the image below I tried to emphasize the main activities and processes that should be presented in your project. You also have to keep in mind that each artifact and process has own goal and definition.

14024 Views
80 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...
21361 Views
26 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.

12125 Views
21 Likes
0 Comments

Intelligent Business Requirements are business needs and objectives that were designed to add business value and promote scalability and innovation.

‘Project success’ is the attainment of predefined criteria that emerge from attainment of user requirements. User requirements, in turn, are defined by an evaluation of the business and functional requirements. Thus requirements pave the path that leads to project success.

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






Latest Articles

The Art of Letting Stakeholders Have Your Way
Nov 23, 2020
0 Comments
Study after study in behavioral science show that certain approaches are more effective than others when we’re trying to convince others to see ...





Copyright 2006-2020 by Modern Analyst Media LLC