Requirements Management and Communication (BABOK KA)

13220 Views
2 Likes
0 Comments

The Volere requirements techniques were developed to answer the need for a common language for discovering requirements and connecting them to solutions. The language needs to be understandable by business people, customers, business analysts, engineers, designers, suppliers, testers or anyone else whose input is needed. All of these people have different skills and, not surprisingly, different views of what is important. A language intended for all of these people must recognise the differences in peoples’ viewpoints and yet have a consistent way of communicating and tracing the
relevant knowledge. This realisation that requirements is a socio-technical discipline has a strong influence on the development of the techniques.

Author: Suzanne Robertson & James Robertson, The Atlantic Systems Guild

120737 Views
83 Likes
12 Comments

Every year, organizations around the world face startlingly high project failure rates. Some research has shown that less than 30 percent of software projects are completed on time and on budget—and barely 50 percent end up meeting their proposed functionality. If you’re a big league baseball player, failing five to seven times out of ten will get you an endorsement deal and a spot in the Hall of Fame. But, for the rest of us, these types of failure rates represent billions in cost overruns and project waste.

In 2005, ESI International surveyed 2,000 business professionals to try to find out why projects fail. The answers were numerous and varied and included such common thorns in the side as inadequate communication, risk management and scope control. But of all the answers, one showed up more than any other. Fifty percent of those surveyed marked “poor requirements definition” as their leading project challenge.

Failing to properly and accurately define requirements at the very beginning of the project lifecycle points to a distinct lack of business analysis competency. The role of the business analyst is an important one, and, sadly, one that is underutilized by many organizations around the world. In essence, a business analyst acts as a translator or liaison between the customer or user and the person or group attempting to meet user needs. But, that’s just speaking generally. What about the specifics?

Below, I’ve put together a list of eight key competencies that every business analyst—or every professional performing the duties of a business analyst—should possess. I’ve included specific emphasis on tasks associated with junior, intermediate and senior business analysts. If performed effectively, the items on this list could save organizations millions.

Author: Glenn R. Brûlé

7163 Views
1 Likes
0 Comments

When developing or changing a process, and all its related assets, often the process engineers have to face an important issue: how defining an integrated set of processes so that each process element is designed taking in consideration its relationships with all the other interfacing elements. Together with this issue, we also have the need to ensure that all the relevant requirements for the processes and their process assets are fully understood and correctly managed. These objectives are even more difficult to achieve when more persons are working in parallel to the improvement of different process areas. The approach described in the following paper, leverages a defined process architecture and a documented specification of process requirements to ensure integration among the process elements. All the examples are referred to a CMMI® based process definition but the most of the concepts are applicable also when adopting process models other than CMMI®.

Author: Filippo Vitiello, method park Software AG

6469 Views
0 Likes
0 Comments

Requirements and the way they are dealt with are decisive to the success of a project. This statement is never really questioned in modern software engineering circles.

Why is it, then, that a systematic requirements engineering (RE) system is so rarely established?

Where do the problems lie when it comes to implementing such a system?

This paper outlines the challenges and how these may be met using the example of the automotive industry.

Authors: Michael Gerdom and Dr. Uwe Rastofer, method park Software AG

17634 Views
2 Likes
0 Comments

"As I discussed my May article for Modern Analyst, there's a lot of hype about the role of requirements in agile projects. Many people think you don’t “do” requirements on an agile project. Hogwash. Indeed, agile projects use requirements—but just enough requirements at just the right time."

In this article Ellen covers a number of agile requirements topics including:

  • Agile requirements need to be understood in context of the product, release, and iteration
  • Balancing Business and Technical Value
  • The Product Workshop
  • Release Workshops
  • Iteration Workshops

Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time.

11328 Views
1 Likes
0 Comments

The latest progression in software development methods is the agile approach. Its growing popularity proves how effective it is. But two extreme—and even dangerous—views have arisen about agile development. One is that you don’t do requirements at all when you’re working on an agile project. The other is that you don’t need good requirements practices.

In truth, agile development processes are based on good practices. Most of them are not new but are being reconfigured, along with good product development, engineering, and project management practices. In my work with agile teams, I’ve noticed a number of key practices.

Author: Ellen Gottesdiener, Principal Consultant, EBG Consulting, helps business and technical teams get product requirements right so their projects start smart and deliver the right product at the right time.

5475 Views
0 Likes
0 Comments
Defining business requirements accurately is one of the most important success factors for technology projects.  Rather than focus on solutions that satisfy a list of requirements, we need to focus on solutions that satisfy desired business outcomes. The best way to achieve this is by performing business process modeling.  Employing a vi...
202963 Views
4 Likes
3 Comments
Ideally, an agile document is just barely good enough, or just barely sufficient, for the situation at hand. Documentation is an important part of agile software development projects, but unlike traditionalists who often see documentation as a risk reduction strategy, agilists typically see documentation as a strategy which increases overall projec...
6361 Views
1 Likes
0 Comments
Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project. Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted. Instead agilists will do just enough initial requirements envisioning to identify their projec...
7751 Views
1 Likes
1 Comments
To be honest, I'm not very enamored with the term "best practice". I believe that the term "contextual practice" makes far more sense because what is a "best practice" in some situations proves to be a "worst practice" in others. Having said that, people are interested in best practices so here they are when it comes to agile requirements modeling:...
4011 Views
0 Likes
0 Comments
Outsourcing differs from other development because there is bound to be a contractual relationship, probably a geographic distance, a different sense of loyalty, language misunderstandings, cultural differences, reluctance to speak up to the client – and many other associated problems. Good requirements are always a problem, but outsourcing increas...
3802 Views
0 Likes
0 Comments
IAG Consulting’s new Business Analysis Benchmark makes one thing clear: almost 70 percent of companies surveyed set themselves up for both failure and significantly higher cost in their use of poor requirements practices. That failure came at a significant cost: the average $3 million project cost companies using poor requirements practices an aver...
18567 Views
2 Likes
0 Comments

Defining specifications for the design and development of systems and software is a lot like this classic Gershwin song and what I personally regard as the biggest cause of confusion in the Information Technology field for as long as I can remember, which is over 30 years in the industry.  Some people say specifications should be based on the inherent properties of information, others believe it is based on a screen/report or file layout, yet others adamantly believe it should be based on process and data specifications.  Interestingly, all are absolutely correct.  The difference lies in the perspective of the person and the work to be performed.  For example, how we define specifications for the design of an automobile is certainly different than how we specify a skyscraper.  The same is true in the I.T. field where we have different things to be produced by different people.

Author: Tim Bryce

7370 Views
3 Likes
0 Comments
Analysts report poor requirements management accounts for as much as 71 percent of software project failures. The main cause is the gap between (a) what the business team wants and how it communicates this, and (b) what IT understands and delivers. No matter how good a project development environment is, if the requirements captured in the first p...
Page 7 of 7First   Previous   2  3  4  5  6  [7]  Next   Last   




Latest Articles






Copyright 2006-2019 by Modern Analyst Media LLC