Articles for 'Karl Wiegers'

15486 Views
13 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.
32531 Views
19 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...

18133 Views
3 Likes
0 Comments

 Managers often ask me what return on investment (ROI) they can expect from the money they spend on training, process improvement, and tools for requirements engineering. I’d love to give them a nice, tidy answer—but I can’t. As with so many questions in software, the correct answer is, “It depends.” This article explores some of the factors that influence what ROI an organization can expect from better requirements.

34282 Views
41 Likes
4 Comments

People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation.  This makes it sound as though there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize “what” and design should emphasize “how.” 

18862 Views
29 Likes
0 Comments

Rather than expecting use cases to contain all of a system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a software requirements specification, although you could add them to the use case description if you prefer.

19892 Views
14 Likes
0 Comments

It is certainly true that use cases are a powerful technique for discovering the functional requirements for a system being developed. However, this statement suggests that use cases are the only tool needed for representing a software system’s functionality. In most cases, they aren't.

22301 Views
28 Likes
2 Comments

The structure that use cases provide is far superior to the nearly worthless technique of asking users “What do you want?” or “What are your requirements?” In this article I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren't a sufficient solution to the requirements problem.

20145 Views
8 Likes
0 Comments

Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn't work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline. This article defines the requirements baseline and describes when to create one.

 
English (auto-detected) » English
 
 
English (auto-detected) » English
 
 
English (auto-detected) » English
 
44587 Views
8 Likes
0 Comments
An alternative to eliciting use cases and user stories is to identify the external events to which the system must respond. An event is some change or activity that takes place in the user’s environment that stimulates a response from the software system. An event-response table (also called an event table or an event list) itemizes all such events and the behavior the system is expected to exhibit in reaction to each event.
30879 Views
25 Likes
4 Comments

Tracking project status means comparing where you really are at a particular time against the expectation of what “complete” means for this development cycle.  Monitor the status of just those functional requirements that were committed for the current release, because that’s the set that’s supposed to be 100 percent done before you declare success and ship the release.

35278 Views
24 Likes
0 Comments

How often has a customer asked you to write software that is user-friendly, robust, fast, or secure? No one will argue that those are worthy goals that everyone wants in their software products. However, they are terrible requirements. They give you no idea of just what “user-friendly” means, or how to tell if you’ve achieved the desired characteristics that mean “user-friendly” to a particular customer.

21851 Views
36 Likes
2 Comments

No matter how thorough a job you do on requirements elicitation, there is no way to be certain that you have found them all. No little green light comes on to announce “You’re done!” You should always plan on new requirements trickling in throughout the project. However, an excessive rate of change of requirements suggests that important requirements were overlooked during elicitation.

14264 Views
10 Likes
1 Comments

In an ideal world, a single, full-time, expert user would indeed be sitting within view—“on sight”—of developers, ready at a moment’s notice to speak definitively for the entire user community. In reality, this is unlikely in most situations.

15126 Views
3 Likes
0 Comments

The CEO of a major corporation who was present when I described requirements traceability at a seminar asked, “Why wouldn’t you create a requirements traceability matrix for your strategic business systems?” That’s an excellent question. He clearly saw the value of having that kind of data available to the organization for each of its applications. If you agree with this executive's viewpoint, you might be wondering how to incorporate requirements traceability into your systems development activities in an effective and efficient way.

20017 Views
10 Likes
2 Comments

The most common way to represent the links between requirements and other system elements is in a requirements traceability matrix, also called a requirements trace matrix or a traceability table. When I’ve set up such matrices in the past, I made a copy of the baselined SRS and deleted everything except the labels for the functional requirements.

Page 3 of 5First   Previous   1  2  [3]  4  5  Next   Last   

 



 




Copyright 2006-2022 by Modern Analyst Media LLC