敏捷工程的需求

Agile Requirements Engineering
We need to make a distinction between requirements engineering for agile methodologies and agile requirements engineering. Agile requirements engineering means, generally, any ad hoc requirements engineering approach purported to be more flexible than traditional requirements engineering. This definition is not to be confused with specific practices for requirements engineering in agile methodologies as we just discussed (Sillitti and Succi 2006).
A number of agile requirements engineering approaches have been introduced in the past few years, many of them not much more than sloppy requirements engineering. But some of the recent work in this area has been good too. However, for any “legitimate” agile requirements engineering methodologies that you may encounter, most of the practices can be traced to the Agile Manifesto. For example, Vlaanderen et al. (2011) showed how certain requirements engineering practices from Scrum could also be for software product management (after delivery). In particular they identified sprint cycles, backlog administration, daily meetings, and early and frequent collaboration as necessary practices.
Story Test-Driven Development

To illustrate an agile methodology, we describe one notable example. In this methodology called story test-driven development (SDD), many of the usual customerfacing features of agile methodologies are incorporated along with short bursts of iterative development à la XP or Scrum. One difference in SDD, however, is that instead of the conventional user stories, customers write or review “story tests.” Story tests are nontechnical descriptions of behavior along with tests that verify that the behavior is correct. The story tests help “discover a lot of missing pieces or inconsistencies in a story” (Mugridge 2008).
A nice feature of the story test is that it uses the Fit framework to allow users to build test cases into the stories in a tabular fashion (see Chapter 8). Hence, the users intuitively specify behavior and the tests for that behavior in the requirements. For example, for a typical payroll system for a business (such as the pet store), a story test describing how to calculate ordinary and overtime pay for an employee based on various clocked hours is given in Figure 7.7.
The table in Figure 7.7 shows, for instance, that if an employee works 5 consecutive 9-hour workdays, then they are considered to have 45 hours in ordinary and zero hours in overtime pay due. If a worker clocks 10, 11, 12, 13, and 14-hour days in a week, then they are entitled to 45 hours of regular and 15 hours of overtime pay. But the Fit framework is an interactive specification—plugging in different values into the table that are incorrect will show up as invalid (see Chapter 8).
SDD development is considered to be complementary to test-driven development (TDD) in that the former is applied to overall system development (Mugridge 2008).