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.
  • HopPress must let readers open published posts and keep unpublished posts private.
  • When an author is signed in, HopPress must allow the author to create a draft.
  • HopPress must let signed-in authors edit only their own posts, and only while those posts are drafts or have been returned for revision.
  • When a signed-in author owns an editable draft, HopPress must allow the author to submit it for editorial review.
  • HopPress must let only signed-in editors publish posts, and only after those posts have been submitted for review.
  • 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.