13.3. Defining the Requirements

The storyboards are only a part of the overall solution design, so you shouldn't be jumping for the keyboard just yet. However, they have provided a solid way forward. You've seen the application from a complete end-to-end flow and how it should work successfully from a user's perspective. The storyboards and walkthrough have also helped to flesh out some messages and alternative flows.

This section fleshes out the high-level functional and technical requirements, which can be used to build up the detailed use cases and processing. Requirements are often derived from use-case specifications. In reality, I find that the two are somewhat interrelated because detailed use cases help to define requirements. The case study's functionality is a pretty well known subject, so I chose to start by fleshing out a series of storyboards, which helps to define the requirements and the detailed use cases. In the field, analysis and design will include a number of these activities which can be performed simultaneously.

The requirements are not going to be an exhaustive list, but they will capture some of the core business and processing rules. A full set of detailed low-level requirements would be a rather long list, even for such a relatively small application. I'll also take a look at some of the features and functions that are offered by similar systems to help define the scope and, more important, determine what's out of scope for this release.

13.3.1. Functional ...

Get Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.