A directory of resources inthe field of technical communication.

Wiegers, Karl E.

5 found.

About this Site | Advanced Search | Localization | Site Maps
 

 

1.
#30581

Good Money After Bad

Many software projects that suffer a lingering death should have been canceled much earlier. Although it is hard to pull the plug on a project with a weak business case, failing to do so does throw good money after bad. Karl Wiegers gives some tips on decision making that can help you avoid this outcome. Karl also shows how to use decision points to keep a good project moving along.

Wiegers, Karl E. StickyMinds (2002). Articles>Project Management

2.
#27247

Inspecting Requirements

Errors in requirements specifications translate into poor designs, code that does the wrong thing, and unhappy customers. Requirements documentation should be inspected early and often. Anything you can do to prevent requirements errors from propagating downstream will save you time and money. Karl Wiegers shows you how.

Wiegers, Karl E. StickyMinds (2004). Articles>Documentation>Engineering>Specifications

3.
#27246

Listening to the Customer's Voice

Perhaps the greatest challenge facing the software developer is sharing the vision of the final product with the customer. All stakeholders in a project-developers, end users, software managers, customer managers-must achieve a common understanding of what the product will be and do, or someone will be surprised when it is delivered. Surprises in software are almost never good news. Therefore, we need ways to accurately capture, interpret, and represent the voice of the customer when specifying the requirements for a software product.

Wiegers, Karl E. Process Impact. Articles>User Centered Design>Collaboration

4.
#30582

When Requirements Collide

Could it be that not every set of business requirements has the customer's best interest in mind? Karl Wiegers had always believed that implemented software functionality should enable users to accomplish their goals and help the business achieve its objectives. But a recent experience with a less-than-helpful parking meter system suggested to him that conflicts sometimes might exist between business and user requirements.

Wiegers, Karl E. StickyMinds (2007). Articles>Project Management>Programming

5.
#34276

Writing Quality Requirements

This article describes several characteristics of high quality software requirement statements and specifications. We will examine some less-than-perfect requirements from these perspectives and take a stab at rewriting them. I’ve also included some general tips on how to write good requirements. You might want to evaluate your own project’s requirements against these quality criteria.

Wiegers, Karl E. Process Impact (2007). Articles>Project Management>Business Communication>Specifications

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon