Mastering the Requirements Process
Author: Suzanne Robertson
"If the purpose is to create one of the best books on requirements yet written, the authors have succeeded."
—Capers Jones
It is widely recognized that incorrect requirements account for up to 60 percent of errors in software products, and yet the majority of software development organizations do not have a formal requirements process. Many organizations appear willing to spend huge amounts on fixing and altering poorly specified software, but seem unwilling to invest a much smaller amount to get the requirements right in the first place.
Mastering the Requirements Process, Second Edition, sets out an industry-proven process for gathering and verifying requirements with an eye toward today's agile development environments. In this total update of the bestselling guide, the authors show how to discover precisely what the customer wants and needs while doing the minimum requirements work according to the project's level of agility.
Features include
- The Volere requirements process—completely specified, and revised for compatibility with agile environments
- A specification template that can be used as the basis for your own requirements specifications
- New agility ratings that help you funnel your efforts into only the requirements work needed for your particular development environment and project
- How to make requirements testable using fit criteria
- Iterative requirements gathering leading to faster delivery to the client
- Checklists to help identify stakeholders, users, nonfunctionalrequirements, and more
- Details on gathering and implementing requirements for iterative releases
- An expanded project sociology section for help with identifying and communicating with stakeholders
- Strategies for exploiting use cases to determine the best product to build
- Methods for reusing requirements and requirements patterns
- Examples showing how the techniques and templates are applied in real-world situations
Robert L. Glass
Requirements are a make or break phase of the software development process. If the requirements are carefully chosen to represent what the customer wants, needs, and expects, then the project has a good chance of success. If not, the project may very well be doomed.
That said, it is easy to say that this book is about an important topic.
But is it a good book about that important topic?
My vote is "yes." This is a nicely crafted, well-thought-through, complete, up-to-date view of the task of creating a requirements specification for a software project.
Nicely crafted? It is well written, readable, never pedantic. Well-thought-through? The authors base the book on seminars they have given and honed over the years. Complete and up-to-date? Not only are the basic topics covered, but the authors also mention such advanced topics as requirements reuse, requirements patterns, traceability, and an event + use case-driven approach.
The book is written for the requirements novice. There are plenty of detail-level discussions of steps and approaches, templates for framing the results, and an elaborated case study (how refreshing it is to see a case study based on de-icing roadways, rather than one of the traditional, overused topics like video rental or cruise control!) But the book can also be useful to the patient requirements expert - there is more verbiage than the expert will want, but by scanning carefully the essence of the book can be easily distilled out. Importantly, the essence of the book is conceptual rather than formula/methodology-driven - the authors say the book is intended "not as a set of canonical rules that must be obeyed, but as a reliable companion to intelligent work."
Given all of that, I found some things that were mildly annoying: Some of the terminology the authors use is cutesy, although often it is appropriate, but (a) "blastoff: as the term for project start? (The projects I've been involved with rarely start with a "blast"!); (b) "requirements leakage" for requirements that erroneously get accepted into a project? (I would have thought that things leak out of a project, not in!) The authors claim that their book can be used not just for customized software development projects, but also for software maintenance and even for projects that aggregate pre-built packages. But later they say that the requirements process should never consider the technology of the solution (all well and good for customization, but impossible for the latter two categories). The authors take the (debatable) position that "object-orientation has become the standard way of developing systems," but then mix the two terms "use cases" and "event-driven" as if they were the same, both related to the OO approaches. In my view, event-driven approaches are rather different from object-oriented ones (for example, Visual Basic allows the programmer to build an event-driven system, but the result may or may not (likely not!) be object-oriented). The authors speak of a "post-mortem review" (an excellent idea), but it is not until page 271 (near the end of the book) that it becomes clear that "post-mortem" means "after the requirements phase," not "after the project is complete." (Either could be correct, but the authors should make it clear which they mean when they first bring up the topic 250 pages earlier). There is an appropriate and thorough discussion of the topic of "fit," by which the authors mean that requirements should be expressed in a measurable way. But the authors fail to acknowledge that some things simply don't lend themselves to measurement, with the result that much mischief is done by those who attempt to measure the unmeasurable (e.g., the terrible tendency to state "the software product shall be modular" in terms of the length of program segments - "modules shall contain no more than 50 lines of code").
Things I particularly like about the book are Requirements representation is treated as a pragmatic topic, where requirements are to be readable by both application customers and software designers. There is none of the formal specification discussion that computer scientists love to advocate but that seldom fits the needs of real-world requirements. There is also a nice discussion of software tools, appropriately mentioning that they are a means to an end, not an end in themselves. (Interestingly, there is no mention of the now-in-disrepute term "CASE"!) The discussion of the "quality gateway," which covers the process of making a final decision as to which requirements to include in the final specification, is both important and nice. There are very well-done discussions of such topics as "requirements creep," "gold plating," "traceability," and "viability." (I was reminded of the wry comment by Jerry Weinberg at a conference many years ago that software may be the only discipline where the answer to the early-project question of feasibility is always "yes"!) The discussions of the avant-garde requirements topics like requirements reuse and requirements patterns are very nice. I was less pleased with the discussion of traceability - what the book contains is excellent material, but it fails to go far enough to note that tracing requirements into design and code, although extremely desirable, is so far an out-of-reach topic (due to the "explosion" of business requirements into design requirements as the life cycle proceeds, an explosion estimated by some to be measured in orders of magnitude).
There should be at least one book on requirements in the library of every enterprise, even every software professional. You could do a lot worse than choosing this one.
Booknews
She specializes in systems analysis and requirements modeling and specifications; he advises companies on requirements. They set out an industry-tested and adaptable template for gathering and verifying requirements for software products, errors in which they estimate account for up to 60% of the failures. The provide techniques and insights for discovering precisely what the customer wants and needs. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Interesting book: The Futures of European Capitalism or Market Operations in Electric Power Systems
CCNA Command Quick Reference
Author: Empson
All the CCNA®-level commands in one compact, portable resource
With hundreds of Cisco IOS® Software commands, options, and command arguments to remember, a CCNA® candidate has a lot to commit to memory. Organizing your own engineering journal with notes is a task unto itself, and online resources are not always available. Now there’s help from the CCNA Command Quick Reference.
Filled with handy tips and examples on how to apply the commands to real-world scenarios, this easy-to-use, portable reference will help increase your familiarity with Cisco IOS Software when working on routers and switches or in simulated networks. CCNA Command Quick Reference summarizes all commands with keywords, command arguments, and associated prompts. The book includes many configuration examples, visually diagramming a network with related configuration and output. It also includes unique references on subnetting, variable-length subnet masking (VLSM), and common router configuration steps.
Designed as a memory booster, this book is an excellent supplementary guide for students in the Cisco Networking Academy® Program CCNA curriculum or anyone reviewing for the CCNA exam (640-821 INTRO, 640-811 ICND, or 640-801 CCNA).
Topics are covered in the order of modules in the four CCNA Networking Academy courses:
CCNA 1–Networking Basics
CCNA 2–Routers and Routing Basics
CCNA 3–Switching Basics and Intermediate Routing
CCNA 4–WAN Technologies
Related Titles:
CCNA 1 and 2 Companion Guide
RevisedThird Edition
ISBN: 1-58713-150-1
CCNA 1 and 2 Lab Companion
Revised Third Edition
ISBN: 1-58713-149-8
CCNA 3 and 4 Companion Guide
Third Edition
ISBN: 1-58713-113-7
CCNA 3 and 4 Lab Companion
Third Edition
ISBN: 1-58713-114-5
Cisco CCNA Network Simulator
ISBN: 1-58720-131-3
This book is part of the Cisco Networking Academy Program Series from Cisco Press®. The products in this series support and complement the Cisco Networking Academy Program.
Quick Reference Chart Inside the Front Cover
Table of Contents:
| Pt. I | CCNA 1 | 1 |
| Pt. II | CCNA 2 | 3 |
| Ch. 1 | WANs and routers | 5 |
| Ch. 2 | Introduction to routers | 11 |
| Ch. 3 | Configuring a router | 17 |
| Ch. 4 | Learning about other devices | 27 |
| Ch. 5 | Managing Cisco ISO software | 33 |
| Ch. 6 | Routing and routing protocols | 43 |
| Ch. 7 | Distance vector routing protocols | 47 |
| Ch. 8 | TCP/IP suite error and control messages | 55 |
| Ch. 9 | Basic router troubleshooting | 57 |
| Ch. 10 | Intermediate TCP/IP | 61 |
| Ch. 11 | Access control lists (ACLs) | 63 |
| Pt. III | CCNA 3 | 81 |
| Ch. 1 | Introduction to classless routing | 83 |
| Ch. 2 | Single-area OSPF | 87 |
| Ch. 3 | EIGRP | 97 |
| Ch. 4 | Switching concepts | 103 |
| Ch. 5 | Switches | 105 |
| Ch. 6 | Switch configuration | 107 |
| Ch. 7 | Spanning tree protocol | 123 |
| Ch. 8 | Virtual LANs | 125 |
| Ch. 9 | VLAN trunking protocol | 135 |
| Pt. IV | CCNA 4 | 153 |
| Ch. 1 | Scaling IP technologies | 155 |
| Ch. 2 | WAN technologies | 165 |
| Ch. 3 | PPP | 167 |
| Ch. 4 | ISDN and DDR | 173 |
| Ch. 5 | Frame relay | 185 |
| Ch. 6 | Introduction to network administration | 195 |
| App. A | Subnetting | 199 |
| App. B | VLSM | 211 |
No comments:
Post a Comment