Requirements Analysis (BABOK KA)

13073 Views
4 Likes
0 Comments

The ubiquity of software project failures – with failure defined as projects that fundamentally failed to meet business-sponsor expectations, missed scheduled completion dates, or exceeded budget – is a pronounced theme in any number of independent research reports on custom software development. The Standish Group, for example, cited that only 31% of projects delivered 100 percent of the expected value, were on-time, and on-budget and a report from the Aberdeen Group found 90 percent of projects came in late, of which 30 percent were simply cancelled before delivery.

Analysts and users alike cite inaccurate, incomplete and mismanaged requirements as the number one reason for software project failure. The Standish Group’s annual CHAOS report indicates three of the top five reasons for project failure are related to requirements. Requirement miscommunications is also the primary factor behind the prevalence of rework, which according to industry statistics, can add up to 40 percent of the total development effort within a given software project. A 2005 survey conducted by iRise and Decipher found that almost three-quarters (73%) of organizations budget for rework, thus, in effect, planning for failure. Moreover, almost one-third set aside more than 25% in their budgets for these change orders, money that could be funneled directly into innovation rather than re-doing work that should have been com¬pleted the first time.

Ultimately, rework costs companies the ability to get to market quickly and saps competitive advantage; while companies are busy fixing applications, their competitors are busy capturing market share.

The solution to these costly, frustrating problems is the creation of accurate requirements before development even begins. By allowing the business analyst to col¬laborate with stakeholders, users, architects, user expe¬rience designers and developers early on in the development process, all parties are involved in the definition of the product and all parties know what will be built long before a single line of code is written.

5217 Views
1 Likes
0 Comments

When your users are physicians and nurses, they don't have time to sit in meetings explaining what they want out of an application or to wade through documents validating requirements. Patient care is their number one priority.

To get over that obstacle, the development team at the University of Texas M.D. Anderson Cancer Center relies on a simulation tool. Using iRise's visualization tool, physicians and nurses can see what the application will look like based on requirements given and quickly change or validate those requirements.
Those applications are part of an electronic medical record (EMR) system that the cancer center has been working on for the past three years, after they could not find a packaged application that met the hospital's unique needs. Sherry Preston, manager of EMR support and development at the center, called the project a work in progress that will continue to evolve.

17044 Views
8 Likes
1 Comments

In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.

19236 Views
7 Likes
0 Comments

While working on a Business Architecture effort several years ago, I collaborated on developing a new internal standard for business process and business capability description. From my perspective, a business capability is the required function or desired service that a business unit performs and the business process is the set of methods employed to realize the business capability. Business capabilities and business processes can be described as current or future state. Their description can also be scaled for strategic or tactical objectives.

This article will present an approach for documenting and aligning business capabilities, business processes, and functional requirements by integrating two distinct tools that leverage robust repositories and object metadata.

7946 Views
2 Likes
1 Comments

Industry experts agree -- the success of any software development project depends directly on the definition of complete, high-quality, accurate requirements. Today's business analyst (BA) takes a lead role in defining those requirements. BAs are responsible for eliciting, analyzing, communicating, and validating requirements for a huge variety of business processes and information systems.

Since the activities of a BA are so critical to a timely, cost-effective, successful software project, it is important to equip the modern BA with a toolset that supports and accelerates all requirements definition activities, as well as provides the BA with practical guidance and resources to support this rapidly evolving role.

This toolset, known as a Business Analyst Workbench, allows analysts to do the following:

  • Gather and record stakeholder needs from a variety of sources
  • Interpret and analyze this information to produce a set of solution requirements
  • Collaborate with stakeholders to validate the requirements
  • Communicate the agreed-upon requirements to those who need to design, build, and test the solution

A Business Analyst Workbench can dramatically increase the accuracy and efficiency of both requirements definition and test definition. But what should you look for when evaluating a potential workbench?

A full-featured Business Analyst Workbench should satisfy four main criteria:

  • Support for multiple requirements approaches
  • Support for all phases of the requirements definition lifecycle
  • Intelligent integration with other application lifecycle management (ALM) tools
  • Inherent change management of requirements

Author: Tony Higgins

9768 Views
4 Likes
0 Comments

Requirements gathering resources and best practices were found lacking at Fortune 500 companies, a recent study from Voke Inc. found. But if business analysts are equipped with the right tools and enough resources, businesses stand to benefit greatly.

19073 Views
6 Likes
0 Comments

Software production has become one of the key activities of the industrialized world. Software applications are now the driving force of business, government operations, military equipment, and most of the services that we take for granted: electric power, water supplies, telephones, and transportation.

Most major companies and government agencies build or commission new software applications every year. But software development and software contracts have been very troublesome. Cost and schedule overruns are common, and litigation for software problems is a frequent outcome. Successful development of large software projects is so difficult that significant percentage of large systems greater than 10,000 function points are canceled and never completed.

One of the major challenges of software cost and schedule estimation is “sizing” or predicting the amount of source code and other deliverables that must be built to satisfy the requirements of a software application. Sizing is a critical precursor to software cost estimating whether estimation is done manually or by means of a commercial software cost estimating tool.

For software applications that are similar to existing applications, size can be derived by analogy to the existing packages. When the software application is a new kind of application then sizing by analogy is not a feasible approach.

For much of the history of the software industry, sizing was considered a very difficult and intractable problem. Sizing is still difficult, but over the past 30 years an interesting new methodology for dealing with size prediction has been developed based on the use of the function point metric. This new methodology has the advantage that it can not only predict the volume of source code, but also the volumes of planning documents, specifications, user manuals, test cases, and even the probable number of errors or bugs that might be encountered.

 

 

 

Author: Capers Jones is the President of Capers Jones & Associates LLC. He is also the founder and former chairman of Software Productivity Research, LLC (SPR), where he holds the title of Chief Scientist Emeritus. He is a well-known author and international public speaker, and has authored the books “Patterns of Software Systems Failure and Success,” “Applied Software Measurement,” “Software Quality: Analysis and Guidelines for Success,” “Software Cost Estimation,” and “Software Assessments, Benchmarks, and Best Practices.” Jones and his colleagues from SPR have collected historical data from more than 600 corporations and more than 30 government organizations. This historical data is a key resource for judging the effectiveness of software process improvement methods. The total volume of projects studied now exceeds 12,000. 

Copyright * 2008 by Capers Jones & Associates LLC.  All Rights Reserved.

12911 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

7089 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

6450 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

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

11173 Views
3 Likes
1 Comments

“The biggest risk to your company is not being able to change fast enough… Business Rules are the answer.” …Ron Ross

I am a great appreciator of Mr. Ross. He has written extensively on the topic of Business Rules, offers excellent training on the subject, and is the keynote speaker at each year’s International Business Rules Forum. I would like to start my own article on Business Rules with an ‘icebreaker’ he used on a seminar I attended.

Consider the sport of American Football. Some aspects of the game are very stable, some less so, and some not necessarily stable at all.

Author: David Wright

176367 Views
52 Likes
7 Comments

As a software architect and developer I’ve used Enterprise Architect (EA) from Sparx Systems (www.sparxsystems.com) for a number of years. In that time I’ve spent considerable time and energy trying to get our business analysts to do the same. While I’ve had some success I must admit it’s been an uphill battle. I suspect this is partly because EA is often seen as a technical person’s tool. And that’s not altogether surprising.

  • Enterprise Architect – the name itself is completely misleading. EA is not only for people with the title ‘Enterprise Architect’. It’s for the entire project team, from BA’s to Testers and even for Clients.
  • User Interface – for developers the user interface of EA is extremely familiar and intuitive. It looks like a lot of the tools they use already. For non-technical users more familiar with tools like Microsoft Office it is somewhat more intimidating.

So, if you’re a Business Analyst looking for a tool that can help you do your job more effectively then read on.

Author: Andrew Tokeley, Development Manager, Intergen Ltd
You can read Andrew's blog at:
http://andrewtokeley.net

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

14155 Views
8 Likes
8 Comments

A lot of IT folks and or BA’s believe that if you create the requirements without the business, and then review the requirements with the business for confirmation, you can save a lot of time.

After all, creating requirements collaboratively just takes too long, and the business doesn't know what they want, anyways. In addition, we (IT or BA) know the system better than the business, so it just makes sense for us to create the requirements, and then let the business say yes or no.

Let’s see this concept in practice in the “Requirements for My New Car”: a fable.

Author: James Shoemaker

Page 8 of 12First   Previous   3  4  5  6  7  [8]  9  10  11  12  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