Requirements Management and Communication (BABOK KA)

18797 Views
22 Likes
0 Comments
 In this article we look at some quality attributes that are particularly vital to explore when specifying requirements for embedded systems projects. Quality attributes for embedded systems can be much more complex and intertwined than those for other applications. Business software is generally used in an office where there’s not much variance in the environment. In contrast, the operating environment for embedded systems could involve temperature extremes, vibration, shock, and other factors that dictate specific quality considerations.
12637 Views
16 Likes
0 Comments

The purpose of this brief article is to explain the connection between documenting requirements and contract type. Recently I consulted with a firm eliciting requirements for a new product. In this case, an internal business analyst team was documenting the product requirements by consulting with appropriate stakeholders. The follow-on project intent was to outsource the work to develop the product in the form of a contract.

17856 Views
17 Likes
0 Comments

iRise gives Business Analysts the tools they need to communicate clearly with both the business and its stakeholders.  They use working previews that can be virtually indistinguishable from the final product.  When business analysts uses iRise to elicit and document requirements: the business analyst becomes a powerful weapon to get to the right answer, ...

60460 Views
67 Likes
0 Comments

A business analyst is a person who analyzes, organizes, explores, scrutinizes and investigates an organization and documents its business and also assesses the business model and integrates the whole organization with modern technology. The Business Analyst role is mostly about documenting, verifying, recording and gathering the business requirements and its role is mostly associated with the information technology industry.

18709 Views
8 Likes
0 Comments
Let’s face it, there are just some conversations that you don’t want to have. There are some people you simply don’t want to talk to, but what happens when we don’t have these conversations? Everyone loses! It is perfectly natural for us to avoid difficult conversations. We fear rejection, retaliation, emotional outbreaks, the dismissal of our ideas, and of course those incredibly awkward moments where everyone around you stares at their feet thinking “God I am glad that’s not me.” However, these conversations need to be had and the Badass Business Analyst will have them. If we want healthy, productive teams and projects, crucial conversations must be had frequently. You can’t just keep ranting, raving, complaining and avoiding, you need to start having meaningful, persuasive conversations that make an impact. You need your ideas to be heard, and more importantly you need behaviors to change. Don’t you think its time you and I have a crucial conversation? Suddenly I feel like I have turned into my father. Sigh. For the record, all of his crucial conversations were always too late, which is maybe why I am so passionate about this particular chapter in my book (the longest chapter by far - okay, moving away from from therapy now).
19846 Views
15 Likes
0 Comments
A story is defined as a narrative or tale, true or imaginary. Each story has a moral hidden in it. A story writer won't directly say that hard work and patience is the key to success. Instead the writer came up with a story of Hare and Tortoise. And if we observe carefully, stories are everywhere; we ask a friend about her love story, we watch a prime time news story, we ask a new friend about his life's story, the movie I watched the other day had a good story. 
19074 Views
72 Likes
0 Comments

Most discussions about software requirements deal with business information systems and similar projects. The world is also full of products that use software to control hardware devices, broadly called embedded systems. Among countless examples are cell phones, television remote controls, kiosks of all sorts, Internet routers, and robot cars.  This is the first article of two that will discuss some of the requirements issues that are especially important to embedded and other real-time systems.

32294 Views
176 Likes
6 Comments

With the rise in popularity of agile methods, business analysts and product owners often use the term “agile requirements” to label their work.  We do not care for the term “agile requirements” because it implies that the requirements for an agile project are somehow qualitatively different from those for projects following other life cycles. A developer needs to know the same information to be able to correctly implement the right functionality regardless of the life cycle being used.

13318 Views
13 Likes
4 Comments
So you’ve developed a set of requirements for some portion of your next systems development project. Now what? Experienced project managers and software developers understand the value of translating requirements into rational project plans and robust designs. These steps are necessary whether the next release represents 1 percent or 100 percent of the final product. As shown in Figure 1, requirements serve as the foundation for project plans, designs, code, and tests. In addition to these connections, there is a link between the requirements for the software to be built and other project and transition requirements. Those include data migrations, training design and delivery, business process and organizational changes, infrastructure modifications, and others.
8883 Views
2 Likes
1 Comments

This article covers a trend in the industry that has been yielding great results for companies looking to deliver more successful projects. By cutting down on huge initiatives with outrageous requirements documents that just can't be managed and focusing on implementing features and functionality a piece at a time, companies can be sure to deliver more value to customers more often. 

23771 Views
19 Likes
0 Comments
Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles...
11553 Views
0 Likes
0 Comments

Are the current IT systems meet the requirements of Business users or deliver the services that will bring competitive advantage to the organizations?

IT projects continuing to cost overrun, time overrun or doesn’t meet requirements. Poor communication – particularly between business and technical experts – is a constant problem. – As per Financial Times

14968 Views
9 Likes
3 Comments

Many business analysts focus their full attention on tasks related to specifying, modeling, verifying, and validating requirements. And in doing so, they often forget about a critically important aspect of the BA work:requirements prioritization... Since good prioritizing skills help teams deliver business value faster, it’s a key competency for business analysts to develop. An effective to get better at prioritizing requirements is to follow this 3-step approach during the requirements discovery process.

13989 Views
3 Likes
4 Comments

Business Requirements are central to Software Development Offshoring relationship. Requirements are not hard objects that can be put across as formulas or equations. Irrespective of the artifacts used in requirements communication, requirements remain soft objects subject to various interpretations that may leave many voids for assumptions.

The purpose of this article is to investigate the challenges of requirements communication in Software Development projects.

14653 Views
32 Likes
8 Comments

It’s always the requirements fault! Whenever anything goes wrong with a software development project the requirements tend to be the scapegoat. It is a fact of life as a BA that at some point the requirements you write will be wrongly blamed for a mistake in the product. In reality, any oversight in the product is the responsibility of the entire development team. So what can the BA do to ensure they are not the convenient scapegoat for an issue with the product?

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











Copyright 2006-2020 by Modern Analyst Media LLC