HopPress’s Initial-Release Requirements

We have now identified HopPress’s stakeholders, functional requirements, conflicts, scope, system quality attributes, and system constraints. We can combine them into a requirements specification for the initial release.

Functional requirements

HopPress’s initial release must satisfy these functional requirements:

  • When a reader requests a list of posts, HopPress must return the published posts.
  • When a reader requests a post, HopPress must return it if the post is published.
  • When an author is signed in, HopPress must allow the author to create a draft.
  • When a signed-in author owns an editable draft, HopPress must allow the author to edit it.
  • When a signed-in author owns an editable draft, HopPress must allow the author to submit it for editorial review.
  • When an editor is signed in and a post has been submitted, HopPress must allow the editor to publish the post.
  • When an editor is signed in and a post has been submitted, HopPress must allow the editor to return the post to the author for revision.
  • When an administrator is signed in, HopPress must allow the administrator to assign roles.
  • When a post is created or its state changes, HopPress must record its author and current state. When a post is published, HopPress must record its publication time.

System quality attributes

The initial release must also meet these requirements for system quality attributes:

  • Performance: When a reader requests a published post, HopPress must return the response in under two seconds.
  • Availability: During each calendar month, readers must be able to open published posts at least 99.9 percent of the time. This allows at most about 43 minutes of unavailability in a 30-day month, including planned maintenance and unexpected failures.
  • Scalability: HopPress must continue to meet its two-second response-time target as the number of simultaneous readers grows from 50 to 500.

These requirements state measurable targets. The university may revise the targets, but each target must remain explicit enough to evaluate.

System constraints

The initial release must also respect these system constraints:

  • Technical: HopPress must run on the university’s existing hosting platform.
  • Technical: HopPress must use the university’s identity provider for sign-in.
  • Business: The project must work within a fixed budget and a three-month schedule.
  • Legal: HopPress must protect personal information and meet the university’s accessibility requirements.

This specification gives us a basis for evaluating design choices. A design must support the selected functional requirements, meet the required system quality attributes, and respect the system constraints.