3.2. User Stories

User stories are informal descriptions of the software’s features. These stories are written from the perspective of the users roles described in User Roles and Responsibilities. The general format is:

As a <user> I want <goal/desire> so that <benefit>.

This section contains the user stories identified for this project.

3.2.1. Game State Management

As a Rust application developer,

I want the library to contain functionality for managing the state of the game,

so I can focus on creating engaging user experiences.

Acceptance Criteria

• The library exposes APIs for getting the current state and updating the state of the game. This includes functionality for checking the victory condition and determining the winner of the game, if any.

Notes

The design details of the APIs are outside the scope of this requirements chapter.

3.2.2. Know Squares that Contributed to Player’s Victory

As a Rust application developer,

I want to know what squares contributed to the player’s victory,

so I can draw a line through them or mark them in a special color.

Acceptance Criteria

• When a player has won the game there is a way to obtain the board’s squares that contributed to the victory.

• If the player won by getting multiple sets of squares as shown in Figure 3.1 then all square that contributed to the win are available.

3.2.3. Stable Library API

As a Rust application developer,

I want the library to have a stable API,

so that my application does not unexpectedly break if I use a different version of the library.

Acceptance Criteria

• The library uses semantic versioning to clearly communicate when there are API changes. 1

• There are integration tests that help library developers detect if the library’s API changes.

3.2.4. AI Player

As a Tic Tac Toe player,

I want to play against the computer,

as I do not always have a friend to play with.

Acceptance Criteria

• The library provides an AI player that Rust application developers can incorporate into their applications.

3.2.5. AI Difficulty Settings

As a Tic Tac Toe player,

I want different AI difficulty settings,

so I can play a challenging yet winnable game of Tic Tac Toe.

Acceptance Criteria

• The difficulty for AI players can be configured by the Rust application developer.

Notes

The difficulty can be thought of as a probability of how likely the AI will make a mistake.

3.2.6. Players Take Turns Having the First Move

As a Tic Tac Toe player,

I want to have the first move on the next game if I did not have the first move this game,

so I have a better chance of winning the next game.

Acceptance Criteria

• The game logic ensures the starting player alternates between games.

Notes

The player who takes the first move has more wining possibilities than the second player. 2

3.2.7. Maximum AI Update Time

As a Rust application developer,

I want the AI to block for less than one frame when picking a square,

so it does not block my rendering thread making my animations choppy.

Acceptance Criteria

• There is a benchmark that measures the worst case time the AI blocks while picking a square.

• How to run the benchmark is documented so developers can quickly evaluate this library to see if it meets their needs.

Notes

Frame times can vary greatly depending on platform and application. For example, an update time of one second might be just fine for a casual Tic Tac Toe game. However, a Tick Tac Toe mini-game in a modern FPS is expected to take just a fraction of the 1/144 second frame time. Therefore, providing the tools to allow the Rust application developer to see if this library meets their needs is sufficient to fulfill this requirement.

3.2.8. Getting Started Example

As a Rust application developer,

I want an example of getting started with the library,

so I can quickly start integrating the library into my application.

Acceptance Criteria

• There is a runnable example of using the library.

• The example is in a prominent location such as library’s documentation home page.

3.2.9. Detailed Library Documentation

As a Rust application developer,

I want detailed and thorough library documentation,

so I can determine how to use the library for my specific needs.

Acceptance Criteria

• All public modules and their members are documented using Rust’s documentation comments.

• The documentation contains the typical sections such as Panics and Errors.

• The documentation is accessible from the internet, such as being hosted on https://docs.rs.

3.2.10. Idiomatic Rust APIs

As a Rust application developer,

I want the library to provide idiomatic Rust APIs,

so the library works in natural and familiar way.

Acceptance Criteria

• The Rust API Guidelines are consulted when designing the library’s API. 3

• An experienced Rust programmer code reviews and signs off on the library’s API.

Notes

API design can be subjective. However, providing an idiomatic Rust API is important to fulfilling the Learn About Rust objective. Therefore, obtaining the opinions of an experienced Rust programmer helps ensure the resulting design is reasonable and idiomatic.

3.2.11. Cross Platform Support

As a Rust application developer,

I want the library to work on a variety of platforms,

so I can make Tic Tac Toe games for a wider use base.

Acceptance Criteria

• The library is tested and verified on two different platforms such as Windows 10 and Linux.

Notes

The use of platform specific code is minimized, however, the number of platforms the library is tested on may be limited due to resource constraints.

3.2.12. Available on crates.io

As a Rust application developer,

I want the library to be on Rust’s package registry, https://crates.io/,

so that I can easily incorporate it into my Rust based application with Cargo.

Acceptance Criteria

• The library is hosted on crates.io.

• The library can be obtained by simply specifying it as a dependency in a package’s Cargo.toml.

3.2.13. Source Available on GitHub

As a Rust application developer,

I want the library’s source code to be available on GitHub

so I can view the source code to get a better understanding of how the library works.

Acceptance Criteria

• The library’s source code is hosted on a public GitHub repository.

• The library’s tags match the releases on crates.io.

3.2.14. Permissive License

As a Rust application developer,

I want the library to be licensed under a permissive open source license,

so that I can incorporate the library into my application without worrying about legal issues.

Acceptance Criteria

• The library is released under a permissive open source license. The MIT license fulfills this requirement.

Footnotes

1

See https://semver.org/ for details on semantic versioning.

2

The player with the first move has about double the number of winning possibilities. For details see Wikipedia’s Tic-tac-toe page.

3

See the [Rust-API-Guidelines] for details.