From Needs to Functional Requirements

A requirement states a behavior, a quality, or a limit that the system must satisfy. A functional requirement states something the system must do.

Stakeholders usually begin with needs rather than precise system behavior. For example, a reader may need access to published information, an author may need a private place to develop a post, and an editor may need control over publication. We turn those needs into statements that a team can design, build, and test.

“Support an editorial workflow” is too broad because several different systems could satisfy it. For HopPress, that need turns into specific behaviors: an author can submit a draft, an editor can list submitted posts, and the editor can publish a submission or return it to the author.

State the behavior and its limits

A useful functional requirement answers three questions: Who or what initiates the action? What must the system do? Under what conditions may it do it? (Later, when we look at use cases, we will give names to the first and third of these: the initiating action is a trigger, and the condition is a precondition.)

“Authors can edit posts” leaves important questions unanswered. Which posts can they edit? Can they edit a post after submitting it? Must they sign in first?

A clearer requirement is: “A signed-in author can edit a post they own while the post is a draft or has been returned for revision.” This tells us who may act, which post they may change, and when the action is allowed.

For now, we can sketch HopPress’s main behaviors:

• A reader can list and open published posts.
• A signed-in author can create and edit their own drafts.
• An author can submit one of their drafts for editorial review.
• An editor can list submitted posts and publish or return a submission.
• An administrator can assign author, editor, and administrator roles.
• The system records each post’s author and current state.
• When the post is published, the system records the publication time.

These candidate behaviors are not yet a complete or final requirements specification. We still need to define words such as “published,” decide what happens when an action cannot be completed, confirm the priorities with stakeholders, and answer unresolved questions such as whether authors can delete drafts.

Keep design choices out of functional requirements

A functional requirement should describe the needed behavior without prescribing how we will build it.

“Store posts in a database table” selects a storage method and a particular way to organize the information. This is a design choice, not a functional requirement. “The system records each post’s author and current state” states what HopPress must store. This is a functional requirement; it makes storage necessary, but it does not choose the method for us.

Sometimes a technology is required. An organization might tell us that the new CMS must use a database it already operates. That statement limits our design choices, so we record it as a constraint rather than as a functional requirement. (More on this when we discuss non-functional requirements.)

The same distinction applies to the user interface. “Put a blue Publish button at the top of the page where an editor reviews a post” describes an interface design. “An editor can publish a submitted post” states the required behavior, which is what we want to capture in a functional requirement. The design of the interface is a separate concern.

This is a good place to define a few related terms:

• User interface (UI) design is about how the product looks: visual elements such as colors, fonts, and layout.
• User experience (UX) design is about the experience a user has when interacting with the product, including its visual appeal and usability.

UI and UX design deal with how users perceive and interact with an application. Software system design deals with the technical architecture, data flows, and infrastructure that let the application satisfy its requirements. We could consider the design of a system’s user interface and experience as part of its overall system design, but we usually treat them separately because they are different kinds of work.

Keep design choices (including UI/UX) out of functional requirements. This does not mean making a requirement vague. It still needs enough detail that two developers do not build different behavior while both believe they followed it. You should strive for clarity and precision, but keep the requirement focused on what the system must do, not how it does it.