Articles for 'Karl Wiegers'

23024 Views
17 Likes
2 Comments

Simple requirements changes often have far-reaching impacts, necessitating that many parts of the product be modified. It’s hard to find all the system components that might be affected by a requirement modification. Assessing the impact of a proposed change is easier if you have a road map that shows where each requirement or business rule was implemented in the software.

13418 Views
6 Likes
0 Comments

Many BAs wait until their requirements specification is complete before they present it to some reviewers. Busy developers, testers, project managers, and users have difficulty finding the time to scrutinize a large document on short notice. It’s far more effective to review an evolving document incrementally. Give reviewers just a few pages at a time, preferably soon after an elicitation activity.

20995 Views
12 Likes
2 Comments

In my view, the most powerful quality practice available to the software industry today is inspection of requirements documentation. A peer review is an activity in which someone other than the author of a work product examines that product to find defects and improvement opportunities.

17046 Views
3 Likes
1 Comments

There is no single correct way to document specific requirements information. Every BA needs a rich tool kit of techniques at her disposal so that she can choose the most effective requirements view in each situation. In this article I offer some ideas about how to make that choice.

18703 Views
8 Likes
0 Comments

An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable.

20521 Views
17 Likes
2 Comments

There are three basic checkpoints the business analyst can facilitate to help ensure that he or she is on the right track. Two are informal, merely a get-together with other parties to review the situation and not fraught with the imprimatur of approval. The other is a more formal presentation. I’ll address each of the three checkpoints in this series.

19185 Views
21 Likes
2 Comments

If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.”

29245 Views
33 Likes
6 Comments

There’s an old fable about six blind men who encountered an elephant for the first time. Although they couldn’t see it, they wanted to learn what an elephant was like. Each of them touched a different part of the elephant.

21756 Views
6 Likes
4 Comments

There are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article, expect to spend more time than average developing detailed requirements specifications.

21154 Views
3 Likes
2 Comments

Several conditions make it appropriate to leave the requirements descriptions at a higher level of abstraction. Recognize that these are broad guidelines. The BA should perform a risk-benefit analysis to balance the potential downside of omitting important information against the effort required to include it.

49684 Views
43 Likes
15 Comments

Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?”

16276 Views
5 Likes
2 Comments

The path to building great software goes through requirements management. It’s easy to forget some times, but the world relies on great software.  Software is everywhere. Whether you’re building a revenue-generating product or an internal system, your company’s overall success largely relies on your software team’s success.

3936 Views
1 Likes
0 Comments
 Software managers sometimes assume that every skilled programmer is also proficient at interviewing customers and writing requirements specifications, without any training, resources or coaching. This isn't a reasonable assumption. Like testing, estimation and project management, requirements engineering has its own skill set and body of know...
5871 Views
0 Likes
0 Comments
 Most books and articles on software requirements are written as though you’re gathering requirements for a brand-new product—what’s sometimes called a green-field project. In reality, few people have that opportunity on every project. Many developers work on maintenance projects. In such a project you’re usually adding...
4617 Views
0 Likes
0 Comments
The software industry is exhibiting an increasing interest in requirements engineering — that is, understanding what you intend to build before you’re done building it. Despite the hype of "Internet time," companies across many business domains realize that time spent understanding the business problem is an excellent investme...
Page 4 of 5First   Previous   1  2  3  [4]  5  Next   Last   

 



 




Copyright 2006-2022 by Modern Analyst Media LLC