Software Requirements: Styles and Techniques |
|
|
|
|
| Soren Lauesen |
| January 2002, Addison-Wesley Pub Co, Paperback, 608 pages, ISBN 0201745704
|
|
|
|
 |
|
Topics covered:
Introduction to requirements, domain and product-level requirements,
requirements for different project types, traditional, fast, and two-step
approaches to defining requirements, types of data requirements (data
models, dictionaries, data expressions, and virtual windows), types of
functional requirements (including context diagrams, event and function
lists, feature requirements, screens and prototypes, task descriptions,
scenarios and use cases), functional details (including tables and decision
tables), Unified Modeling Language diagrams used with requirements (including
state, activity, class, collaboration, and sequence diagrams), requirements
for product integration (for nontechnical and technical audiences), defining
quality requirements, specifying accuracy, performance, and usability;
security and maintainability requirements, product life cycle and requirements
for each step (including contracts, proposals, design and programming,
acceptance testing and delivery, requirements management, release planning,
tracing and tool support), elicitation issues and techniques, stakeholders,
working with focus groups, business goals and cost/benefit, domain-requirements
tracing, checking and validation, real-world examples of techniques in
action, case studies (and sample requirements) for a Danish shipyard database,
two medical systems, a noise source location application, and a system
to manage members of a political association.
|
 |
|
| Preface | | | 1 | Introduction and basic concepts | 1 | | 1.1 | The role of requirements | 3 | | 1.2 | Project types | 8 | | 1.3 | Contents of the specification | 12 | | 1.4 | Problems observed in practice | 18 | | 1.5 | Domain level and product level | 20 | | 1.6 | The goal-design scale | 24 | | 1.7 | Typical project models | 31 | | 2 | Data requirement styles | 41 | | 2.1 | The hotel system example | 42 | | 2.2 | Data model | 44 | | 2.3 | Data dictionary | 56 | | 2.4 | Data expressions | 60 | | 2.5 | Virtual windows | 66 | | 3 | Functional requirement styles | 71 | | 3.1 | Human/computer - who does what? | 74 | | 3.2 | Context diagrams | 76 | | 3.3 | Event list and function list | 80 | | 3.4 | Feature requirements | 84 | | 3.5 | Screens and prototypes | 88 | | 3.6 | Task descriptions | 92 | | 3.7 | Features from task descriptions | 102 | | 3.8 | Tasks & Support | 104 | | 3.9 | Scenarios | 114 | | 3.10 | Good Tasks | 116 | | 3.11 | High-level tasks | 122 | | 3.12 | Use cases | 126 | | 3.13 | Tasks with data | 134 | | 3.14 | Dataflow diagrams | 138 | | 3.15 | Standards as requirements | 146 | | 3.16 | Development process requirements | 150 | | 4 | Functional details | 153 | | 4.1 | Complex and simple functions | 154 | | 4.2 | Tables and decision tables | 160 | | 4.3 | Textual process descriptions | 164 | | 4.4 | State diagrams | 168 | | 4.5 | State-transition matrices | 172 | | 4.6 | Activity diagrams | 176 | | 4.7 | Class diagrams | 182 | | 4.8 | Collaboration diagrams | 188 | | 4.9 | Sequence diagrams, events, and messages | 190 | | 5 | Special interfaces - combined styles | 195 | | 5.1 | Reports | 196 | | 5.2 | Platform requirements | 200 | | 5.3 | Production integration - non-technical customers | 204 | | 5.4 | Product integration - main contractor | 212 | | 5.5 | Technical interfaces | 214 | | 6 | Quality requirements | 217 | | 6.1 | Quality factors | 220 | | 6.2 | The quality grid | 228 | | 6.3 | Open metric and open target | 228 | | 6.4 | Capacity and accuracy requirements | 234 | | 6.5 | Performance requirements | 238 | | 6.6 | Usability | 248 | | 6.7 | Usability requirements | 258 | | 6.8 | Security | 266 | | 6.9 | Security requirements | 276 | | 6.10 | Maintenance | 280 | | 6.11 | Maintainability requirements | 284 | | 7 | Requirements in the product life cycle | 289 | | 7.1 | Project inception | 292 | | 7.2 | Contracts | 294 | | 7.3 | Comparing proposals | 298 | | 7.4 | Rating the requirements | 304 | | 7.5 | Writing a proposal | 308 | | 7.6 | Design and programming | 314 | | 7.7 | Acceptance testing and delivery | 318 | | 7.8 | Requirements management | 322 | | 7.9 | Release planning | 326 | | 7.10 | Tracing and tool support | 328 | | 8 | Elicitation | 331 | | 8.1 | Elicitation issues | 334 | | 8.2 | Survey of elicitation techniques | 338 | | 8.3 | Stakeholders | 350 | | 8.4 | Focus groups | 352 | | 8.5 | Business goals | 356 | | 8.6 | Cost/benefit | 360 | | 8.7 | Goal-domain tracing | 364 | | 8.8 | Domain-requirements tracing | 370 | | 9 | Checking and validation | 373 | | 9.1 | Quality criteria for a specification | 376 | | 9.2 | Checking the spec in isolation | 382 | | 9.3 | Checks against surroundings | 390 | | 9.4 | Checklist forms | 394 | | 10 | Techniques at work | 399 | | 10.1 | Observation | 399 | | 10.2 | Focus groups at work | 402 | | 10.3 | Conflict resolution | 408 | | 10.4 | Goal-requirements analysis | 410 | | 10.5 | Usability testing in practice | 420 | | 10.6 | The keystroke-level model | 426 | | 10.7 | The story behind Tasks & Support | 428 | | 11 | Danish Shipyard | 439 | | 12 | Midland Hospital | 491 | | 13 | West Zealand Hospital | 511 | | 14 | Bruel & Kjaer | 519 | | 15 | Tax Payers' Association | 529 | | 16 | Exercises | 541 | | References | 561 | | Index | 575 |
|
|
 |
|
| Most IT systems fail to meet expectations. They don't meet business goals
and don't support users efficiently. Why? Because the requirements didn't
address the right issues. Writing a good requirements specification doesn't
take more time. This book shows how it's done many times faster and
many times smarter.
What are the highlights? - Two complete real-life requirements specifications (the traditional and the fast approach) and examples from many others.
- Explanations of both traditional and fast approaches, and discussions of their strengths and weaknesses in different project types (tailor-made, COTS, and product development).
- Real-life illustrations of all types of requirements, stakeholder analysis, cost/benefit and other techniques to ensure that business goals are met.
- Proven methods for dealing with difficult or complex requirements, such as specifying ease-of-use, or dealing with 200 reports that might be needed because they are in the old system.
Who is it for?
Everyone involved in the software supply chain, from analysts and developers
to end users, will learn new techniques, benefit from requirements written
by other specialists, and discover successes and failures from other companies.
Software suppliers will find ideas for helping customers and writing competitive
proposals. Programmers and other developers will learn how to express
requirements without specifying technical details, and how to reduce risks
when developing a system. Students aspiring to IT careers will learn the
theory and practice of requirements engineering, and get a strong foundation
for case studies and projects. |
 |
|
| Soren Lauesen is currently professor at the IT-University of Copenhagen.
He has worked in the IT industry for 20 years and has been a professor at
Copenhagen Business School for 15. He has been co-founder of three educational
and two industrial development organizations. His industry projects have
encompassed compilers, operating systems, process control, temporal databases,
and software quality assurance. His research interests include human-computer
interaction, requirements specification, object-oriented design, quality
assurance, marketing and product development, and interaction between research
and industry. He has a broad range of other interests ranging from biology
to dancing and foreign cultures. |
 |
|
Amazon.com
Suitable for most any IT professional who wants to build better software,
Software Requirements: Styles and Techniques offers a surprisingly readable
textbook-style treatment of software engineering's numerous attempts to
get it right with defining requirements. Surveying nearly every conceivable
style of defining requirements, yet remaining thoroughly practical, this
book can let your organization do more with its requirements documents,
which is a good step to creating software that succeeds better with your
users.
Though everyone in software design knows about requirements, actual examples
have usually remained shrouded in secrecy whether out of concern over
client or intellectual property confidentiality. One considerable strength
of this title is that the author has seen many good and bad requirements
documents and has included here several complete samples for a Danish
shipyard and two hospital systems.
The book begins by describing several dozen types of requirements styles,
along with the advantages (and disadvantages) of each. Each requirements
style differs by notation (text-based, graphical, or using Unified Modeling
Language), level of audience (for nontechnical or technical users), focus
(data, functional, performance, and usability), and whether it's used
early or late in the project development cycle. While the author highlights
those conventions that have worked best based on his extensive industry
experience and research, each type of notational style gets due coverage.
Sample requirements for a hotel-booking application anchor these early
sections.
Not surprisingly, requirements are often hard to ascertain. The author's
very thorough chapter on nearly 20 techniques to elicit requirements from
users (using interviews, focus groups, and the like) is a real standout.
Throughout this title, he offers plenty of advice on tracing requirements
so that you can prove your software meets all user expectations. This
text concludes with an extensive requirements document for a system used
to track shipping repairs for a Danish shipyard, two systems for hospitals,
and a membership database for a European political organization.
Reading Software Requirements will likely convince you that you can do
better with your requirements documents. Though there is no one best way,
certain types of requirements work for certain situations better than
others. This text can help you choose. Certain to be mandatory reading
for serious software analysts, this title can also benefit virtually anyone
who works with software design documents. Its clear presentation style,
remarkably devoid of jargon, helps make this book a great resource for
a wide range of readers, whether or not they have a background in traditional
software engineering.
--Richard Dragan
|
|