| Software Requirements Essentials |
|
Authors: Karl Wiegers and Candase Hokanson This slim book looks at how to work out the requirements for a software project through twenty 'practices' that you can use to understand that the problem is, find the right people for your team, communicate effectively, and develop the features of your project in the best order. Karl Wiegers has written a number of other popular titles, including Software Requirements. In this book he and Candase Hokanson have distilled the material in Software Requirements into a shorter form summary of the practices explained there for how to carry out an agile-like iterative development. Many of the practices sound self-evident, but having them laid out with discussions does clarify the process. 
The opening chapter of this book sets out the essentials of software requirements, starting by defining what the authors mean by requirements before going on to lay out good practices for requirements engineering and themes that will recur throughout the book. The next chapter, laying the foundation, introduces the first five practices: understand the problem before converging on a solution; define the business objectives; define the solution's boundaries; identify and characterize the stakeholders; and identify empowered decision makers. All of the practices in the book are written up in the format of an overview of what the practice involves, a more detailed description, a list of related practices, and a set of next steps you should take. In this chapter, the business requirements practice includes suggested templates for project scope and charters, while the boundaries practice has context diagrams and ecosystem maps.
Chapter 3 is titled "Requirements Elicitation", and the three practices it describes are understand what the users need to do with the solution; identify events and responses; assess data concepts and relationships; and elicit and evaluate quality attributes. There's a useful table of common requirements elicitation techniques with activities you might carry out with different stakeholders, and another useful 'anatomy of a use case' table setting out the different elements and their descriptions. Chapter 4, "Requirements Analysis", has practices for analyzing the requirements and requirement sets for the project; creating the requirement models; creating and evaluating prototypes; and prioritizing the requirements. By this stage in the book, the practises are more complex and the descriptions more detailed. The description of how to analyze requirements and requirements sets has useful checklists for the major aspects, future trees showing the major features and their subfeatures that make up a solution; and a quality assessment guiding the reader on characteristics they need to ensure are included - completeness, correct, feasible, necessary, prioritized, unambiguous and verifiable. Again, the list is obvious when laid out, but we've all read horror stories of large well funded software projects that obviously didn't use this. Chapter 5, "Requirement Specification", starts with the practice of writing requirements in consistent ways, followed by organizing templates in a structured fashion. These are followed by practices to identify and document business rules, and create a glossary. The practice for writing consistently looks at the traditional use of the keyword 'shall' for setting out how the system should behave under certain conditions, and how you can identify requirements that conceal complexity and should be expanded. Chapter 6 is a short chapter with just a single practice - to review and test the requirements, with two suggested ways you might do this: requirement reviews and acceptance criteria. The final chapter on "Requirements Management" has two practices, establish and manage the requirements baseline, and manage changes to requirements efficiently. The authors set out baselining strategies, and the technique of overlaying a feature tree with what is included in iterations and releases. Overall, the book is well written, clear, and has useful tables and discussions. There wasn't anything that made me react 'wow, I'd never thought of that', but there wasn't anything I dismissed as irrelevant. Most of what is described ought to be obvious, but there are plenty of examples out there where people obviously haven't put the right planning and steps in place. Worthy of a place on your planning bookshelf.
To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.
|
|||
| Last Updated ( Tuesday, 07 November 2023 ) |