Requirements Management and Communication (BABOK KA)

3159 Views
0 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.
Jun 11, 2017
5278 Views
9 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.
May 13, 2017
7097 Views
4 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, ...

Mar 19, 2017
11379 Views
14 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.

Jan 22, 2017
7240 Views
4 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).
Dec 28, 2016
10977 Views
10 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. 
9828 Views
69 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.

Jul 04, 2016
20739 Views
148 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.

May 23, 2016
9570 Views
6 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.
6454 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. 

13073 Views
12 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...
7735 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

10367 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.

9150 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.

10364 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 1 of 7First   Previous   [1]  2  3  4  5  6  7  Next   Last   


Upcoming Live Webinars



Latest Articles

Does design belong in your requirements?
Dec 17, 2017
0 Comments
I don’t know how many articles I’ve read where the author states requirements should be “what” the user/client needs, not &ldq...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC